パスワードのセキュリティに関する質問です。

ユーザーとしてウェブサービスを使っていると、ユーザー登録時やパスワードリマインダを使ったときに、そのままパスワードが表示されたりして、明らかに「パスワード平文で保存してるだろ」と思われるようなものが多くあります。

1.実情としてユーザーのパスワードは平文で保存されていることが多いのでしょうか(割合としてどれくらいかというデータがあると嬉しいですが、体験談や伝聞でもかまいません
2.自分が見た、PHPでよく使われているオープンソースの認証システムでは「sha1+固定のsalt値」でユーザーのパスワードをハッシュ化しているようですが、sha1を対象とした攻撃が既に見つかっているようですし、固定のsalt値であると同一のパスワードを設定したときにハッシュ値が同じになってしまいます。
そういった問題までは一般的には気にする必要はないということでしょうか。(パスワードをハッシュ化して保存するとなると、ハッシュ化の仕組みを後に置き換えるのは現実的にかなり難しいと思われるので、途中で「やっぱこの仕組みだとやばかったわ」となっても、修正が効かないような気がするのですが)

回答の条件
  • 1人2回まで
  • 登録:2008/06/14 17:05:36
  • 終了:2008/06/18 15:50:48

ベストアンサー

id:pahoo No.1

pahoo回答回数5960ベストアンサー獲得回数6332008/06/14 18:27:36

ポイント40pt

1.実情としてユーザーのパスワードは平文で保存されていることが多いのでしょうか

少なくとも私が関わっているシステム開発では、パスワードはハッシュ化して保管しています。

しかし、他社システムとWeb連携するとき、平文のパスワードを渡されたことが何度かあり、これには閉口しました。いずれの原因も、第三者が作成したPHPやJavaのフレームワークが原因でした。

フリーにせよ市販にせよ、フレームワークを利用する際は、あらゆる観点からチェックを加えるべきです。



2.sha1を対象とした攻撃が既に見つかっているようですし

【CRYPTO-GRAM日本語版】解読されたSHA-1」によれば、2の69乗回の演算でSHA-1衝突を発生させる手法が明らかになったとのこと。2005年時点では、

2の69乗回の演算には3年3カ月を要する。開発に2500万~3800万ドルをかけられるならば,56時間に2の69乗回の演算を処理できるシステムも実現できるだろう。

としています。

その後、さらに計算回数を減らせるというレポートも出たようです。

ただ、愉快犯を別にすれば、アタッカーもプロですので、これだけのコストをかけて破るに値するシステムでなければ攻撃してきません。

残念ながら、私が関わっているシステムでは、そこまで重要度の高いものはありません。


固定のsalt値であると同一のパスワードを設定したときにハッシュ値が同じになってしまいます

これは、salt 値を乱数にするかどうかという問題とは関係なく、運用上の問題になります。

SHA-1の出力は160bit、これに対してパスワードは英数8文字程度の56bitですから、実はパスワードを総当たりで解く方が早いんですね(笑)。

SHA-1の衝突を気にするようなシステムは、少なくともパスワードの長さが英数23文字以上であるようなシステムになります。


参考書籍

id:studio15

丁寧な回答ありがとうございます。

やはり、攻撃の効率と保存されているデータの重要度のバランスが肝なのですね。

2008/06/14 22:03:21

その他の回答(2件)

id:pahoo No.1

pahoo回答回数5960ベストアンサー獲得回数6332008/06/14 18:27:36ここでベストアンサー

ポイント40pt

1.実情としてユーザーのパスワードは平文で保存されていることが多いのでしょうか

少なくとも私が関わっているシステム開発では、パスワードはハッシュ化して保管しています。

しかし、他社システムとWeb連携するとき、平文のパスワードを渡されたことが何度かあり、これには閉口しました。いずれの原因も、第三者が作成したPHPやJavaのフレームワークが原因でした。

フリーにせよ市販にせよ、フレームワークを利用する際は、あらゆる観点からチェックを加えるべきです。



2.sha1を対象とした攻撃が既に見つかっているようですし

【CRYPTO-GRAM日本語版】解読されたSHA-1」によれば、2の69乗回の演算でSHA-1衝突を発生させる手法が明らかになったとのこと。2005年時点では、

2の69乗回の演算には3年3カ月を要する。開発に2500万~3800万ドルをかけられるならば,56時間に2の69乗回の演算を処理できるシステムも実現できるだろう。

としています。

その後、さらに計算回数を減らせるというレポートも出たようです。

ただ、愉快犯を別にすれば、アタッカーもプロですので、これだけのコストをかけて破るに値するシステムでなければ攻撃してきません。

残念ながら、私が関わっているシステムでは、そこまで重要度の高いものはありません。


固定のsalt値であると同一のパスワードを設定したときにハッシュ値が同じになってしまいます

これは、salt 値を乱数にするかどうかという問題とは関係なく、運用上の問題になります。

SHA-1の出力は160bit、これに対してパスワードは英数8文字程度の56bitですから、実はパスワードを総当たりで解く方が早いんですね(笑)。

SHA-1の衝突を気にするようなシステムは、少なくともパスワードの長さが英数23文字以上であるようなシステムになります。


参考書籍

id:studio15

丁寧な回答ありがとうございます。

やはり、攻撃の効率と保存されているデータの重要度のバランスが肝なのですね。

2008/06/14 22:03:21
id:memo77 No.2

memo77回答回数238ベストアンサー獲得回数202008/06/14 20:27:46

ポイント40pt

割合などは知りませんが、大手ベンダーでも平気で平文のパスワードを提案してきたり、暗号化やハッシュの仕組みについてほとんど知らないという経験を複数しています。

実際にパスワードの変更字に平文のままメールで送りつけてくる大手サービスもまだありますよね。

まえに下記のような質問もありました。

http://q.hatena.ne.jp/1207182796


パスワードは単一のシステムとしてみるのではなく、ユーザーが複数のシステムで同じものを使うということも念頭において設計しないといけません。

ここ数年でだいぶ状態は改善されると思うんですけどね。


パスワードとsoltではなく、ユーザーIDとパスワードとsoltにすれば、ハッシュ後の重複は気にしなくてよくなります。

まあいまなら私はsha256で組むかなぁ。

id:studio15

回答ありがとうございます。

>まあいまなら私はsha256で組むかなぁ。

ちょっとここの根拠が知りたかったです。

2008/06/14 22:04:59
id:redwing1 No.3

redwing1回答回数541ベストアンサー獲得回数32008/06/17 02:28:45

phpではそうかもしれませんね。webデザイナー程度が書いているので。

もっとUNIXのシステムを利用すればいいのに。

http://www

  • id:memo77
    なんか回答としてつけるほどのことでもないので、コメント開くのを待ってました。
    別にSHA-256なら大丈夫という理由はなく、下記記事などを読んで「まだまし」という程度の判断です。


    http://www.atmarkit.co.jp/fsecurity/rensai/crypt01/crypt02.html
    >そこで、NISTは、SHA-1に大きな問題が生じる前に、少なくとも新規の米国政府の情報システムからはSHA-1の利用を縮小させ、2010 年までにはSHA-2(具体的にはSHA-256)に移行するよう誘導している。実際、「Recommendation for Key Management」[参考文献6]や「Cryptographic Algorithms and Key Sizes for Personal Identity Verification」[参考文献7]では、ガイドラインとしてSHA-1からSHA-256に変更するよう具体的に求めている。


    記事中にもありますが、SHA-256もSHA-1の設計の延長線上ですので、10年は持たないのかもしれませんね。
    自分の設計するシステムでそこまで重要かつ長期間運用するものはないので、まあいいんですが。


    とりあえず適時動向を追いかけることが大事だと思います。


    ps.saltの綴りをsoltと間違えていて恥ずかしかった・・・

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません