| 項目 | パスワード3文字省略 | ID一部マスク |
|---|---|---|
| 分かりやすさ | ◎ 「先頭3文字まで省略できます」と書けば理解しやすい | ○ 最初は「なぜ隠れているの？」となる人もいる |
| 入力の手間 | ◎ 毎回3文字少なく入力できる | △ IDを変える場合の面倒さのみ |
| 覗き見対策 | ○ パスワードの一部が見えない | ◎ ID全体が見えない |
| 実装の受け入れられやすさ | △ 独自認証として慎重な評価になりやすい | ○ 一般的なUIとして受け入れられやすい |
操作明瞭性と利便性が下がらないことを優先するか、セキュリティを優先するかの差だと思います。
今回はパスキーは採用しませんでした。パスキーは非常に優れた仕組みですが、サービスや利用環境によっては導入・利用のハードルがあると感じたためです。また、デバイス認証についても有力な選択肢ですが、「どこまでを同一端末として扱うか」や、ブラウザデータの削除・移行時の扱いなど、運用面で考えることが多いと感じました。
「パスワードを3文字も省略できるなんて危険では？」
そう思われるかもしれません。
しかし、実装方法によっては意外なメリットがあります。
今回は、「このブラウザだけ先頭3文字まで入力を省略できる」仕組みについて紹介します。
仕様
通常のパスワードは自由記述です。
ただし、以下の条件を満たした場合のみ、先頭3文字まで入力を省略可能とします。
- 信頼済みブラウザと判定されている
- 利用者がこの機能を有効にしている
- 入力された省略後パスワードがサーバー側の認証情報と一致する
信頼済みブラウザは、例えばID欄が自動入力される状況を思い浮かべて下さい。(自動入力されたID以外でのログインでは第2パスワードを使えません)
標準ではOFFにしておき、利用者が必要に応じて有効化する形がよいと思います。
信頼済みブラウザの判定方法は、実装環境やサービスの要件によって変わります。
そのため、この記事では特定の判定方式には踏み込みません。
利用する場合は、各サービスの設計方針に合わせて、
- Cookie
- セッション情報
- デバイス判定
- ログイン履歴
- サーバー側で管理する信頼済みブラウザ情報
- その他、環境に応じた判定情報
などを組み合わせて判断するとよいでしょう。
次回ログイン時に、信頼済みブラウザと判定されている場合のみ、
「このブラウザでは先頭3文字まで省略できます」
のように表示します。
通常ブラウザでは、今まで通り完全なパスワード入力のみを受け付けます。
信頼済みブラウザでは、通常パスワードに加えて、先頭1文字〜3文字を省略した入力も受け付けます。
サーバー側での判定
サーバーには、通常のパスワードハッシュとは別に、例えば次のような情報を保持します。
- 通常パスワードのハッシュ
- 1文字省略後のハッシュ
- 2文字省略後のハッシュ
- 3文字省略後のハッシュ
- 省略ログインが有効かどうか
- 信頼済みブラウザとして扱うために必要な情報
信頼済みブラウザと判定された場合のみ、省略後のハッシュを用いて認証します。
つまり、通常は完全なパスワード認証を行い、信頼済みブラウザと判定された場合だけ入力文字数を減らせるようにします。
省略する3文字をそのまま保存する実装は避けるべきです。データベース漏えい時のリスクを考えると、通常パスワードと同様に、必要な形でハッシュ化して保持する方が望ましいでしょう。
「弱そう」に見える理由
確かに見た目だけでは、
パスワードを3文字も削れるなんて危険そう
と思います。
実際、この方式は認証強度そのものを高めるものではありません。
むしろ、信頼済みブラウザと判定された状態では、通常パスワードより短い入力でもログインできるため、純粋な認証強度だけを見れば低下します。
しかし、この方式には一つだけ大きなメリットがあります。
最大のメリット
覗き見に少しだけ強くなることです。
例えば、
- 電車内でログインしている様子を録画された
- 後ろからキーボード入力を見られた
- 記憶力の良い人に入力内容を覚えられた
このようなケースでも、
実際に入力された文字列だけでは、本来のパスワードが完成しません。
さらに、別ブラウザや別端末では信頼済みブラウザとして扱われないため、省略入力は利用できません。
つまり、画面を見られただけならば、そのままログインされる可能性を下げられます。
先頭の0文字〜3文字を削ったパスワードの削った部分については、ログイン試行回数に強い制限がある場合、たまたま覗き見した程度の人が突破するのは難しくなると考えられます。
プログラマーであれば仕組みを理解して推測することはできますが、一般的な覗き見攻撃に対しては一定の効果が期待できます。
第2パスワード方式との比較
メリット
- 第2パスワードを覚える必要がない
- パスワードを2つ管理する必要がない
- 認証できるパスワードの種類を増やさずに済む
- 表示文を読めば操作内容が分かりやすい
デメリット
- サーバーに省略後ハッシュを複数保存する必要がある
- 信頼済みブラウザでの認証強度は下がる
- 独自認証として慎重な設計が必要になる
- 信頼済みブラウザの判定設計が必要になる
セキュリティコードを表示しない方式との比較
よくある方法として、
信頼済みブラウザの場合だけ6桁のセキュリティコード入力欄を非表示にする
という実装もあります。
しかし、この方法では、
- 6桁コードを覚えておく必要がある
- 新しい端末では結局入力が必要になる
- コードの発行・通知・再発行などの運用が必要になる
という問題があります。
一方、先頭3文字省略方式は、
覚える情報を増やさず、入力だけ減らせる
という点が使いやすいと感じました。
ただし、これはセキュリティコード方式より安全という意味ではありません。
あくまで、
入力負担を少し減らしつつ、覗き見された入力内容をそのまま再利用されにくくする
ための工夫です。
この方式が防げるもの・防げないもの
防げる可能性があるもの
- 覗き見
- 電車などでの盗み見
- キーボード入力の録画
- 肩越しの監視
- 入力内容を記憶される攻撃
防げないもの
- XSSなどでブラウザ内情報が取得される攻撃
- 信頼済みブラウザの判定情報が取得される状況
- マルウェアやキーロガー
- パスワード総当たり攻撃
- 弱いパスワードそのものの問題
- 信頼済みブラウザが第三者に使われる状況
セキュリティ面
この方式は、
認証を強くする技術ではありません。
むしろ、信頼済みブラウザでは短い入力でもログインできるため、条件によっては通常のパスワード認証より不利になります。
特に、
- パスワード自体が短い
- ログイン試行回数制限が弱い
- 信頼済みブラウザの判定が甘い
- 信頼済みブラウザ情報が簡単にコピーできる
- 省略可能であることを過度に目立たせる
- 通常ブラウザでも省略入力を受け付けてしまう
といった状態では危険です。
そのため、この方式を使う場合は、
- 十分な長さのパスワードを前提にする
- ログイン試行回数を制限する
- 通常ブラウザでは省略入力を絶対に受け付けない
- 信頼済みブラウザの解除機能を用意する
- 不審なログイン時には通常パスワードや追加確認を求める
- パスワードマネージャー利用時は省略機能を使わない選択肢を用意する
といった対策が必要です。
まとめ
基本的にログイン画面では、回数上限やボット対策、追加認証などを除けば、同じ入力内容に対して同じ認証結果が返ります。
そのため、Aさんが入力したIDとパスワードをBさんが覗き見し、同じ内容を入力できてしまうと、そのままログインに成功する可能性があります。
今回の方式は、この
見えた入力内容をそのまま再現される
という問題を少し崩すための工夫です。
また、今回の方式は、
認証を強くする技術ではありません。
パスキーや多要素認証が問題なく使える状況であれば、そちらの方が有益であることは確かです。
一方で、
通常のパスワード認証の強度を大きく下げすぎずに、信頼済みブラウザだけ入力を少し楽にしつつ、覗き見には多少強くする
という目的には面白いアプローチだと思います。
ただし、信頼済みブラウザの判定情報が取得された場合は、0〜3文字少ない入力で認証を試せるため、覗き見対策以外の観点ではセキュリティは低下します。
それでも、認証強度を大きく下げすぎずに、ユーザー体験を少し改善したい場合の選択肢として検討する価値はありそうです。
ユーザー側がパスワード管理ツールを使う場合は、省略設定をONにしない、または省略せずに通常パスワードを使えばよいでしょう。
補足
ID入力欄が自動入力される状況では、パスワードの一部省略よりも、IDの一部を隠して表示する方法も検討できます。(気になってID入力画面に移動したり、サブアカウントに切り替えたりすると、見られる点に注意)
パスワード欄に、
このブラウザでは先頭3文字まで省略できます
といった但し書きを表示する方式の方が、利用者にとっては操作内容が分かりやすく、利便性も高いと思います。
一方で、ID一部マスクは独自認証ではなく、表示上の工夫として実装できるため、受け入れられやすい可能性があります。
| 項目 | パスワード3文字省略 | ID一部マスク |
|---|---|---|
| 分かりやすさ | ◎ 「3文字省略できます」と書けば理解しやすい | ○ 最初は「なぜ隠れているの？」となる人もいる |
| 入力の手間 | ◎ 毎回3文字少なく入力できる | △ IDを変更しない限り恩恵は少ない |
| 覗き見対策 | ○ パスワードの一部が見えない | ◎ ID全体が見えにくい |
| 実装の受け入れられやすさ | △ 独自認証として慎重な評価になりやすい | ◎ 一般的なUIとして受け入れられやすい |
ID入力欄を隠す方式は、HTML側を少し修正するだけでも実装しやすいです。
実装方法としては、画面に表示する入力欄と送信用のhidden入力欄を同期しておくのが扱いやすいでしょう。
利用者がIDを変更した場合は、表示用入力欄の内容をhidden入力欄にも反映させることで、画面表示と送信内容の不一致を防げます。
例えば、メールアドレス形式のIDであれば、@より前の文字列について、
- 3文字
- 文字数の3分の1
のうち大きい方を先頭から隠す、といった方法が考えられます。
利用者が別のIDに変更したい場合のみ、「変更する」ボタンを押して入力欄を編集できるようにします。
この方式であれば、覗き見された場合でもID全体を知られにくくなり、通常利用時には自動入力の利便性も維持できます。
少し過剰な対策かもしれませんが、IDとパスワードの両方について、見えている部分から隠された部分を推測されやすい問題を減らしたい場合は、これらを併用するのも悪くないと考えています。
パスワードマネージャーを使う場合は、自宅など安全な環境で省略しない通常パスワードを登録して使うのがよいでしょう。
ただし、パスワードマネージャーの利用率は国や利用者層によって差があります。
調査するタイミングによって前後しますが、世界のパスワードマネージャー利用率は約34%ですが、日本国内の利用率は約20%にとどまっています。
そのため、サービス提供者がパスワードマネージャーを利用していない人向けに、入力負担や覗き見対策を工夫すること自体は、誤りではないと思います。
実装するかどうかは、自サービスの利用者層、ログイン頻度、利用環境、セキュリティ要件を調査したうえで判断するとよいでしょう。