パスワードをハッシュ値で管理してみる
とは言ってもサーバ側の話ではありません。通販サイトなどログインを必要とするサービスのパスワードとして、ハッシュ値そのものを使ってみよう、というお話です。
大雑把な説明になりますが、ハッシュ値というのは、ハッシュ関数によって生成された文字列のこと。
関数への入力データが同じであれば何度やっても同じ値を返し、(ほぼ)不可逆な一定長の文字列となります。
そのハッシュ値をパスワードとして使う最大のメリットは、必要に応じてパスワードを生成/参照できるため、パスワード自体を覚える必要がないこと。さらに、サイトごとに異なるパスワードを設定するのも簡単になります。
また、環境依存度が低く、複数端末や異なるOSが混在する環境でも、比較的ラクにパスワード管理が行えるのもポイント。
デメリットとしては、パスワードの文字数制限や、記号の混ぜ込みが必須のパスワードなど、そもそも使えない場合があること。また、コピーペーストを許さないパスワード入力の手入力も結構面倒です。
もちろん、毎回のパスワード入力も手間ではありますが、そこは妥協してWebブラウザのパスワード・マネージャを使うことにします。有名所のWebブラウザなら、まぁ信用しても良いだろうという判断。
ハッシュ値を生成するための仕組みが必要になるのもデメリットと言えるかもしれません。Linux系のOSであればコンソールからハッシュ値を得ることもできますが、インターフェース的に使いづらく、専用のアプリ/ソフトを使うのが現実的な選択となります。
Web上でもハッシュ変換ツールが提供されておりますが、その利用には要注意です。中には結果をデータベースに保存し、ハッシュ値→元データの変換ツールとして提供している場合があるためです。詳しくは後ほど。
で、キモとなるのがハッシュ値を生成するための元データの作り方。あくまで一例ですが、冒頭のスクリーンショットでは"amazon-banana"を元データとしています。あえて1バイト文字を使っているのは、文字コードが異なる環境でも問題が発生しないようにするため。
2バイト文字を使用した場合、テキストとしての見た目が同じでも文字コードの違いから生成されるハッシュ値が違うものになる場合があるためです。
で、元データの構造ですが、サイト名の部分は可変とし、サイト/サービスごとに異なる単語を設定します。まんまサイト名でも良いし、サービス名や社名、ドメインなど、わかりやすいモノでOK。
もうひとつの要素である独自文字列は固定化してしまい、他のハッシュ値を生成する時に使いまわします。
なので、好きな食べ物や趣味のアイテムなど、覚えやすいけど他人には推測されにくいモノがよろしいかと。
このように元データの作り方をルール化しておくことで、バリエーションが簡単に増やせ、サイトごとに異なるパスワードの設定も用意になる...という訳です。
元データが1バイトでも異なれば生成されるハッシュ値はまったく異なるモノとなるので、サイトごとのパスワードも簡単に設定できるという訳です。
万一サイトへの不正アクセスなどでパスワードの変更が求められた場合でも、例えば元データのサイト名部分を"amazon(2)-banana"などとしてハッシュ値を生成すれば、新たなパスワードとして利用できます。
手間を省く目的で、サイト名のみを元データとして生成したハッシュ値を使ってはいけません。見た目は難解読っぽくなりますが、容易に解読されてしまう可能性があるためです。
ハッシュ値から元データを復元するのは非常に困難ですが、ある文字列に対して生成されたハッシュ値があらかじめ登録されているデータベースを使えば、一瞬でハッシュ値→元データの変換が行えます。
例えばこちらのサイト。"2d0d4809e6bdb6f4db3e547f27b1873c"というハッシュ値をフォームに入力(ダブルクオーテーションを除く)してEnterを押せば、元データが"amazon"であるとわかります。
これは、あくまで"2d0d4809e6bdb6f4db3e547f27b1873c"が"amazon"という文字列のハッシュ値であると記録されているだけのことで、ハッシュ値を解析して元データを表示している訳ではありません。
なお、こちらのサイトではテキストデータからハッシュ値を生成するツールも提供されているのですが、入力とその結果はデータベースに記録されるため、決して本番用として使ってはいけません。
で、ハッシュ値をパスワードとして使った場合のセキュリティ的な強度はどうなのよ? という話ですが、ハッシュ値を求める方法のひとつであるMD5を使用した場合、英数字32桁のハッシュ値となります。
これを有名なセキュリティソフトベンダーであるカスペルスキーのパスワードチェッカーにかけてみると、一般的なPCを使った場合の解読時間は"10000+ 世紀"になるのだとか。
単純な総当り方式のパスワード解読に対する評価なので鵜呑みにはできませんが、それなりには強力なパスワードになっていると言えそう。
決して「この方法で万事OK」という訳ではありませんが、元データ作成の簡単なルールだけ覚えておけば良く、汎用性があって、面倒も少ない。個人的にはなかなかの妙案なのではないかと思っております。
セキュリティに関することなので、異論・反論は大歓迎。ぜひコメントにてお知らせいただけますれば。
コメント