「メールが認証」パターン
(rubenerd.com)- 一部のユーザーは、パスワードを覚えたり管理したりする代わりに、毎回「パスワードを忘れました」手順をログイン方法のように使っている
- 実際の流れは、ログインページで復旧リンクをメールで受け取り、一時パスワードを入力し、次の訪問時にも同じ手順を繰り返す構造になっている
- この習慣は、意識的なセキュリティ戦略というより、時間の経過とともに固着した学習された行動に近い
- パスワードマネージャーや2段階・多要素認証といった改善策も、ユーザーにはセキュリティ強化より摩擦の増加として感じられることがある
- システム設計はユーザーの反復行動を前提にしつつ、より良い利用方法へ自然に移行できるよう導く必要がある
ログインのように使われるパスワード復旧
- 一部のユーザーは、オンラインアカウントにログインする際、パスワードを入力せず、毎回復旧手順を繰り返している
- ログインページにたどり着く
- 「I forgot my password」をクリックする
- メールを開く
- 復旧リンクをクリックする
- 覚えるつもりのない一時パスワードを入力する
- その後も同じ手順を繰り返す
- なぜそうするのか尋ねても答えられなかったり、理由を考えたことがないと反応したりする
- この行動は、その朝に決めたログイン戦略ではなく、時間とともに固まった反復手順に近い
セキュリティ改善がユーザーにもたらす摩擦
- この方法は、ユーザーがパスフレーズを記憶しなくてよい低労力の解決策として機能する
- パスワードマネージャー、アイデンティティ盗用、2段階認証と多要素認証、ユーザー名/パスワード方式の老朽化は、すでに広く議論されてきたテーマである
- より良いセキュリティ手順は、しばしば障壁や摩擦を増やし、ユーザーが自然に受け入れにくくなることがある
- 設計者はユーザーの学習された行動を考慮し、時間の経過とともにより良い利用方法へ移行できるフローを作る必要がある
1件のコメント
Hacker News のコメント
メールアカウントは、オンライン認証における最も普遍的な共通分母です。携帯電話も有力ですが紛失する可能性があり、電話番号はより一般的で長持ちするものの、セキュリティ水準は主要なメールプロバイダーのアカウントよりはるかに低いです。
「インターネット向けの想像上の認証システム」を設計するなら、まずアカウント復旧から見るべきです。立派な認証器をなくしたときの答えが「単にアクセスできない」や「同僚のパネルが身元を保証する」なら、そのシステムは人間ではなく、想像上の知的生命体をユーザーにしないと機能しません。
人間は失敗から復旧できなければなりません。
普通の人間にも機能するようにできるでしょうか？十分に設計できるだけの創造力はあると思います。
私たちのサービスはかなり軽い性質のビジネスなので、ユーザーは便宜上アカウントを使うだけです。落ち着いた方式はこうです。ユーザーがメールアドレスを入力し、メールで認証コードを送り、ユーザーがコードを入力すると、事実上無期限にログインされる非常に長い Cookie を発行します。
既存アカウントかどうかは重要ではなく、新しいメールアドレスなら新しいアカウントを作ればよいのです。複数のメールアドレスを持つユーザーが誤って新規アカウントを作ることは時々ありますが、登録とログインのコンバージョン率が大きく改善したので、許容できます。コードの有効期限と試行回数にはリスク分析が必要で、可能ならロック機構を使うのがよいです。サービスがそれほど重要でないなら、この戦略をおすすめします。iOS Mail も今では Messages のワンタイムコード機能のようにこの方式をサポートしているので、一部のユーザーにはかなり便利です。
購入者にアカウントを強制せず、詳細情報だけ求めればよいのです。どうせブラウザが自動入力します。その後、注文状況確認リンクをメールで送り、次の注文時にまたメールアドレスを尋ねればよいです。追加の摩擦は、「登録ユーザー」を得る利点より大きな売上損失を生みます。
別の端末でログインする必要があるときだけ、新しいパスワードを要求できます。こうすると登録時の摩擦と弱いパスワードが減ります。ほとんどの人は、どうせ別端末でログインすることがほとんどありません。
匿名性を保つ必要がある領域でなければ、これで問題なく、後でパスキーを統合すればよいです。欠点はパスワード共有ができなくなるため、1つのアカウントに複数ユーザーを管理する問題をより早く考えなければならないことです。ただし意識的に扱えば、ファネルやユーザー体験は最終的に良くなります。またセキュリティはユーザーのメールプロバイダー群の平均的なセキュリティ水準に縛られますが、通常は必要な水準より優れています。パスワードは後で必要になったときに第2要素として使うか、別の要素を追加できますし、B2B ならすぐに SAML や OIDC に進めます。B2B や D2C では常にうまく機能し、例外的な状況も獲得上の利点があるため解決する価値がありました。
コードをコピーし、ログインページを開いたタブを探し、貼り付けるプロセスが面倒です。
ここまで来ると、メールアドレスにワンタイム URL リンクを送り、1クリックでログインできるようにすればよいのではないでしょうか？10分以内に期限切れになり、1回使ったら破棄されるようにすればよいです。
もちろん最初にリンクを持った人は誰でもそのアカウントにログインできますが、どうせメールからしかアクセスできません。メールアカウント以上のセキュリティ感覚はすべて吹き飛びますが、現実はすでにそこまで来ています。携帯メッセージで「ログイン認証するにはクリック: http://someurl.com/?p=134234535」のようなパターンを使えば…
メールがスパムに入ったり、グレーリスティングのせいで何時間もログインできなかったり、到着まで1分かかるだけでも長すぎると感じることがあります。おすすめするかはよく分かりません。
携帯電話に送る「ログイン認証をクリック」は、コードとリンクの両方を提供すべきです。常にログインする端末が携帯電話とは限らないので、「1234を入力、またはクリック」であるべきです。
ただし、パスワードマネージャーがユーザー名／パスワードの組み合わせを自動入力するより遅いです。メールを待ってリンクを押す必要があるからです。
Gmail のアプリ内ブラウザにログインしたいのではなく、通常のブラウザにログインしたいので、かなり厄介です。
「メールでリンクを送る」より「Google でログイン」ボタンのほうがよく、どちらにしても追跡は可能です。
人間が、取るに足らないサービスごとにパスワードを作って覚えるという考えは現実的ではない。もう一つパスワードベースの認証システムを作るのは、一種のごっこ遊びに近い。
パスワードは通常、2つの方式のどちらかで使われる。1つの実際のパスワードで保護されたパスワードマネージャー、またはサービスごとに繰り返される同じパスワードだ。ほぼすべてのサービスがメールでの復旧を提供しているので、実際には メールが認証手段 である。個人メールはあまり変えず、共有せず、再利用もされない。おそらく個人メールは電話番号より長く使っている可能性が高い。現在のメールアドレスを使っている間に電話番号は少なくとも5回変わり、その番号は今では別の人たちが使っている。
そしてパスワードリセット機能は、少なくともアドレスの所有者にすべての試行を知らせてくれる。パスワードベースのログインは、新しい場所からログインするたびに必ずメールを送るわけではない。
答えは単純だ。たいていはサービス提供者がユーザーのために作っておいた不便さに関係している。この場合は明確に見えるが、メールプロバイダーのセッションは通常、事実上終了せず、ブラウザのキャッシュを消さない限りログインしたまま残る。
自分のサービスの認証トークンもGmailと同じ寿命にし、代替手段として毎回 ワンタイムパスワード でログインできるようにすればよい。だが12時間の認証トークンのような冒涜的な慣行はやめるべきだ。そうすればユーザーは二度とパスワード復旧でログインしなくなるだろう。
以前、EpicとSpotifyのアカウントで問題があった。アカウントを作って1週間使うとセッションが切れ、Spotifyがアカウントから追い出す。ログインしようとするとパスワードが違うと言われるが、パスワードマネージャーに保存されているのであり得ない。結局メールでリセットするしかない。最初の数回はメールを受け取ってリセットしても同じパターンが繰り返され、3〜4回を過ぎるとメールすら来なくなり、新しいアカウントを作らなければならなかった。今はGoogleアカウントでSpotifyにログインして使っていて、まだ問題はない。だが通常のメールで使うと、彼らの認証システムは単に機能しない。
問題は、リスクを測定し、「このサイトに本当に2要素認証が必要なのか？」「30分のセッション時間は合理的か？」を判断するための一貫した言語が不足していることだ。最新のアンチウイルスがあれば、大半の人はログイン状態を維持したいだろう。あるサイトの問題を直すためにCookieを全部消してくれと頼まれたことがあるだろうか。私の答えはいつも拒否だ。「アカウントはあなたのもので、ログイン状態を維持してハッキングリスクを負うなら、それはサービス運営者ではなくあなたのリスクだ」と言われたことがあるが、ますます同意するようになっている。ノートPCがログインされた状態で誰かがEC2インスタンスを全部削除したなら、それはもっと早くログアウトさせなかったAWSのせいではなく、あなたのせいだ。AWSにはできるだろうが、なぜそうする必要があるのか。不注意な1人を守るために100万人を苛立たせる理由はない。
パスワードリセットの手順をなくす、あるいはパスワード自体をなくしたサイトを見たことがある。メールが認証 である。
メールアドレスを入力し、コードが入ったメールを受け取り、コードを入力してログインする方式だ。なぜこうするのかは理解できるが、複数のメールを使っている立場としてはかなり嫌だ。どのメールを使うべきか覚えるために、パスワードマネージャーにメールとメモを入れなければならず、パスワードのない項目のように残る。
まともなログインシステムも作れないなら、約束した機能を提供する実力も不足している可能性が高いと思う。マジックリンクは、もはや面倒を超えてフィルターになった。
あまり使わないサービスのパスワードを覚えろという負担がなく、会社のオンボーディングも楽になる。会社がユーザーCSVをアップロードすると、ユーザーはパスワードを作成し、確認し、ルールに合わせる過程なしにすぐ作業を始められる。メールリンクは好まない。スマホアプリのプレビューや企業のウイルススキャナーなどがリンクを「クリック」してしまうからだ。
両方を提供したとしても、パスワードを要求しつつメール確認までさせると、登録フローでより多く離脱しそうだ。さらに、パスワードと複数のメールログインフローを処理しなくてよいので、コードもずっと単純になる。
バウチャーをメールと紐付ける必要があるので、後でバウチャー紛失によるサポート問題が起きたときに備え、リンククリックで所有を確認する必要があった。その後アカウントを作れば、以前受け取ったバウチャーも見られる。
この記事を読んで初めて、自分が Best Buy でまさにこの方式を使っていることに気づいた
意図したわけではない。1Password にパスワードが保存されているので正しいはずだと分かっているのに、bestbuy.com で何かを買おうとするたびに何らかのアカウント乗っ取り防止に引っかかり、パスワードが間違っていると嘘を言われる。こちら側の問題かもしれないとは十分思っている。広告ブロッカーやローカル DNS ブロックのようなものかもしれない。ただ、何度か繰り返すとデバッグする気が失せて、結局いちばん抵抗の少ない道を選ぶようになる
maxlengthが違うケースは非常によくあるたとえばパスワード変更時に60文字のパスワードを入力したのに、ログインページの最大長が40文字なら、ログイン時に「パスワードが違います」になる。なので私は今では、アプリケーション設定に最大長を保存し、すべてのパスワードフィールドへ伝播させる方針にしている。確認してみると、実際に長さの不一致がある。パスワード設定フォームは
maxlengthが54だが、ログインページにはmaxlengthがない。したがって、パスワードが54文字を超えていて、1Password が保存済みパスワードを自動で54文字以下に切り詰めないなら、ログインできないほとんどの人にとって、コンピュータ作業とは、なんとなく動くまで力任せに繰り返し試すことだ。ソフトウェアは下層のシステムを細かく理解している人たちが作るが、そうした理解を持たない人たちのために作られている
ユーザーは一度うまくいくパターンを見つけると、そこに留まる。今では多くの学校が教育にタブレットを使うようになっており、この傾向はさらに強まっている。コンピュータがどう動いているのか感覚をつかみにくい。大半の人は深く考えない。ただそこにあり、もともと壊れているものに慣れているのだから、クリックが数回増えるくらい大したことではない
大げさに言えば、ログインフローは同じだ
A) Webサイトに行き、パスワードマネージャー経由でランダム文字列をコピー＆ペーストし、本人確認のためにメールで届く TOTP リクエストを受け取る。あるいは B) Webサイトに行ってパスワードを忘れた場合のリンクを押し、ログインリンクを受け取ってからランダム文字列を入力する。多くの場合、B のほうが実際には速く、ほとんどの場合で遅くもない。「記憶する」チェックボックスは何の効果もない
自分のフローはこの2つより良いと思う。サイトに行くと Safari が自動入力を提案し、TouchID/FaceID を使い、2段階コードを求められる。SMS やメールで届けば Safari が自動入力を提案する。TOTP 方式でも Safari が自動入力してくれる。とても簡単だ。パスキーは2つ目のステップと SMS/メール待ちがないので、さらに簡単だ
動機はすぐ理解できる。「パスワードを忘れた」を使えば、パスワードを覚える必要がない。そしてアカウントのセキュリティがさらに弱くなるわけでもない。どうせその経路は攻撃者にも開かれていたからだ
一部のWebサイトはこれを基本フローにしており、誰かにログインボタンをメールで送れるなら、パスワード自体が無意味だと暗に主張している。個人的には嫌いだ。メールを信頼していないし、何十ものアカウントの単一障害点になるのも嫌だ。第2要素だけでログインできるなら、それは2段階認証ではない。リセットオプションなしでパスワードでログインしたいが、現実はそうではない