使い捨てコードをメールで送る方式は、パスワードよりも悪い
(blog.danielh.cc)- 最近、多くのサービスが メールまたは電話番号ベースの6桁コードログイン 方式を導入している
- メールアドレスや電話番号を入力すると6桁の認証コードが送信され、それを入力してログインする
- この方式は アカウントのセキュリティに深刻な脆弱性 をもたらす
- 攻撃者は単に 他人のメールアドレスを正規サービスに入力 して、認証コードの送信を要求できる
- ユーザーは受け取った認証コードが 本当に正しく使われるべき状況なのか、それともフィッシングの試みなのかを簡単に判断できないという問題がある
- Password manager（パスワードマネージャー）のような既存のフィッシング防止ツールの効果がない
- この認証コード方式は、実際に悪用事例が継続的に発生している
- 実際にMicrosoftが運営する Minecraftアカウントのログイン でも類似の方法が使われている
- Reddit、YouTubeなどさまざまなオンラインコミュニティやメディアで 複数のアカウント盗難事例 が報告されている
結論
6桁コードのメール認証方式は、セキュリティ面で予想以上に 脆弱な方式 である
- 従来のパスワード方式に比べて、むしろフィッシングのリスクが 大幅に増加する
- ユーザー体験の改善やセキュリティ向上のために導入された方法だが、実際にはより悪い結果を招く 可能性がある
3件のコメント
あまり共感できませんね。かなり限定的な状況でしか通用しないトリックのように思えるので。
パスキーを使っていてデバイスをなくしたら、本当にかなり困りそう……
Hacker Newsの意見
攻撃パターンは次のようなもの
1) ユーザーが詐欺サイトに登録する
2) そのサイトが「GOODサイトからログインコードをメールで送ったので入力してください」と案内する
3) 詐欺サイトが、ユーザーのメールアドレスを使ってGOODサイトの「メールでワンタイムコードを送ってログイン」フローを開始する
4) GOODサイトがログインコードをユーザーにメール送信する
5) ユーザーはメールがGOODから来ているので信用してそのコードを入力する
6) ユーザーが詐欺サイトにコードを入力する
7) 詐欺サイトがそのコードを使って、GOODサイトにユーザー本人としてログインする
このため、「メールでワンタイムコードを送る」認証方式はフィッシング攻撃に非常に弱い
「メール内のリンクをクリック」方式のほうが少しマシで、ユーザーがGOODサイトへ直接移動するうえ、詐欺サイトにそのリンクをコピー＆ペーストするのはより面倒で怪しく見えるから
ただし、人気のあるメールサービスが突然ログインメールやリンク自体をブロックし始めると、多くのユーザーがそもそもログインできなくなる問題もある
Passkeysが最も正しい方法
パスワードマネージャーのパスキー対応はますます良くなっている
もしパスキーを保存した端末を紛失してすべてのパスキーを失ったとしても、従来のパスワード方式よりはるかに安全だと確信している
祖母がアカウントへアクセスするために銀行を訪ねなければならないとしても、誰かがフィッシングで祖母のお金を全部盗むよりはマシだと思う
Passkeysの問題は「端末を失うとアクセス権も失う」というだけではなく、もっと複雑だ（設定次第では端末紛失時の救済策もある）
最大の問題はAttestationだ
サービス側が、ユーザーの自由を広げるツール（たとえばオープンソースの認証ソリューションなど）を使う人をブロックできるようにしてしまう
Passkeysやchallenge-responseプロトコル方式は、本来パスワードを置き換えられる大きな改善策になれたはずだった
ところが現実には、BigTechの支配体制をさらに強固にし、ユーザーの自由を減らす方向に設計されている
「祖母がアカウント復旧のために銀行へ行くほうがマシ」という話について
銃で脅されてアカウントを無理やり解除され、お金まで全部奪われる場合を考えるべきだ
私の住む第三世界の国ではスマートフォン強盗の問題が深刻すぎて、2FAすら現実的ではない
以前一度だけ2FAを復旧したことがあるが、地獄のようだった
パスワードなら、どこからでもBitwardenにアクセスすれば解決できていた
Passkeyをgithubに設定し、Chromeに保存されていることも確認した
githubにpasskeyでログインしようとすると、ChromeがGoogleパスワードマネージャーのPIN入力を求めるポップアップを出す
このPIN番号が何なのかわからず、リセット方法も見つからない
Googleプロフィール、パスワードマネージャー、セキュリティ設定のどこにもPINについての案内がない
祖母が銀行を訪ねてアカウント復旧するのは構わない、という意見に対して
私は銀行や会社のITヘルプデスクに直接行ってアカウント復旧できるが、
Google・Facebook・Xitterの本社まで行って同じことはできない
デバイス結合型のパスキーは、こうしたケースで問題が起きる確率が非常に高い
ほとんどのユーザーはこういう状況を想定できていない
Passkeysだけでは十分ではない
これまでの失敗を繰り返すな、という話だ
パスワードマネージャーを基本にして、本当に例外的なケース（メールアカウント、金融口座など）にだけ専用MFAを導入すべきだ
MFA設定も最低3種類を設定させ、そのうち2つ以上を使うべきだと思う
印刷したコード、OS非依存の認証アプリ、yubikeyのようなハードウェアキーなど、ほぼあらゆる方式をサポートしないMFAには価値がないと思う
1日に4回、Microsoftアカウントのパスワード再設定リクエスト通知メールが届く
6桁の数字が書かれたメールで、これでアカウント復旧できるようになっている
つまり攻撃者は毎日100万分の1の確率で、私のアカウント奪取を4回試せるということだ
これを数千アカウント相手に試せば、毎日無料でいくつかのアカウントを突破できる
この内容でセキュリティ報告まで出したが、数学的に脆弱性の証明が十分でないとして対応を拒否された
残る手は、ただスパムを受けながらアカウントが乗っ取られないことを祈るしかない
ログイン用エイリアス(alias)を追加して解決した
ログイン時には従来のアカウントメール（公開されているメール）は使えなくし、非公開のランダム文字列であるエイリアスでのみログインできるようにした
それ以降、外部からのログイン試行は一度もない
[設定方法: account.microsoft.com > 自分の情報 > サインインの設定 > メールを追加 > エイリアスを追加して既定に設定 > サインインの設定でエイリアスのみ許可を選択]
私も同じ経験をした
たぶんMicrosoft Teamsを使わなければならなかったときの名残だと思う
攻撃者が125,000アカウントを対象にこの方法を使えば、1日に1アカウントくらいは当たる可能性がある
特定アカウントを狙わず全体に対して試すなら、時間あたりの効率はかなりいい
この問題を解決するには、固定4回の試行制限ではなく、失敗するたびに待ち時間を増やすexponential backoffを適用すべきだ
私も古いInstagramアカウントで似たようなメッセージを受け取り続けている
「ログインに問題がありますか？ パスワードを変更するにはここをクリックしてください！」
古い使い道のないアカウントでも同じことがあった
ログインを試みたIPアドレスを確認すると、世界中のさまざまなISPから来ており、その大半は互いに異なる/16ネットワークだった
こんな「どうでもいい」アカウントにまでbotnetを動員しているのを見ると、脅威にさらされている人たちはどれほど深刻なのかと心配になる
2FAを追加したら完全に解決した
彼らが最初にどうやってこの6桁コードを使うログインフローを見つけたのかは今でもわからない（私は毎回パスワード入力後すぐログインできていたので）
それでも2FA追加後は、追加の試行を一度も見ていない
2FAコードもパスワードマネージャーに保存している
Microsoftの自動6桁（英字ですらなく数字だけ！）「パスワード」抽選を、もう攻撃できなくなったのだから満足だ
最悪なのは、この認証方式がユーザーの習慣と期待値をさらに悪化させることだ
1passwordのような現代的なパスワードマネージャーを使えば、メールトークン方式よりずっと簡単で、安全で、速い
数台の端末で初期設定と検証に少し気を配るだけでいい
新しい場所に引っ越してドアの鍵を複製するのと同じで、パスワードマネージャーに保存したあと、別の端末でも同期されていることを確認してはじめて安心できると思う
人はそれくらいできる
暗号化や2FAの概念を知らなくても、「新しいパスワードを作成」をクリックして、アプリが保存してくれるランダムパスワードを使えばいい
パスキーも同じで、保存先を端末内蔵ストレージではなく、バックアップや復旧まで考えて使うべきだ
皮肉なことに、昔ながらの方式（メールアドレスとパスワード入力）のほうがむしろよく機能する
パスワードマネージャーが必ずすぐ自動入力してくれるので、実際にはずっと速い
パスキーはそれよりさらに速くなりうる
私ももどかしいが、私の周囲の非IT職の人の80%はセキュリティについて無知で、半ばあきらめて暮らしているように見える
せいぜいうまくいった例といえば、アカウント情報を小さな手帳に書き留め、パスワードに数字と英字を必ず入れる程度だった
このフローの問題点は理解している
私の経験では、このワンタイムパスワード方式は、私の周りの非ITの人たちにとってはパスワードの次に馴染みのある認証だ
私の住む小さな町では、パスワードマネージャーやパスキーのほうがむしろ難解で、目の前で使い方を説明しても絶対に理解してもらえない
メンタルモデル自体があまりに馴染みがなく、UXも複雑すぎて理解不能なのだ
大衆が直感的に理解できる何かが出てくるまでは、パスワードと「問題だらけの」ワンタイムコード方式が、その単純さゆえに主流であり続けると思う
きちんとしたパスワードを使っていても、パスワードを「忘れたとき」のアカウント復旧方式が同じワンタイムコードのパターンになっている
結局、攻撃者はパスワードを「忘れたふり」をして、その復旧フロー経由でログインできてしまう
私も自分の作ったサービスではログインにワンタイムコード方式を使っている
ただし機密性の高くないサービスなので、認証を厳格にするのが目的ではない
私はこれをICGAFAS("I Couldn't Give A Factor" Auth System)と呼んでいて、そもそもセキュリティをあまり気にしていないことを示している
メールベース認証は管理者側にとっても、SMTP送信や配信の問題など、気を配ることが増える
結局、ブラックリスト入りしたりスパムフィルタに弾かれたりしないようにするには、3rd party relayサービスを使うしかないのが現実だ
多くのサービスが、従来のメール+PWやソーシャルログインの代わりに、このワンタイムコード方式を強制してくるのが非常に不快だ
自分の100文字のパスワードを使わせてほしい
あなたはターゲットユーザーではない
むしろ非常に特殊な少数派に属している
長期的には「多数派」と接続できるソリューションを考える必要がある
100文字のような長いパスワードには意味がないと思う
下層の暗号処理で実際に使われるkey lengthに応じて長さがtruncateされる
NIST文書（NIST 800-63b section 5.1.2.1）で、この認証方式が公式に許容されているか確認してみた
「Look-up Secret Authenticator」と見なすなら、特に問題はない
本来は事前配布された認証コード（復旧コードなど）を指す方式を、リアルタイム送信かつ単一選択で乱用している格好だ
この方式がフィッシングに弱いとは思うが、実際のところ従来のusername/password方式より危険だと断言するのも難しい
たとえば、ユーザーのメールアドレスに6桁コードを送って入力させると、ユーザーはそのコードが本物のログイン用か偽物かを区別できない
ただし攻撃者は、Googleアカウントのようにもっともらしく見えるページでユーザーをだまして情報を盗むこともできる
結局、フィッシング耐性のある認証こそが本当の未来だと思う
今日突然この認証サイクルにはまり込んだせいで、gofundmeアカウントを削除する羽目になった
何年もアカウントを使い寄付もしてきたが、今では携帯電話番号とMFAコードを必須で要求し、拒否する選択肢もない
結局手続きを全部済ませて、アカウントを無効化した
こんな認証は人生に不要だと思うし、gofundmeがなくても生きていける
今ちょうど家を探しているのだが、Zillowアプリも同じようにログインを要求し、届いたメッセージを読むたびに毎回MFAまで要求してくる
1時間でセッションが切れる
こういう認証方式にはうんざりだ
完全に狂った世界だ
Ticketmasterも似たようなことをしている
Google Voiceの番号は認めず、SIMに紐づいた番号だけを要求する
私のSIM番号なんて頻繁に変わる「実装上の詳細」にすぎないのに、今ではその番号がないとアカウントにログインできない
結果的に、こうしたチケット購入をあきらめるか、SIMを変えるたびにアカウントロックアウトを覚悟するしかない
Googleが私のアカウントで2FAを勝手に有効にし、登録されている電話番号が古いものだったせいで完全にアカウントがロックされた状態だ
何の予告もなくサービスがパスワードや二次認証を変えてしまうと、アカウントに紐づいたスマホを持たずに旅行している最中には、永久にアクセス不能になりかねない
多くのサービスは、ローカルのパスワードマネージャーに保存してある20文字のランダムパスワードより、二次認証のほうが安全だと見なしている
だがその二次認証方式というのも、結局はSMSで平文送信、メールで平文送信といった大したことのないレベルだ
この文は4回読んでも理解できなかった
「攻撃者がユーザーのメールアドレスを正規サービスに送って6桁コードを要求すると、当のユーザーはそのコードが本物のログイン用かどうかわからない」といった説明だ