ritou です。
大きなサービスで何か問題があると、それをきっかけに皆さんのセキュリティ意識が高まりかけたりするものです。 最近はパスワードマネージャーやパスキーについて言及する人も増えてきました。 表題の通り、パスワードマネージャーをお勧めしますという話を書きます。新しい話ではなく、いつもの内容です。
パスワード認証に求められる要件とは？
パスワード認証自体は脆弱な認証方式ではありません。 ユーザー、サービス共に要件を満たして実装、運用されているならば至高の認証方式なのであります。その要件を見てみましょう。
- ユーザー
- 推測不可能な文字列にする
- 複数のサービスで別のパスワードを利用する
- 忘れない
- 第3者にパスワードを知らせない
- サービス
- パスワードを安全に管理する
- 各種攻撃からユーザーを保護する
これに対する現状を見てみましょう。
"記憶する" パスワード認証の課題
ユーザー側が記憶で上記の要件を満たそうと思うと、次のような課題があります。
- ユーザー
- 推測不可能な文字列にする: 推測しやすい文字列を使ってしまう
- 複数のサービスで別のパスワードを利用する: 使い回してしまう
- 忘れない: 忘れてしまう
- 第3者にパスワードを知らせない: フィッシングサイトを見分けられずにパスワードを入力してしまったり、付箋にメモってみられたりしてしまう
全員が...とは断定はできませんが、ほとんどの人間はパスワード認証の要件を満たせないのであります。
パスワードマネージャーの利用により変わること
世の中のパスワードマネージャーの機能も様々ですが、一般的には次のようになります。
- ユーザー
- 推測不可能な文字列にする: 安全な文字列を生成可能
- 複数のサービスで別のパスワードを利用する: サービスごとにパスワードを保存可能
- 忘れない: 長期間保存可能
- 第3者にパスワードを知らせない: アクセスしているドメインなどを利用して、対象のサービスを識別可能
最後のドメイン判定について最近Xで投稿したところ、なぜか反響がありました。
パスワードマネージャーの特徴のひとつとして保存されているパスワードを入力するかどうかのドメイン判定があります。これは記憶の問題とは別のフィッシング対策という意味で重要な機能であり、パスキーではより厳密に管理されるようになるので意識しておきましょう。 https://t.co/ThJ9AIvpHr
— 👹秋田の猫🐱 (@ritou) 2024年7月5日
細かい話をすると、このドメイン判定の精度はパスワードマネージャーごとのロジックに依存します。 登録したドメインと一致する場合のみ許容、サブドメインでも許容などいくつかのロジックがあるでしょう。
話を戻すと、要件は大体満たしています。大体、というのは全てをパスワードマネージャーに委ねる利用をしている場合です。
- パスワードは自分で考える
- クロスデバイスの場合などに、パスワードマネージャーに表示させたパスワードを目でコピペする
- フィッシングサイトでも、パスワードマネージャーに表示させたパスワードを目でコピペする
といった使い方をすることで、要件が満たせなくなります。完璧ではない。 しかし、これを言い換えると、この部分が危ないということを知っていたら、気をつけることができるでしょう。
これが まずはパスワードマネージャーを使いましょう という主張をする1つ目の理由です。
パスキー認証との関係は？
次に、パスワードマネージャーを利用するパスワード認証とパスキー認証との関係について整理しましょう。 パスキー認証の最大の特徴である 公開鍵暗号の利用 のおかげで別物として捉えられがちですが、パスキー認証とはパスワードマネージャーを利用するパスワード認証を進化させたもの、強化したものと言えます。ここでは パスワードマネージャーを用いたパスキー認証 についての話となります。
パスワードマネージャーの不完全な点として挙げたものに対して、パスキー認証では次のような特徴があります。
- パスキー、FIDOクレデンシャルの一番のキモである秘密鍵情報はパスワードマネージャーが生成する
- どのパスキーを利用するかどうかはサービスが指定したドメイン/オリジンと実際にアクセスしているURLの一致をブラウザが判断した上で認証器に要求が送られる
- クロスデバイスのユースケースを想定してQRコードやPush通知 + BLEを利用した接続したモバイル端末を利用する仕組みがある
パスワードマネージャーで統一されていないドメイン/オリジン判定について、しっかり定義されています。 認証フローにおいて入力されたものがそのまま送られるパスワード認証に対して、パスキー認証では秘密鍵を利用して生成された署名のみがやり取りされるため、フィッシングサイトやクロスデバイスでユーザーの手入力を利用する、というのは仕組みからして困難です。そのため、クロスデバイス用のフローもあらかじめ定義されています。QRコードやPush通知とBLE接続と組み合わせにより、遠隔地にある第3者のモバイル端末を用いた認証を困難とします(近接のデバイスを用いたアレコレはできる余地がありますが一旦割愛します)。
あとは、ここまで触れていなかったサービスがわの要件についても触れます。要件に対して次のような特徴があります。
- サービス
- パスワードを安全に管理する: サービスは公開鍵のみ管理するので、漏洩しても不正ログインが困難
- 各種攻撃からユーザーを保護する: 認証処理における攻撃手法が変わる
管理するのが公開鍵であれば漏洩時の被害が大きく変わるということ、やり取りされるデータがパスワード認証とは異なるために攻撃手法についても変わりますよ、というのは認識しておきましょう。
そして、最近はパスワードマネージャーを用いたパスワード認証からパスキー認証へのアップグレードのための仕組みが出てきています。
この辺りは今後、より使いやすくなるでしょう。
パスワードマネージャーを利用しているユーザーにとって、パスキー認証はもう目の前にあるのです。 サービスがパスキー認証に対応したら、アップグレード機能を利用するなりパスワードマネージャーを使ってシュッとログインした後に設定をすれば良いのです。
これが まずはパスワードマネージャーを使いましょう という主張をする2つ目の理由です。
まとめ
今回は、パスワード認証において記憶のみを利用する場合、パスワードマネージャーを使うことで実現できること、できないこととパスキー認証との関係について整理しました。
触れていない内容として、パスワードマネージャー自体の認証方式とそれへの依拠、知識要素からの変換といった話があります。今回の話でも分かる通り、パスキーで新しく出てきた話ではなく、既にある話なのです。これもXで注目されることが多い話題なので別途整理しましょう。
大事なことなので2回ずつ言います。
まずはパスワードマネージャーを使いましょう。まずはパスワードマネージャーを使いましょう。パスキーは目の前です。パスキーは目の前です。
何かを広めようと思ったら、有識者は同じ話を内容をちょっとずつ更新しながら何度も説明する必要があるでしょう。たまには軌道修正も必要です。 Xでフォローいただいている方にしてみれば「あの猫、またこの話してるんか」というところでしょうが、それが狙いです。
引き続きやっていきましょう。ではまた。
