PassKeyメモ

古き良き時代のパスワード認証

ユーザーIDとパスワードをそのままサーバーに保存。

クライアントからユーザーIDとパスワードを受け取りサーバーに保存しているユーザーIDとパスワードとで照合。

一方向ハッシュ関数を掛けることで、パスワードを保護

ユーザーIDと一方向ハッシュ関数を掛けたパスワードをサーバーに保存。

クライアントからユーザーIDとパスワードを受け取り、パスワードに一方向ハッシュ関数を掛けて、サーバーに保存しているユーザーIDと一方向ハッシュ関数を掛けたパスワードとで照合。

パスワード方式の問題点

ユーザーが使いやすい(覚えやすい)脆弱な(誰でも思いつく、何度か繰り返せば当たってしまう)パスワードを設定してしまう。

ユーザーがパスワードを紙などに書いてしまう。最悪、端末にポストイットなどで貼り付けてあることもある。

パスワードを別システムに使い回していた場合、パスワードリストが漏れたら、そのパスワードで別システムにログインできてしまう。

一方向ハッシュ関数を使っていたとしても、定型的なパスワードの場合にはすぐにバレてしまう。

悪意のある管理者がパスワードを収集するようなことができてしまう。(ユーザーにパスワードを入力させることができれば成功。)

間違ったパスワードの改善方法

定期的にパスワードを変更する。

面倒くさくなって、より簡単なパスワードを設定するようになる。

記号を混ぜたパスワードを設定する。

総当たり方式では記号を混ぜるよりも文字列の長さを長くした方が効率が良い。

数字や英字を見立てた記号を使ったり、最後に申し訳程度に記号を使う傾向があり、改善にならない。(H3110!とか、Pa55w0rd!など)

PassKeyの考え方

公開鍵暗号を使う。ユーザーは秘密鍵、サーバーは公開鍵を持つ。秘密鍵は外に漏らさない。通信では鍵をやり取りするのではなくて鍵を使って暗号化したデータをやり取りするので盗聴することも難しい。

このため、ユーザー側のシステムが乗っ取られるとき以外では漏れない。

ユーザーはパスワードを覚える必要もないし、入力する必要もない。

URLとマッチさせて通信するため、異なるURLのフィッシングサイトなどでパスキーを収集されることもない。

秘密鍵は十分なビット数を持っていて、総当たりは不可能。アルゴリズム的にも見つけることが困難。

PassKeyとシングルサインオンをどうやって組み合わせる?

認証用URLにリダイレクトしてそこで認証する。認証が完了したら認証トークンを発行して、その認証トークンを使い回す。