「パスワードを2つも持つなんて危険では？」
そう思われるかもしれません。
しかし、第2パスワードを通常時は利用できず、信頼済みブラウザだけで利用可能に限定すれば、覗き見対策として利用価値があるかもしれません。
信頼済みブラウザは、例えばID欄が自動入力される状況を思い浮かべて下さい。(自動入力されたID以外でのログインでは第2パスワードを使えません)
今回は、「第2パスワード方式」を考えてみました。
信頼済みブラウザの判定方法は、実装環境やサービスの要件によって変わります。
そのため、この記事では特定の判定方式には踏み込みません。
利用する場合は、各サービスの設計方針に合わせて、
- Cookie
- セッション情報
- デバイス判定
- ログイン履歴
- サーバー側で管理する信頼済みブラウザ情報
- その他、環境に応じた判定情報
などを組み合わせて判断するとよいでしょう。
今回はパスキーは採用しませんでした。パスキーは非常に優れた仕組みですが、サービスや利用環境によっては導入・利用のハードルがあると感じたためです。また、デバイス認証についても有力な選択肢ですが、「どこまでを同一端末として扱うか」や、ブラウザデータの削除・移行時の扱いなど、運用面で考えることが多いと感じました。
仕様
通常は今まで通りのパスワードでログインします。
ただし、以下の条件を満たした場合のみ、第2パスワードでもログインできるようにします。
- そのIDの信頼済みブラウザと判定されている(他のIDでは使えません)
- 利用者が「第2パスワードを有効にする」をONにしている
- 入力された第2パスワードがサーバー側の情報と一致する
ログイン画面には、条件を満たす場合のみ、
「このブラウザでは第2パスワードが利用できます」
と表示します。
通常ブラウザでは通常パスワードのみ利用でき、
信頼済みブラウザでは通常パスワードまたは第2パスワードでログインできます。
初回ログイン
初回アクセス時は、例えば次のような流れになります。
- 通常パスワードでログインする
- ログイン成功後、サービス側でそのブラウザを信頼済みブラウザとして扱うか判定する
- 条件を満たす場合、次回以降そのブラウザでは第2パスワードを利用可能にする
- 第2パスワードでログインする場合も、サーバー側で信頼済みブラウザかどうかを確認する
- 信頼済みブラウザでない場合は、第2パスワードによるログインを拒否する
ここで重要なのは、
第2パスワードは、信頼済みブラウザでのみ利用できる補助的なログイン手段にする
という点です。
信頼済みブラウザの判定方式は、サービスごとに適切な方法を選べばよいと思います。
サーバー側で保持するもの
サーバー側では、例えば以下のような情報を保持します。
- 通常パスワードのハッシュ
- 第2パスワードのハッシュ
- 第2パスワードが有効かどうか
- 信頼済みブラウザとして扱うために必要な情報
具体的に何を保存するかは、実装方針によって変わります。
この記事では、特定の保存方式や判定方式は前提にしません。
第2パスワードとは
第2パスワードは、通常パスワードとは別に設定するパスワードです。
例えば、
通常パスワード
MyPassword123
第2パスワード
BlueCat987
のように、全く別の文字列にできます。
第2パスワードでログインした様子を見られても、第1パスワードの中身が分からない
ことがメリットです。
ログインには、
- 通常パスワード
- 信頼済みブラウザでの第2パスワード
のどちらかが必要になります。
覗き見によって第2パスワードを知られたとしても、通常ブラウザからは第2パスワードを使えないため、単純な再現ログインを防ぎやすくなります。
通常ブラウザでは通常パスワードのみ利用でき、
信頼済みブラウザではどちらでもログインできます。
3文字省略方式との比較
| 項目 | 3文字省略 | 第2パスワード |
|---|---|---|
| 分かりやすさ | ◎ 「先頭3文字まで省略できます」と表示するだけ | ○ 「第2パスワードが利用できます」と表示 |
| 入力の手間 | ◎ 少ない | △ パスワードを2つ覚える必要がある |
| 覗き見対策 | ○ パスワードの一部が見えない | ◎ 第2パスワードでログインした場合、通常パスワードが見えない |
| 判定情報流出時 | × 強度が落ちたパスワード候補が増える | △ 第2パスワードも候補になる |
メリット
- サーバーに省略後ハッシュを複数保存しなくてよい
- 第2パスワードは完全に独立した文字列にできる
- 「3文字だけ推測すればよい」という状態にならない
- 第2パスワードでログインした様子を見られても、通常パスワードは分からない
デメリット
- 第2パスワードを覚える必要がある
- パスワードを2つ管理することになる
- 認証できるパスワードが2種類になる
- 信頼済みブラウザの判定設計が必要になる
最大のメリット
例えば、
- 電車内でログインしている様子を録画された
- 後ろからキーボード入力を見られた
- 記憶力の良い人に入力内容を覚えられた
という状況でも、第2パスワードでログインしていた場合、通常パスワードは知られません。
また、第2パスワードは信頼済みブラウザでしか利用できないため、見られた第2パスワードだけで別の端末からログインされるリスクも下げられます。
この方式は、
通常パスワードを隠すためのログイン導線
として使える可能性があります。
セキュリティ面
この方式も、
認証強度そのものを高める技術ではありません。
認証可能な入力パターンが増えるため、設計を誤ると通常パスワードしか存在しない場合より不利になる可能性があります。
特に、
- 第2パスワードが弱い
- 信頼済みブラウザの判定が甘い
- 第2パスワードを通常ブラウザでも使えるようにしてしまう
- 信頼済みブラウザ情報が簡単にコピーできる
- ログイン試行制限が弱い
といった状態では危険です。
そのため、第2パスワード方式を使う場合は、
- 第2パスワードにも十分な強度を求める
- 通常ブラウザでは第2パスワードを使えないようにする
- ログイン試行回数を制限する
- 信頼済みブラウザの解除機能を用意する
- 不審なログイン時には通常パスワードや追加確認を求める
といった対策が必要になります。
まとめ
この方式も、
パスキーや多要素認証を置き換えるものではありません。
パスキーや多要素認証が利用できる状況であれば、そちらを優先する方が望ましいでしょう。
一方で、
- 先頭3文字省略方式
- 第2パスワード方式
はどちらも、
信頼済みブラウザ限定で、覗き見対策や入力負担を工夫するための独自アプローチ
としては面白いと感じました。
どちらを採用するかは、
- 覚える情報を増やしたくないなら「3文字省略」
- 覗き見対策に特化するなら「第2パスワード」
という考え方で選択できると思います。
ただし、どちらの方式も慎重な設計が必要です。
特に第2パスワード方式は、
「第2パスワードを知っていること」だけでログインできる仕組みにしてはいけない
という点が重要です。
あくまで、
信頼済みブラウザでのみ使える補助的なログイン手段
として扱うべきです。
パスワードマネージャーを使う場合は、自宅など安全な環境で通常パスワードを登録して使うのがよいでしょう。
ただし、パスワードマネージャーの利用率は国や利用者層によって差があります。
調査するタイミングと調査の精度によって前後しますが、世界のパスワードマネージャー利用率は約34%で、日本国内の利用率は約20%にとどまっている可能性があります。
そのため、サービス提供者がパスワードマネージャーを利用していない人向けに、入力負担や覗き見対策を工夫すること自体は、誤りではないと思います。
実装するかどうかは、自サービスの利用者層、ログイン頻度、利用環境、セキュリティ要件を調査したうえで判断するとよいでしょう。
補足
ID入力欄が自動入力される状況では、第2パスワードよりも、IDの一部を隠して表示する方法も検討できます。
Googleログイン等にも対策の1つとして使われている記憶があります。
しかし、第2パスワード方式は1端末で複数のIDに対して、それぞれ信用済みブラウザの判定を持てるため、
- 気になってID入力画面に移動
- サブアカウントに切り替える
と言った操作を行う場合に、第2パスワード形式の方が覗き見対策として強く機能します。
IDの一部を隠す手法はID入力画面に戻った時に、覗き見対策の強度が落ちるのです。
個人的には共存の余地があると思いますので、まずはIDの一部を隠してから第2パスワードを検討する事をおすすめします。
先程触れたGoogleログインのように、2段階認証を設定しても良いサービスならば、2段階認証の方が優れているのは確かだと思いますし、その場合第2パスワードはやり過ぎの可能性はあります。