二要素認証なんだから、同じサービスレベルで並列に管理するのが楽です


なんでアカウントの識別情報を変える必要があるの?

1) クラウドがパスワードを生で保存していないことを証明できるのか?

 クラウドがパスワードを生で保管、盗聴していることを否定する要素がないから。

 プログラムでパスワードを受け取る場合、生のハッシュ値を渡しても意味はありません。
 なぜなら、そのハッシュ値を記録して送信すればなりすませます。
 このためにチャレンジ用の乱数をサーバから送信して、それとパスワードをハッシュ関数に含めた数列を返送することで盗聴による同一ハッシュ値を用いた攻撃を予防します。
 しかし、これでは当然「クラウド側は、パスワードを知っていない」と「正しいパスワードでハッシュされたか?」を確かめようがありません。
 このため、事前にクラウドに「自己のパスワードが何であるか?」を伝える必要があります。
 これは、保管するときのリスクヘッジで、パスワードを自己のみが知っていることを保証するものではありません。
 つまり、パスワードを入力だけの類型に合致する認証の場合、必ず何らかの形でクラウドにパスワードを伝えています。
 その契機に「パスワードを生で保管」されていれば、それを知る術はありません。

 現状は、非対称鍵暗号方式と呼ばれる優れた技術(数学)がありますが、これを利用して認証しているサイトというのは、どれぐらいあるのでしょうか?
 これは、パスワード管理の問題ではなく【サイトを信頼できるのか?】という問題になります。 これをPKI サーバ証明書は、保証しません。

2) ブラウザとアプリ(笑)は、信頼できるのか?

 ブラウザに限定して、そのパスワード管理が示す結果を見れば分かります。
 そもそもブラウザは「パスワードをハッシュして保管しているの?」「記録したパスワードを逆関数で取り出せないの?」
 という観点を検証してみましょう。

 「生のパスワードを取り出せない」のであれば、どうやって乱数(チャレンジ)と生のパスワードを使ってチャレンジレスポンスを生成できるのでしょうか?

3) 何故、メガバンクや地方銀行、信用金庫は、無料アカウント(ゴキブリ、Ap、Am、Fa、Tw、Microsoft)のOAuthと連携しないのでしょうか?

 出来るわけがない。
 パスワードカードでも弱いから、殆どがワンタイムパスワードを運用している。

サービスレベルって何のこと?

 用語の定義で言えば「サービス品質」ですが、ここのページの定義は「サービスが提供する漏洩が発生した場合のリスク」です。

  1. 現実通貨、資産を操作できるアカウント(口座)
  2. OAuthで連携されているアカウント(口座)
  3. 国内法、合衆国法で縛り、指導が発生する通信事業者、大企業が提供するサイト(yahooを除く)
  4. 知名度がある企業が提供しているアカウント
  5. 素性が知れないサイト
 「大きく、この五つで分類してメールアドレスとパスワードを分けるべきである」というのが、このページの趣旨です。
 一つ思い出しておきたい事は、無料で作成できてサービスを提供しているサイトというのは、漏洩事故が発生した場合は、単純にサイトとサービスを終了して責任達成!終了!EoS!スレを落としていいよ^^v!
 となることが、実際の事例で散見されます。

 リスクヘッジ。 少し前にゴキブリが新しい認証方法(ただし提供者が大きな金銭的負担、投資なく)を募集していましたが、あれは結果が出たのでしょうか?