| 項目 | パスワード3文字省略 | ID一部マスク |
|---|---|---|
| 分かりやすさ | ◎ 「先頭3文字まで省略できます」と書けば理解しやすい | ○ 最初は「なぜ隠れているの？」となる人もいる |
| 入力の手間(趣旨とはズレる) | ◎ 毎回3文字少なく入力できる | △ IDを変える場合の面倒さのみ |
| 覗き見対策 | ○ パスワードの一部が見えない | ◎ ID全体が見えない |
| 実装の受け入れられやすさ | △ 独自認証として慎重な評価になりやすい | 〇 一般的なUIとして受け入れられやすい |
操作明瞭性と利便性が下がらない事を優先するか、セキュリティを優先するかの差だと思います。
今回はパスキーは採用しませんでした。パスキーは非常に優れた仕組みですが、サービスや利用環境によっては導入・利用のハードルがあると感じたためです。優れたAPIが多い印象なので、特に利用面です。また、デバイス認証についても有力な選択肢ですが、「どこまでを同一端末として扱うか」や、ブラウザデータの削除・移行時の扱いなど、運用面で考えることが多いと感じました。
「パスワードを3文字も省略できるなんて危険では？」
そう思われるかもしれません。
しかし、実装方法によっては意外なメリットがあります。
今回は、IndexedDBを利用して「このブラウザだけ先頭3文字まで入力を省略できる」仕組みについて紹介します。
仕様
通常のパスワードは自由記述です。
ただし、以下の条件を満たした場合のみ、先頭3文字まで入力を省略可能とします。
- IndexedDBに認証情報が保存されている
- 過去にログイン成功した際にサーバーから取得したランダム値が保存されている。(今回のログイン時に誤っているならばリジェクト)
- 時間経過での実行を含むログアウト時の設定として、この機能を足せる設定を加える(標準はOFF推奨)
初回アクセス時の流れは次のようになります。
- ログイン成功したらサーバーがindexeddb保存用の6文字を返却(サーバー側に6文字が無ければランダムな6文字(Base62)を生成してサーバーに保存して返却)
- レスポンスを見てブラウザのIndexedDBに保存
次回ログイン時は、IndexedDBに保存されていれば「先頭3文字まで省略可能」とします。
サーバー側は
- サーバーの値
- 送られてきたIndexedDBの値
を比較し、一致した場合のみログイン成功にします。
サーバー側での判定
サーバーには通常のパスワードハッシュとは別に、
- 1文字省略後のハッシュ
- 2文字省略後のハッシュ
- 3文字省略後のハッシュ
- (先ほどのランダムな6文字)
の3種類を保持します。
ランダムな6文字が合っている場合のみ、それらを用いて認証します。
つまり、通常は完全なパスワード認証を行い、信頼済みブラウザと判定された場合だけ入力文字数を減らします。
省略する3文字をそもそも記憶するのは、実装は容易になりますがデータベース漏洩リスク的に避けるべきです。indexeddbの6文字の流出の方がマシであるためです。ハッシュの作り方がサーバー側のため、被害はそちらのほうが少ないのです。
「弱そう」に見える理由
確かに見た目だけでは、
パスワードを3文字も削れるなんて危険そう
と思います。
実際、この方式は認証強度そのものを高めるものではありません。
しかし、この方式には一つだけ大きなメリットがあります。
最大のメリット
覗き見に少しだけ強くなることです。
例えば、
- 電車内でログインしている様子を録画された
- 後ろからキーボード入力を見られた
- 記憶力の良い人に入力内容を覚えられた
このようなケースでも、
実際に入力された文字列だけでは、本来のパスワードが完成しません。
さらに、別ブラウザや別端末ではIndexedDBの情報が存在しないため、省略入力は容易ではありません。
つまり、画面を見られただけならば、そのままログインされる可能性を下げられます。
先頭の0文字〜3文字を削ったパスワードの削った部分の推測は、ログインを挑戦する回数に効力の強い制限がある場合、たまたま覗き見したレベルの人
からすると突破は難しいと考えます。
プログラマーであれば仕組みを理解して推測することはできますが、一般的な覗き見攻撃に対しては一定の効果が期待できます。
第2パスワード方式との比較
メリット
- 第2パスワードを覚える必要がない
- パスワードを2つ管理する必要がない
- 認証できるパスワードが1種類で済む
デメリット
- サーバーに省略後ハッシュを複数保存する必要あり
- セキュリティ面では劣る
セキュリティコードを表示しない方式との比較
よくある方法として、
IndexedDBが存在する場合だけ6桁のセキュリティコード入力欄を非表示にする
という実装もあります。
しかし、この方法では、
- 6桁コードを覚えておく必要がある
- 新しい端末では結局入力が必要になる
という問題があります。
一方、先頭3文字省略方式は、
「覚える情報を増やさず、入力だけ減らせる」
という点が使いやすいと感じました。
この方式が防げるもの・防げないもの
防げる可能性があるもの
- 覗き見
- 電車などでの盗み見
- キーボード入力の録画
- 肩越しの監視（Shoulder Surfing）
防げないもの
- XSSなどでブラウザ内情報が取得される攻撃
- IndexedDBが盗まれる状況
- マルウェアやキーロガー
- パスワード総当たり攻撃（通常のパスワード強度に依存）
まとめ
基本的にログイン画面では、回数上限やボット対策、追加認証などを除けば、同じ入力内容に対して同じ認証結果が返ります。
そのため、Aさんが入力したIDとパスワードをBさんが覗き見し、同じ内容を入力できてしまうと、そのままログインに成功する可能性があります。
今回の方式は、この「見えた入力内容をそのまま再現される」問題を少し崩すための工夫です。
また今回の方式は、
「認証を強くする技術」ではありません。
パスキーや多要素認証が問題なく使える状況であれば、そちらの方が有益である事は確かです。
一方で、
「通常のパスワード認証の強度を大きく下げずに、信頼済みブラウザだけ入力を少し楽にしつつ、覗き見には多少強くする」
という目的には面白いアプローチだと思います。
indexeddb側を取得できた場合は、0〜3文字少ない文字数で4通り通過できるため、覗き見以外のセキュリティ面は間違いなく下がります。
それでも認証強度を大きく下げずに、ユーザー体験を少し改善したい場合の選択肢として検討する価値はありそうです。
ユーザー側がパスワード管理ツールを使う場合は、省略設定をONにしない。または省略しなければOKです。
補足
ID入力欄が自動入力される状況では、パスワードの一部省略よりも、IDの一部を隠して表示する方法も検討して下さい。
今まで紹介したように、パスワード欄に「このブラウザでは先頭3文字まで省略できます」といった但し書きを表示する方式の方が、利用者にとっては操作内容が分かりやすく、利便性も高いと思います。
| 項目 | パスワード3文字省略 | ID一部マスク |
|---|---|---|
| 分かりやすさ | ◎ 「3文字省略できます」と書けば理解しやすい | ○ 最初は「なぜ隠れているの？」となる人もいる |
| 入力の手間 | ◎ 毎回3文字少なく入力できる | △ IDを変更しない限り恩恵は少ない |
| 覗き見対策 | ○ パスワードの一部が見えない | ○ ID全体が見えない |
| 実装の受け入れられやすさ | △ 独自認証として慎重な評価になりやすい | ◎ 一般的なUIとして受け入れられやすい |
ID入力欄を隠すのは、恐らくHTML側を少し修正するだけで実装できるため、実装も簡単です。
実装方法としては、画面に表示・出現する入力欄と送信用のhidden入力欄を同期しておくのが扱いやすいでしょう。利用者がIDを変更した場合は、表示用入力欄の内容をhidden入力欄にも反映させることで、画面表示と送信内容の不一致を防げます。
例えば、メールアドレス形式のIDであれば、@より前の文字列について、「3文字」または「文字数の3分の1」のうち大きい方を先頭から隠します。Googleログインレベルで上手く隠せるのがベストです。利用者が別のIDに変更したい場合のみ、「変更する」ボタンを押して入力欄を編集できるようにします。
この方式であれば、覗き見された場合でもID全体を知られにくくなり、通常利用時には自動入力の利便性も維持できます。パスワードそのものを短く扱うよりも、金融系など慎重な設計が求められる場面では受け入れやすいと思います。個人的には、金融系ならこちらの方がかなり現実的です。パスワードを弱く見せないまま、覗き見対策とUX改善を両立しやすいです。
少し過剰な対策かもしれませんが、IDとパスワードの両方について、見えている部分から隠された部分を推測されやすい問題を減らしたい場合は、これらを併用するのも悪くないと考えています。