あなたのパスワードはサービス提供者も知らない。～認証プロセスを秘伝のタレに例えてみる～

アカウント、ID、パスワード、ログイン。
これらの言葉は、今では広く認知されている。

でも裏側の仕組みはあまり知られていない。
今回は、認証の仕組みを「秘伝のタレ」に例えてIT系以外の方にも分かりやすくその仕組みを解説してみたい。
（うまくいくかどうかは分からないが。）

まず、何かしらのアカウントを作成すると、パスワードの作成を求められる。
このとき、サーバーにパスワードがそのまま保存されていると思っている方も多いと思う。
つまり、「サービス提供側は私のパスワードを知っているはずだ」と。

実際はそうではない。
サービスを提供する側も、普通は顧客のパスワードを知らないのだ。
一部の許された管理者だけが知っているとか、そういう話でもない。
社長以下、管理職、技術職、平社員はもちろん、パスワードが保存されたコンピューター自信も、あなたのパスワードを知らない。

一体どういうことか。それならなぜ認証などできるのか。

パスワードは、秘伝のタレの材料？

うなぎ屋の、秘伝のタレをイメージして欲しい。

うなぎのたなかの秘伝のタレ★秘伝のたれ 100cc

パスワードの文字は、その材料である。
しょうゆ、みりん、砂糖、酒などを思い浮かべると良い。

秘伝のレシピ（材料やその分量）は、タレを開発した本人しか知らない。

そして、サーバーに保存されているのは、完成した秘伝のタレである。
こうしておけば、例えサーバー自体が盗み出されたとしても、秘伝のレシピは守られることになる。

同じ材料をぶちこみ（パスワード入力）、サーバーに保管されているタレと同じ味が再現できれば、それは秘伝のレシピを知る紛れもない本人であると認定される。
これが、基本的な認証の仕組みである。

サーバーにはタレしか保管されて無いので、レシピを忘れたから教えてくれというのはお門違い。
パスワードリセットとは、「レシピを無くしちゃったから、今度から新開発した別のタレをサーバーに登録してくれ」とお願いすることである。

つまりサービス提供側としては、パスワードリセットはできても、パスワードを教えることはできないのだ。

もう少し具体的な説明

さて、認証の仕組みを秘伝のタレに例えて説明したが、コンピューター上では実際にどうなっているのか。
パスワードは計算により、ハッシュ化されて保管される。
ハッシュというのは、ハッシュドビーフ、ハッシュドポテトなどの、あのハッシュである。

ハッシュド ポテト （63g×10枚）フライドポテト

プロジーヌ ハッシュドビーフ 200g×5袋

ぶつ切り、細切れ、ごたまぜという意味の英単語である。

コンピューター上のハッシュとは、具体的には、元に戻せない暗号だと思って欲しい。
ハッシュドポテトをジャガイモに戻せというのは無理な話。それと同じである。(料理全般そうだろというツッコミは無しで！)

以下、過去記事から引用
thom.hateblo.jp

たとえばmd5という暗号化方式がある。
(現在ではより強固な暗号化方式が存在するが、例示するのにちょうど良いので)

「hatena01」というパスワードがあったとすると、md5では次の文字列になる。
8583e57a6af9a203aab6dba70f85112e
「hatena02」なら次のようになる。
90c1d869e54d44712b31cf1b6e0daa42
「hatena03」なら次のとおり。
c37d0bc46a793a34ae85efca4102b973

md5については、どう計算しているのか、詳しくは知らない。

しかしRSA暗号という素数を用いた暗号化方式があるので、こちらを例に挙げたいと思う。
素数とは、1と自分以外で割り切れない数のことで、1000までの素数はこれだけある。

2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, 547, 557, 563, 569, 571, 577, 587, 593, 599, 601, 607, 613, 617, 619, 631, 641, 643, 647, 653, 659, 661, 673, 677, 683, 691, 701, 709, 719, 727, 733, 739, 743, 751, 757, 761, 769, 773, 787, 797, 809, 811, 821, 823, 827, 829, 839, 853, 857, 859, 863, 877, 881, 883, 887, 907, 911, 919, 929, 937, 941, 947, 953, 967, 971, 977, 983, 991, 997

この中から、適当に5つをピックアップして掛け合わせてみよう。

569 * 313 * 257 * 661 * 19 = 574837097311

この574837097311は、分解すると必ず上記5つの素数になる。
嘘だと思ったら、以下のサイトで計算してみると良い。
keisan.casio.jp

数値を素数に分解することを、素因数分解というが、人手でやるのは非常に困難である。
コンピューターを使えば、上記の3桁くらいなら余裕で解けてしまうが、実際のところ素数は無限にあるため、ある程度桁が増えてくるとコンピューターでも計算が困難となる。

適当に桁を足して計算サイトで実行してみたところ、タイムアウトエラーになった。

素数を用いて数を作るのは、ただの掛け算なので簡単であるが、ある程度の桁になるとそれを素数に戻すのはきわめて困難。
この性質を用いたのがRSA暗号である。

レインボーテーブルとソルトの話

話をmd5方式に戻そう。
RSAとかmd5とか、ころころ変わるのは私の知識が不十分な為である。どうかご容赦願いたい。

md5でAppleとOrangeをハッシュ化すると、以下のようになる。

Apple -> 9f6290f4436e5a2351f12e03b6433c3c
Orange -> 909cea0c97058cfe2e3ea8d675cb08e1

もちろん解析によってハッシュを元の文字列に戻すことは困難であるが、文字列とハッシュの組み合わせを辞書に登録してしまえば、索引によって簡単にハッシュから元の文字列を検索できる。
これがレインボーテーブルである。
レインボーテーブルとは、いわばタレ職人の知識とカンの蓄積をデータベース化したようなものである。
どの材料をどれくらい入れたらどんな味になるかは、長年の経験から分かっているのだ。
だからありきたりな材料ではすぐにレシピを見抜かれてしまう。

だから、英和辞典に載っているような英単語はパスワードにしてはいけないし、桁数が少ないのもまずい。
既に辞書に登録されている可能性が高いからだ。レインボーテーブルは常に更新されて、辞書登録数は増え続けている。

このレインボーテーブルに対抗するのがソルト(塩)である。
ソルトとは、サーバー側でパスワードに追加する文字列のことである。

利用者がAppleという単純なパスワードを作成したとすると、サーバー側ではこれに決まった文字列（たとえばSalt12345）を足してハッシュ化する。
AppleSalt12345 -> 2cb4fc93c5cd67b70c91519be759b123

認証プロセスでは、ユーザーの入力したAppleに対し、またSalt12345を足してハッシュ化し、保存されているハッシュ値と比較する。
Appleなどという単純なワードはさすがにレインボーテーブルに登録されているだろうけど、AppleSalt12345がレインボーテーブルに登録されている可能性は低い。
そんなものをいちいち登録していては、テーブルの容量がいくらあっても足りないし、ソルトが変わればまた計算をやり直すハメになる。

ソルトは単純にパスワードを長くしてハッシュ値の辞書検索を困難にする目的なので、外部にバレてもさほど影響はない。

以上のような仕組みで、皆さんのパスワードは安全に守られているわけである。

ただし、そうでないシステムもあるのでやはり単純なパスワードはよろしくない。
世の中には恐ろしいことに、いまだに平文でパスワードを保存しているものもあるのだ。
（つまりサーバーに侵入された時点でパスワードだだ漏れ）

さすがにクレジットカード決済するようなサイトでそれは無いと思うが、よく分からない無名のサービスの利用は自己責任である。