ニュースでではなく、たまたま知ったYahoo! JAPANの新しい機能、シークレットIDを試してみました。
この機能は簡単にいうと
- ログインIDを変更できる
という機能。簡単すぎて一行でした。
Yahoo! JAPAN のようにIDがサービス内で表示される場合、ログインIDが既知なのでパスワードのみ何らかの手段で入手されるとIDを乗っ取られてしまいます。
パスワードを総当たりで攻撃するとか、破られやすいパスワードを利用している場合もありますね。
大抵の場合、複雑で、長い(たとえば20文字程度の)パスワードを使用することで防衛するわけですが、それでもIDが知られているので相対的にはリスクは高くなります。
そこで、シークレットIDで、ログイン用のIDを別にしてしまおうという発想ですね。
これ素晴らしいと思います。
思いつく限りで
- (当然のことながら)アカウントを乗っ取られる危険性が減る
- 既存の仕組み(通常のID)と共存できる
- システム的に実装難易度が高くない
- より重要なサービスの場合、シークレットID必須というようなことが将来的に可能になる
という感じ。
ひとつめはいわずもがな。
わたしも早速パスワード管理ソフトのパスワード生成機能で、パスワード以上に堅牢なIDに変更しました。(そこまでする必要はないかもしれませんが、せっかくなので)
ふたつめの共存というのはYahoo! JAPANのようなサービスには絶対に必要でしょう。
ユーザーを啓蒙しながら、徐々に移行させるということも可能なので、意識の高いユーザーから移行していけます。
利用を休止しているユーザーの存在を考えると移行率が100%になることはありませんが、逆に言えば100%にする必要がありません。
3つ目の実装難易度が低いというのもポイントです。
技術的な話をするとおそらく以下のような手順で既存のサービスに載せることになるでしょう。
- usersテーブルにsecret_idフィールドを追加
- Userを追加するときにIDをハッシュ化しsecret_idフィールドに投入
- UserがシークレットID機能を利用するときはsecret_idを変更
- ログイン時にはシークレットIDとパスワードでログイン
という感じでしょうか。既存のユーザーも一律変換してしまって良いですね。
既存のログインの仕組みと大差ないので実装が簡単です。
(シークレットIDを失念したユーザーへの対応はパスワードと同様のフローで必要)
(ハッシュ化されてるかは不明ですが、まあしておいて損は無さそうですね。追記:確認したら登録情報のページでシークレットID表示されてたのでハッシュ化はされてないですね、ログイン専用IDという表記がふさわしいところでしょうか[06/07])
(ハッシュ化されてるかは不明ですが、まあしておいて損は無さそうですね。追記:確認したら登録情報のページでシークレットID表示されてたのでハッシュ化はされてないですね、ログイン専用IDという表記がふさわしいところでしょうか[06/07])
そして最後の点。
Yahoo!カードのような、よりIDパスワードが重要な意味を持つサービスがあります。
このようなサービスのみ、シークレットIDの登録が必須というようにすれば、よりセキュアにサービス展開が可能でしょう。
良いアイディアとはこういう少ない手間で大きな効果を生むものを言うのだと思います。
シークレットIDの機能、良いですね。
サービス提供者にとってパスワードをハッシュ化しておくのは当然ですが、シークレットIDの実装をするのも当然になってくるかもしれません。
というわけでみなさんぜひ活用しましょう!