ホーム DoRuby Webアプリケーション提供に於ける、passwordのあり方

Webアプリケーション提供に於ける、passwordのあり方

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

お久しぶりです。ととろです。半年ほど、留守にしておりました。その間、様々なところで、インシデントが発生し、どこかで私の書いた記事を読まれた方も多いかと思いますが、今後は引き続きこちらで掲載していきますので、今後とも宜しくお願いします。

 不正ログインの大量発生

さて、いずこかの場所で、約12億ユーザーにものぼる数のpasswordが漏えいしました。これを期したかの様に、日本国内の数々の大手サービス会社が狙われ、根こそぎログイン可能なIDとpasswordが盗まれる事態になりました。一部の新聞記事で私がコメントした内容ですが、「今回の事件は、確実にログインできるIDとpasswordリストを売買する闇市場が有る」と考えています。つまり、ユーザーが同じIDとpasswordの組み合わせを、他のサービスで利用している以上、マスターキーとなるべく、確実にログインできる辞書ファイルが作成されつつ有り、それが高値で取引されるブラックマーケットが存在している。その様に考えています。

ユーザーに、どんなにサイト毎にpasswordを変えて下さいとお願いしても、ユーザーは「まさかそんなこと」と、相手にもせずにそのまま同じIDとpasswordの組み合わせを使い続けることでしょう。

 サービス提供会社としては?

先ほど、ユーザーは対岸の火事と考え、同じIDとpasswordの組み合わせを使い続けると書きました。では、サービスを提供する側に立って考えてみましょう。サービスを提供するが解らしてみれば、ユーザーが勝手に他のサービスと同じIDとpasswordを使い回した結果、不正ログインされるわけです。それが、数件ならまだしも、数百件、数千件にも上れば、新聞沙汰になりかねませんし、提供しているサービスが有名であれば、有名であるほど、ユーザーのサービス離れ(サービス解約)に拍車がかかります。サービス提供会社に、落ち度が無いにもかかわらず、ユーザーの勝手な思い込みにより、サービス提供が出来なくなる。こんな理不尽なことはありません。

今まで、どのサービスに於いても、password設定に関する主導権は、ユーザー側にありました。ポリシーとして、記号を入れるや、大文字を含める、数字を含めるなどいくつかの制限を盛り込んだとしても、それはあくまでもpassword設定に対して求める内容であって、passwordそのものを決定づけるのは、ユーザー自身です。これは、不文律で有り、世界の常識でした。しかしながら、昨今の様に立て続けに不正アクセスが続き、そして、不条理にもユーザーの勝手なpassword設定によって、不正アクセスが表沙汰になり、大騒ぎとなってサービス停止や、ユーザー離れにつながる。これでは、サービス提供会社はたまったものではありません。そこで、敢えてこの「passwordはユーザーが設定する物」という不文律を変えてみたいと考えています。

 では、どのようにすればいいのか?

サービス提供者から、passwordをいくつか提示し、そのpasswordの中から、ユーザーに利用するパスワードを決めて貰えば良いのです。このとき、パスワードのみを提供し、ユーザーID(ログインID)は、ユーザーに提供して貰います。データベース的には、ユーザーIDのみを記録し、passwordは記録しません。ユーザーには、先ほど書いた様に、ユーザーIDを提供して頂きますが、そのときの打鍵の情報をsaltとして持ちます。つまり、打鍵の早さによってバイオメトリックス認証もどきを行います。バイオメトリックス認証そのものを行うわけでは無く、あくまでも、saltとして用いるだけであり、他の用途には用いません。そして、ユーザー登録した日時を、秒まで含めて記録します。頭のキレる方はお気づきのことと思いますが、ユーザー認証に用いるIDとそれを入力した時間、それに加え、saltキーを元に幾何学演算を用い、いくつかの候補を画面に表示し、どれを選んだかを、DBに記録します。

これを行う事により、認証に用いられるpasswordは、ユーザーのみが記録しておき、システム側はそのpasswordを記録すらしません。存在するのは、生成アルゴリズムとユーザーが入力したID、それに暗号化したsaltのみである。これなら、アプリケーションに穴があったとしても、passwordは漏えいしませんし、当然、ユーザーからpasswordが漏えいしたとしても、他のユーザーへの影響はもちろんのこと、他のサービスに於いても、影響を受けることがありません。

 まとめ

今回は、ユーザーにも優しく、システム側にも優しい、passwordのあり方について考えてみました。

記事を共有
モバイルバージョンを終了