パスワード認証

パスワード認証でのパスワード管理のしかたを調べた。

パスワードはハッシュ値にしてDB(データベース)に保存して管理し、認証の時には、入力されたパスワードをハッシュ値にしてDBのハッシュ値と一致するか

と言うことをするのが一般的なよう。

 

なぜそんなことをするかというと、「もしDBのデータが漏洩したとしてもパスワードは死守するため」。

死守するためには他にも ソルト を付加するとか ストレッチング をするとか言う工夫をしているそう。

 

■ソルト

パスワードをハッシュ値にしておけば、元のパスワードは分からないかと言うと、そういうわけでも無い。

「文字列 と その文字列のハッシュ値 の表」があれば、パスワードのハッシュ値と一致する文字列はなにかな?と順に照らし合わせていけばそのうち一致する物が見つかることになる。

例えば、DBから「8f14e45fceea167a5a36dedd4bea2543」と言うハッシュ値が漏洩したとする。
図のような表があれば元のパスワードは “7” だと言うことが分かってしまうわけだ。

文字列、ハッシュ値テーブル

 

それをしにくく(時間がかかるように)するための工夫としてパスワードにランダムな文字列をプラスしてそのハッシュ値を保存する。このプラスする ランダムな文字列 のことをソルト(salt)と言うそう。ソルトはユーザー毎に異なる文字列を使う。

こうしておけば、ハッシュ値からパスワードの逆読みをするのに使う「文字列 と その文字列のハッシュ値 の表」をユーザー毎に用意しないといけなくなり、より時間がかかるようになると言うわけ。

 

■ストレッチング

パスワードのハッシュ値は一瞬で計算する事ができるので、ハッシュ値からパスワードの逆読みをしにくくするために、「パスワードのハッシュ値」、それのハッシュ値、それのハッシュ値・・・これを1000回とか繰り返したハッシュ値を保存したりする。このハッシュ値のハッシュ値と繰り返すことを「ストレッチングする」とか言うそう。

こうしておくと一つのハッシュ値を得るのに何秒かかかるようになり、ハッシュ値からパスワードを逆読みするのに必要な「文字列 と その文字列のハッシュ値 の表」を作るのに時間がかかるようになる。

 

こういうソルトやストレッチングをしておくことで、ハッシュ値からパスワードの逆読みするのに数年とか数十年とか時間がかかるようにして、もしパスワードが漏洩しても元のパスワードが特定されるまでにユーザーにパスワード変更をしてもらったり、強制的に変更したりして、悪用されるのを防ぐということらしい。

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください