最近パスワード漏洩とかで物騒ですね。
利用者側としても開発者側としても怖いです。
怖いからセキュリティについて少しだけ勉強したので知識の整理を。
勉強したてで間違ったことを書くかもしれません。
そんな時は派手に着火せずコメントでこっそり教えて下さい。
利用者側
パスワードを定期的に変更する理由は何ですか? - QA@IT
よく定期的にパスワードを変更しろって言われるけどなんで？ってことで理由を体系的に学ぶ 安全なWebアプリケーションの作り方の著者が解説しています。
パスワードがハッシュ化(元に戻せないように変換)されていれば解析に時間がかかって
その間にパスワードを変えてしまえば大丈夫って理屈から
定期的にパスワードを変えろと言われるようになったみたいです。
でも最近は頑張れば解析時間を短縮できるから「定期的に」の基準がないみたいです。
あとは、実際にパスワードが漏れてもパスワードを変えてしまえば
変えた段階で悪用が止まるという理屈だそうです。
長期的にわたる盗聴的な悪用だったら意味があるけどすぐに何かを盗んだり改竄したりするような悪用だと意味無いです。
また、長期的にわたる悪用の場合でもパスワードが漏れた段階でシステムが対策してなかったら
パスワードを変えたところで再び漏れる可能性があるのでどうしようもないですね。
利用者にできるのは会員情報などをでたらめな情報に変更してから退会とかかな？
退会したからといって情報を削除しているとは限らないので…。
ユーザーはパスワードを定期的に変えろよーとか言われても面倒臭くてやりませんよねー
それどころかいくつも登録してると面倒でパスワードを同じにしてる人いるしね。
どこかでパスワードが漏れると全部危険になるので最低限パスワードは同じにしないとしても
それらをすべて定期的に変更とか現実的じゃないということでコレはなしですね。
あんまり変更しなくてもいいから各サイトのパスワードはバラバラにして長め(12文字くらい？)にした方が良さそうです。
英単語とかはダメですよ。辞書に載っているような単語とかを総当りでチャレンジしてくるからね。
開発者側
パスワードってどうやって保存すればいいの？
平文(入力値)のまま保存するとSQLインジェクションとかで漏れたら即死だぞー！早く対策しろー！どうなっても知らんぞー！ということで元のパスワードに戻せないように変換(ハッシュ化)して保存したほうがいいです。
ハッシュ関数というので変換するのですが、そのアルゴリズム(変換方法)には
MD5、SHA-1、SHA-256などがあるようです。
ちなみに左から順に衝突しやすい(違う値を渡して同じハッシュ値が得られる、つまり違うパスワードでも正解ということに)。
MD5とか使ってもダメみたい。せいぜいファイルの同一性チェックのイメージしか無い。
SHA-1なら大丈夫かというと必ずしもそうでもないみたい。詳しくはこのあとに書きます。
SHA-256は今のところセーフ？技術やマシンが進歩するとどうなるかわからないから怖いです。
ハッシュ関数について軽く理解したい場合は「プロになるためのWeb技術入門とかいいんじゃないですかね。
SHA-1ハッシュ化されたパスワードは安全ですか? - QA@IT
ハッシュ化してしまえば元に戻すのはできないけど、ハッシュ化すること自体はできるんだから総当り的に文字列をハッシュ化していって一致したら元の文字列がパスワードだってわかってしまいます。
その総当たりにどれだけの時間がかかるか、の勝負になるわけです。
しかも、レインボーテーブルと言って、文字列とハッシュ値のペアを持ったDBが存在するとか。
このレインボーテーブルのハッシュ値と漏洩したハッシュ値が一致すれば
パスワードは元の文字列だということになるわけです。ちなみにこの攻撃方法をレインボークラックと言うとか。
現在のコンピュータパワーだと文字列の長さは10文字程度までとのことなので、
パスワードは12文字とか長くしておいたほうがいいですね。
ユーザーが必ずしも長いパスワードを入力するとも限らないですし、
できるだけ安全性を高めるために開発者側はパスワードにソルトというものを付けてからハッシュ化したほうがいいようです。
ソルトを付けなかったがためにパスワードが漏洩したサービスがあるとか。
ソルトとは何ですか? - QA@IT
ソルト(salt)とは、とりあえずハッシュ化する文字列が長ければレインボークラック対策になるってことですね。
パスワードのハッシュ値を計算する際に、パスワードの前後に付加する文字列のことです。
たとえば、ソルト長が10文字、パスワードが最短8文字とすると、ソルトつきパスワードは最短18文字になります。
このように長いパスワードに対応するレインボーテーブルを作ることは現在のコンピューターパワーでは不可能なので、
ソルトはレインボーテーブルに対する効果的な対策です。
ソルトを付けてからハッシュ化するので割とどんな文字でも良さそうかな？
パスワードのソルトの要件は？ - QA@IT
じゃあソルトって何にしたらいいの？どう扱ったらいいの？って疑問に対しての回答。とりあえずユーザー同士が同じパスワードを使っている場合には
各ユーザーのソルトが同じ場合は同じハッシュ値が得られることになってしまう。
すると同じハッシュ値のものはよく使われている単語によるパスワードだと推測できて
総当りによる攻撃がしやすくなるとのこと。ということでユーザーごとに異なるソルトを使いましょう。
ソルトの長さはパスワードと組み合わせてある程度の長さ(今のところ20文字程度？)があれば良いそうです。
今のところ10文字程度までの文字列しかレインボーテーブルにないので
パスワードにソルトを付けて十分の長さが得られれば良いということですね。
ソルトの文字列は別に乱数でなくても結局パスワードと組み合わせてハッシュ化するから関係ないかも。
でも乱数なら長さ的には申し分ないので乱数を使うのが多いそうです。
ハッシュ値とソルトは一緒にデータベースに保存するだろうけど漏れてしまえば
適当な文字列とソルトを結合してハッシュ化して試すだろうから
ソルトにそんなにこだわっても仕方ないかなという感じですね。
ユーザー毎に異なるソルトを十分な長さで使ってやればそれでいいみたいです。
無駄に長くするより何度もハッシュ化するストレッチングというのをする方が
解析する側の手間が増えて時間稼ぎになるらしいです。
これで十分？
ハッシュ化について結構書いたけど辞書式に総当り攻撃(ブルートフォースアタック)されたらどれだけ安全なハッシュ化しようと関係ないんですよね…。
セキュリティはイタチごっこだから常に最新の情報を手に入れないと十分なんてことはないんだ！
だからセキュリティ関係の基礎知識を付けて最新情報を理解できるようにしよう！
2011年の記事だけど本当は怖いパスワードの話（1/4） － ＠ITにちゃんと書かれてます。
やっぱりこの記事も体系的に学ぶ 安全なWebアプリケーションの作り方の著者が書いてます。
著者の徳丸先生がBloggerやってるので読者になりました→徳丸浩の日記
こんな間違ってるかもしれない記事を書いたり読んだりしてないで著書を読めって話ですよね。すみません。
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
