短命化するWebサービスによるアカウント乱立への対策

Webサービスの普及により、ユーザーが保有するアカウントの数は続々と増えています。

大規模なサービスでは自社サービスを横断利用できるような共通IDへの統合も進んでいますが、多くのWebサイトではなおそれぞれ独自のアカウントを発行しています。

アカウントの乱立は、まずID・パスワードの組み合わせを忘れがちである、という利便性の面の難点があります。

この点についてはアカウントの再発行フローを利用することで回復は可能ですが、ほかにセキュリティの面のリスクがあり、潜在的な危険性も上がります。

多数のアカウントを持つことによる典型的なセキュリティリスクは、同じID・パスワードを複数のWebサイトで登録することです。

それぞれのWebサイトは別のシステムですが、1つのサイトでID・パスワードが流出した際に、別の大手サイトが同一のID・パスワードで攻撃され、なりすまし利用された事例があります。

セキュリティ強度の高いサービスを利用していても、別のサイトで認証情報をセットで入手されてしまうと悪用を防げません。

過去使っていたサービスで今は利用していないとしても、Webサイトの運営が続いている限りは同様の危険があります。

一時利用に近いサービスにアカウント発行は必要なのか?

日常的に利用するサービスであれば、アカウントを持つことにも合理性があります。

逆に一度しか利用しないようなサービスであれば、アカウントを作ることはデメリットの方が大きくなります。

たとえばオンラインショッピングでは、一度しか購買しないケースを想定して、会員登録せずに購入できる流れも用意されています。

購入時に電話番号やメールアドレスなどのコンタクト情報を取得することで、Web会員に限定することなく購入サポートを提供できています。

このような一時利用型サービスと併用されるアカウントは、フリークエンシープログラムのようなリピート利用創出のためのインセンティブ提供に使われています。

同様に、何らかの利用権を誰か特定の個人に付与したい場合は、なりすまし防止を含めたデジタル・アイデンティティが必要になります。

ただし、飲食店で配られるポイントカードやクーポンのように厳密に個人を特定せず、ある程度マスプロで提供する付加サービスであれば、特典メールのような代替手段もとれます。

OAuthのメリットとデメリット

アカウントの乱立対策として、大規模サイトの認証を流用する、という手があります。

OAuthプロトコルをサービスに実装すれば、GoogleやFacebookといった大手サービスのアカウントを利用できます。

この方式はID・パスワードをサービス側で保有することなく利用者を識別できるため、セキュリティリスクを低減できるメリットがあります。

一方、利便性には上がる面と下がる面があります。

基本的には大手サイトの認証を利用するため、利用者から見ると管理するアカウントを減らすことで利便性が向上します。

ただし、その大手サービスを利用していないユーザーにとっては、そのログイン手段を使えないため利便性が下がります。

複数のログインサービスに対応することでカバー範囲を広げられますが、程度問題の差に過ぎない面もあります。

このような制約を考慮に入れると、まずできるだけ多くのユーザーに利用してもらいたいサービス本体部分は認証なしで利用できるフローにしておく方が良さそうです。

また、継続利用するユーザーのインセンティブ識別のためにOAuthによるアカウント管理を導入することで、セキュリティリスクをおさえて利用権の制御を行えるようになります。

ワンタイムパスワード活用の可能性

認証情報にID・パスワードを用いる方式では、これまでに書いたような範囲にシナリオはおおむね収まります。

デジタルアイデンティティという観点で考えると、ほかにも機器認証やバイオメトリクス、ワンタイムパスワードなどがあります。

それぞれの手段には、導入の簡単さやセキュリティ強度、利便性などの面で特性があります。

この中で、とくに追加の機器を必要としないメール経由のワンタイムパスワードや、派生系としての期限付きURLには活用の余地がありそうです。

ワンタイムパスワードはメール認証の際などの利用例が多くあります。

メール受信できていることを本人確認とすることでサービスを利用させる方式です。

この方式では、メールが流出してしまった場合に一定期間アカウントにアクセスされてしまいますが、サービスの内容によっては利用できます。

1点、新たな弱点として、ユーザーがフィッシング詐欺に弱くなる、という懸念はあります。

長いURLにアクセスさせる方式では、ユーザーのURL文字列に対する注意力が落ちるため、実際に第三者のクラッカーからフィッシングURLを送りつけられた際に引っかかりやすくなることが考えられます。

この方式を採用するとしてもサービスの性質に合わせて利用すべきで、定期的に常用するようなサービスでは導入を避けた方が良さそうです。

⁋ 2016/02/03↻ 2024/11/07
中馬崇尋
Chuma Takahiro