マジック／トラジックメールリンクを唯一のログイン手段にしてはいけない
(recyclebin.zip)- メールでログインリンクを送るマジックリンクは、パスワードのフィッシングや使い回しパスワード流出のリスクを減らせるが、唯一の選択肢になるとログイン時の摩擦がそのままユーザーに転嫁される
- 複数のコンピューターを使ったり、仕事用と個人用の機器を分けているユーザーは、メールを受け取った端末とログインしたいブラウザーが異なり、フローが簡単に途切れる
- SMTPの遅延やリンク受け渡しの過程により、ログインは2秒から数分まで遅れることがあり、アプリ内ブラウザーやRSSリーダーアプリではモバイルでの使い勝手も損なわれる
- メールやSMSで受け取ったOTPを直接入力する方式も面倒ではあるが、メールクライアントとブラウザーの間でリンクを移しにくいときは、マジックリンクより良い場合がある
- マジックリンクをデフォルトにする場合でも、技術志向でプライバシーを重視するユーザー層には、passkeysのような堅牢な代替手段もあわせて提供すべき
マジックリンクが不便になる状況
- 「Magic Links」は過去には未来的なPDAを指したが、現在ではAuth0のような企業がメールに含まれるログインリンクを指す際に使う言葉である
- 404 Mediaは「We Don’t Want Your Password」でマジックリンクを擁護し、メールリンクはパスワードよりフィッシングされにくく、パスワード漏えいにもつながらず、漏えいしたパスワードの使い回しリスクも減らせると見ている
- 単一のノートPCとモバイル端末中心の生活では簡単に見えても、複数の端末やブラウザーを使うユーザーには複雑さがそのまま押し付けられる
- 不便な例:
- 複数端末: ゲーム用PCや仕事用ノートPCに個人メールを入れていないユーザーは、ログインリンクをすぐに開きにくい
- 速度: SMTP遅延と正しいブラウザーへリンクを移す過程のため、2秒から数分まで遅くなることがある
- モバイル: アプリ内ブラウザーの利用で挙動が崩れ、RSSリーダーアプリでローカルリンクを扱いにくくなる
- セキュリティ: 個人メールを仕事用端末で開かせたり、その逆を促したりするフローは、セキュリティ上の利点とは言えない
代替手段と最低限の補完
- メールまたはSMSで受け取ったOTPを直接入力するpasswordless方式も不便ではあるが、メールクライアントからログイン先ブラウザーへリンクを簡単に移せない状況では、より実用的なことがある
- StratecheryはPassportを通じてリンククリックまたはOTP入力を提供しており、passkeysの実装なしに不便さをユーザーへ転嫁している限界はあるものの、マジックリンク単独よりはユーザー状況を考慮している
- マジック／トラジックリンクをデフォルトとして固執するにしても、passkeysのような堅牢な代替手段をあわせて提供するほうがよい
- Ricky MondelloのMagic Links Have Rough Edges, but Passkeys Can Smooth Them Overは、passkeysでこの問題を緩和する方法を扱った参考記事である
1件のコメント
Hacker News の意見
マジックリンクでアプリを作っていて遭遇した問題：ユーザーがメールにアクセスしにくい端末でログインしなければならない場合があるので、代替ログインコードをマジックリンクに含める必要がある。
また、メールクライアントがプレビュー用スクリーンショットを作るためにリンクを自動で開くケースに対処する必要があり、ユーザーが好むブラウザではなくアプリ内ブラウザで開くメールクライアントも考慮しなければならない。
たとえば iOS ユーザーが Firefox モバイルを好んでいても、メールアプリが Safari ベースのアプリ内ブラウザで強制的に開くことがある。
ワンタイムコード入力ページへ誘導する方式なら、こうした問題の多くを避けられると思う。
最近、新しいメールアカウントが自動的に確認済みになり、ユーザーがクリックする頃にはマジックリンクがすでに無効になっている問題に遭遇したが、Microsoft が検査中にそのリンクで先にログインしていたのが原因だった。
McDonald's がメールアドレス/パスワードからマジックリンクに切り替えた後、McD アプリでリンクを動かすのが本当に難しく、たいてい McD のウェブサイトだけが開いた。
McD を食べるときの 98% くらいは、アプリで注文できないなら食べない派なのでかなりイライラし、結局 “Sign in With Apple”(SIWA) に乗り換えた。
既存の McD アカウントに SIWA を追加する方法が見つからず、実際のメールアドレスを McD に隠す SIWA を使うしかなかったため、新しいアカウントが作られて以前のアカウントのリワードポイントは失ったが、少なくとも再び McD アプリは使えるようになった。
アプリには毎週金曜日、1ドル以上の注文で “Free Medium Fries on Friday” というディールがあるので、金曜の昼ごとに家でサンドイッチを作り、McD でクッキーと無料のフライドポテトを受け取って添えることにしている。
そこで会社のコンピューターでマジックリンクを受け取り、QR コードを作ったのだが、メール隔離システムがリンク全体を書き換えていたため、元のリンクを抽出する必要があった。
それで終わりではなく、Slack に戻るリダイレクト URL が URL エンコードのせいで壊れていたので、自分で直してから QR コードを作らなければならなかった。
そもそも元のマジックリンクメールにQR コードやコードを一緒に入れてくれれば済む話だ。
コードを入力するようにした瞬間、その利点は完全に消え、攻撃者はコードを要求する偽サイトを作るだけでよくなる。
マジックリンクはクリックした端末でログインされるべきで、ログインセッションを要求した端末でログインされてはいけない。
それ以外の方式は少し面倒が減るかもしれないが、セキュリティ上の問題であり、そのように扱うべきだ。
数年間マジックリンクを使ってきたし、MVP 段階でユーザーパスワードを保存するというセキュリティ上の負担を避けたい理由もあった。最大の問題は、一部のユーザー、約 0.1% がメールをまったく受け取れないこと。
自前 IP、MailGun、PostMark、複数のトランザクションメールツールを順番に再試行する方式まで試したが、それでも絶対にログインできない人たちがいる。
さらに、ユーザーが 6 か月前のマジックリンクをクリックして「動かない」と不満を言うので、エラーメッセージの代わりに Docusign のように状況を説明し、リンクを再送するページを表示することにした。
メールアドレスをよく打ち間違えたうえでコードを受け取れないと、システムのせいにする人もいる。
それでもメールアドレス+パスワード方式よりサポートチケットははるかに少ないと感じているので、今でもマジックリンクを好んでいる。
マジックリンクは使ったことがないが、数か月前に SaaS に Google Sign in を追加したところ、新規登録の 90% 以上を占めるようになった。
ユーザー層は開発者なので技術理解度もプライバシー感度も高い方なのにそうで、今は他の方式が優先事項だとは思わない。もちろんメールアドレス/パスワードは引き続き維持している。
パスワードマネージャーと併用するユーザー名+パスワード、またはパスキーが、HTTPS 上で一般ユーザーに良いユーザー体験を提供しつつ、認証情報をエンドツーエンド暗号化方式で交換するほぼ唯一の方法である可能性が高い。
パスワードマネージャーは、認証情報が正しいドメインでのみ使われることを保証してくれる。
Mercuryの忠実な顧客だったが、安全なパスワードとパスワードマネージャー、有効なTOTPまで通過した後でも、IPアドレスが変わるたびに3つ目の認証要素としてマジックリンクを強制されるため、会社の銀行を他へ移すことまで考えるようになった
過去5年間使っていた場所やISPではない場所からログインするなら理解できるが、昨日ログインした時と違うのがDHCPアドレスの最後のオクテットだけなら、筋が通らない
メールはWebブラウジングとは別のコンピューターでSSH経由で読んでいるので、数百文字のログインリンクをコピー＆ペーストするのは本当に苦行だ
Emacsでは複数行にまたがって表示されるため、行境界の
\も手で取り除かなければならないログインのたびに摩擦を増やすと、アプリ内で続くすべてのやり取りの印象が悪くなり、使いたくなくなる
以前使ったデバイスであれば、デバイス確認の要求は出ないはずです。その確認のために永続Cookieを保存しており、同じIPでも要求しません。もしかするとCookieが定期的に削除されているのか気になります
この機能は、攻撃者たちがhttp://mercury.comの複製サイトを作り、Google広告まで出した後に追加したものです
顧客がフィッシングサイトにパスワードとTOTPを入力すると、フィッシャーはその認証情報でログインして仮想カードを作り、暗号資産や金などを購入し、ユーザーを本物のMercuryへリダイレクトして一時的なエラーだと思わせることを狙っていました
私たちが送るこのデバイス確認リンクは、リンクを開いたIP/デバイスを承認するもので、この方法でフィッシャーをほぼ完全に防げました
WebAuthnはこうしたフィッシング攻撃に耐性があるため、WebAuthnを使っている場合はデバイス確認を要求しません
可能であれば、TouchID/FaceIDまたはデバイスごとのWebAuthnを強くおすすめします。より便利で、より安全で、ここから追加できます: https://app.mercury.com/settings/security
ただし社内でこの記事について議論しており、IPv6がさらに普及すればIPがはるかに頻繁に変わるようになることも認識しています。同一IPマッチングの制限を緩和すべきか検討してみます
先週の404の記事への反応として、とても良いと思う。404は好きだが、筆者が述べたのと同じ理由でマジックリンクはうっとうしい
Ricky Mondelloが先週書いた記事[1]は、記事の終わりで示唆されているように、パスキーがマジックリンクと併用できることをよく説明していて、読む価値がある
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
ストアにログインしようとすると、メールで送られた2段階コードを入力するよう求められ、数分待ってもメールが来ないので新しいコードを要求しても来ず、諦めて別のことをしていると30分後に2つのコードが両方届く、ということがよくあった
実際、メールはどれほど条件が良い時でも信頼しにくい。迷惑メールフォルダに入ったり、会社のスパムフィルターがリンクをブロックしたり、受信トレイがいっぱいになったりすることもある
個人的にはメールはiPhoneにしかなく、会社のノートPCやゲーム用PCではicloud.comにログインしないと確認できないので面倒だ
パスワードを入力させてくれるか、組み込みデバイスのようにQRコードをスキャンさせてくれるか、少なくとも別の選択肢を1つは用意してほしい
マジックリンクはパスキーにアクセスできるようにし、パスキーは基本的に「このコンピューターを記憶する」の強化版だ
今でもApple側の人たちが公の場でほとんど見えなかった時代に慣れている
何か誤解しているのかもしれないが、パスキーが実際にマジックリンクの代替になるわけではないように思う
これまで見たすべてのパスキー実装では、別の方法ですでにログインした後にパスキーを作成するよう提案していた
深く掘り下げたわけではないが、ユーザー体験上、パスキーはパスワード全般の代替というより、「このコンピューターを記憶する」ボタンの代替のように見える
何らかの形で、サービスはこの新しいデバイスが承認されたという事実を知る必要がある
プロバイダーによってはパスキーの同期があるものの、最初の認証をどうするかは解決していない
マジックリンクの核心的な洞察は、セキュリティシステムは復旧メカニズムより強くはなれないということだ
パスキーだけが唯一の認証手段として扱われる世界は来ないだろうし、常に復旧メカニズムは残り、その大半はメールによる自動復旧になるだろう
ならばマジックリンクは、その上により安全な層があるかのように装わず単純化している点で正直だ
復旧メカニズムを認証フローの主なやり取りの手段にすれば、認証システムの実際のセキュリティ水準についてより率直になるということだ
編集: filmgirlcwが、2つの方式が実際にどう補完し合うかを説明する、より良い記事へのリンクを残している: https://news.ycombinator.com/item?id=42628226
マジックリンクにも利点はあるが、メールをより強力な攻撃ベクトルにすることが利点なのかは分からない
パスワードマネージャーを使っている人にとって、マジックリンクは明らかな摩擦点であり、パスキーはそれを確実に減らせる
パスキーのユーザー体験上の問題にも改善の余地があり、エクスポートが可能になればシステム間の同期ははるかに良くなるだろう
1Passwordを標準のパスワード・パスキーシステムとして使っている理由の1つも、デバイス間でパスキーを使えることにあり、会社でも1Passwordを使っているので、個人アカウントと企業アカウントにログインしておき、必要なら個人用または業務用デバイスから認証できる
ただし、404が定義した問題が、パスワードや認証制御の保存責任を負いたくないというものなら、一部のユーザーにとってはパスキーのほうがマジックリンクより良いと思う
それでもRickyと同じく、どちらか一方ではなく両方であるべきだと思う
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
パスキーを使うからといって、必ず代替ログイン方法が必要になるわけではないが、まだどのサービスもパスキー専用には移行していない
古いOSやLinuxユーザーは、まだパスキーを生成して保存できない場合があり、多くのユーザーはクロスプラットフォームの資格情報マネージャーを使っていない
たとえばiCloud Passwordsでパスキーを作った場合、現時点ではLinuxからログインする方法がない
あと数年もすれば、サービスが最初からパスキーを作らせ、パスワードはまったく収集しないフローが見られるようになると思う
パスキーのポータビリティ仕様が実装され、Gnome/KDEもパスキー対応を実装してほしい
業務用PCでWebサイトを訪れるときにスマートフォンのOTPを使ったり、スマートフォンからリンクをコピーしたりするのが苦痛なら、業務用コンピューターをノートPCなどにある個人用パスキーと連携させることが、どれほど簡単で良いのか疑問だ
認証にマジックリンクしか対応していないサービスは使わない。ユーザーに非常に敵対的で、セキュリティの観点でもパスワードマネージャーと併用するパスワードより明らかに悪い
最も致命的なのは、私の個人設定ではそもそも動作しないという点だ
セキュリティとアカウントの安全のため、ログインに使うデバイスではメールアカウントにアクセスしないからだ
AnthropicだけはClaudeが最高のLLMなので例外にしているが、再ログインが必要になるたびに非常に苦痛で、何度も不満を送っている
マジックリンクを見るたびに、いつも「そもそもメールのリンクはクリックしてはいけないのではなかったか？」と思う
メールのリンクを思い浮かべると、フィッシングも一緒に思い浮かぶ
マジックリンクが本当に嫌いだ
重要なのは、疑わしいリンクをクリックしないことだ。マジックリンクが送信されたと分かっているなら、疑わしいリンクではない
それでも遅延があるのでマジックリンクは嫌いだ
Appleのメールプライバシー保護の方式は興味深そうだ。Appleが常にすべての画像を読み込む方式だが、欠点があるのかは分からない
私が見た中で最も良い実装は、メールを受け取ったデバイスでリンクをクリックする必要はあるものの、セッションをそのデバイスに移すのではなく、最初にログイン手続きを開始したデバイスでログインを完了させる方式だった
より良い解決策は、リンクを開いたデバイスでのみログインできるようにし、デバイス間で使うために、受信デバイスで読んで元のデバイスに簡単に入力できるOTPコードも提供すること
あるいはリンクなしでOTPコードだけを提供してもよい
あるブラウザで作業中なのに、メールを開くとデフォルトブラウザで認証されたり、さらに悪い場合は別のデバイスで認証されて、そちらにリンクを転送してから開き直さなければならなかったりすることほど嫌なものはない
特定のデバイスでは特定のメールにアクセスしたくない場合もあるので、変なシナリオというわけでもない
サイトが
crazy-pink-horse-3837のようなOTPを送って、コピー＆ペーストできるようにする方式は、元のリクエストを認証するリンク実装が難しすぎるなら、悪くない落としどころだただ、その実装の問題は、送られてくるマジックリンクがクリックトラッカーでラップされていて、そのドメインがPi-holeのようなツールにブロックされることだった
そのため、実際の認証URLに到達してログイン手続きを完了できなかった
アプリ内ブラウザはなくなるべき。特に「通常のブラウザで開く」を選べないアプリ内ブラウザはなおさらで、RSSリーダーなら当然その選択肢を提供すべき
ユーザーにアプリ内ブラウザを強制したプロダクトマネージャーは全員刑務所に送るべき
はるかに良い選択肢は、メールで送るOTPコードとConditional Mediation UIを使うパスキー
ユーザーがすでにパスキーのあるデバイスでログインするなら、CM UIですぐに選択させて即座にログインできる
パスキーがないデバイスならメールコードを入力させ、成功したらすぐにパスキーを設定して、次回からすぐログインできるようにするユーザー体験を設計できる
こうすれば、既存デバイスではパスキーのセキュリティが得られ、新しいデバイスではパスワードレスなセットアップとアカウント復旧が得られる
おまけに、クラウドプロバイダーがすべてのパスキーを持つベンダーロックインも避けられる