sha256でパスワードをハッシュ化するだけで安全か？

Question

パスワードをデータベースで保存します。

その際に、sha256でソルト値与えて、ハッシュ化してそのままDBに保存します。
パスワードを復元するつもりはございません。

これで安全でしょうか？

Answer 1

ハッシュは辞書攻撃に弱いのでソルトを追加しますがソースコードも一緒に流出するとソルトもバレます
なので全部の解析に膨大な時間がかかるようにストレッチ（複数回ハッシュ関数を通す）という処理を行います

難読化目的のハッシュ関数は時間とともに劣化していくと考えたほうがよくて、いつかは破られるので
アルゴリズムを変更できるようなデータ構造も必要です。
データを格納するとき、ハッシュ値に加えバージョン番号やストレッチ回数などを追加してアルゴリズム変更にたえらるようにします

このような処理を行うためのbcryptというアルゴリズムがあります。
bcryptはBlowfishをハッシュアルゴリズムに使っていることが多いですが、72文字切り捨て問題を除けば耐性の高いアルゴリズムと言われています。

Answer 2

既に他の方が書かれている通り、安全ではありません。
PBKDF2（NIST規格のパスワードハッシュ化規格）やcrypt+blowfish（デファクト標準のパスワードハッシュ化規格+BCryptのblowfishハッシュ）でも、安全ではありません。
まず何故パスワードをハッシュ化するのか？その理由を知る必要があります。

パスワードをハッシュ化する理由は

• システム管理者などでもユーザーのパスワードを”容易に”知りえないようにする
• 攻撃者の攻撃によりパスワードデータベースが盗まれてもパスワードを”容易に”知りえないようにする

の2つがあります。

”容易に”とクオートした通り、PBKDF2やcrypt+blowfishの標準的なパスワードハッシュ化方法に従っても”必ず”パスワードを知りえないようには出来ません。パスワードの解析に時間がかかるようにしているだけです。

PBKDF2やcrypt+blowfishを使ってもパスワードを知りえる事の証明は簡単です。パスワードがユーザー名と同じ、簡単に推測できる文字列なら容易にパスワードを知り得ます。PBKDF2やcrypt+blowfishを使っても、弱いパスワードは保護できません。

従って、PBKDF2やcrypt+blowfishを利用する場合でも、ユーザーが設定するパスワードが十分な強さを持っていることがパスワードを保護できる条件になります。

理想的にはパスワードは十分に長い暗号学的にランダムな文字列である必要があります。覚えるパスワードにランダムパスワードは厳しいので少し工夫が必要です。覚えないパスワード、覚えるパスワード、どちらとも比較的長い文字列が必要です。

従って、PBKDF2やcrypt+blowfishを使っていても安全にパスワードを保存できるようにするには

• ユーザーが弱いパスワードを設定しないようにする
• 上記の為にパスワードの長さ制限を短くしすぎない（最低でも64バイト以上の制限にする）
• 十分なストレッチを行う

といった対策が必要です。

これらに加えて、システムログなどにパスワードが記録されないようにする、ネットワーク通信で盗聴できないようにする、必要があります。システムログに記録したり、非暗号化通信で平文パスワードを送信してしまうとシステム管理者などが容易にユーザーのパスワードを知り得ます。

非暗号化通信でもパスワードを安全にやり取りできるチャレンジレスポンス方式もありますが、説明は省略します。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
生かさせて頂きます。

[YasuoOhgaki]

blowfishを使うがベストアンサーになっていますが、salt+blowfishハッシュを使うだけ、では”不十分”です。

なぜcrypt+blowfishを使うと十分だと考えられている理由は"ストレッチ"にあります。ストレッチ（Streching）とはその意味の通り、強さを伸長する、ことで”ハッシュ関数”を繰り返し適用することで力ずくの解析をより困難にします。crypt+blowfishを使っていてもストレッチが不十分だと、十分に安全とは考えられません。

ストレッチ無しのsaltとハッシュ関数だと力ずくの解析がかなり容易になります。

PBKDF2+SHA2なら最低でも1万回、crypt+blowfishなら最低でも千回以上のストレッチが必要です。blowfishは遅いのでストレッチングが少なくて済みます。これも昔の基準なので実際にはもっと多いストレッチングが必要です。ただ、多くしすぎるとDoSに脆弱になったりもするので多すぎるストレッチも問題になります。PDKDF2+SHA2を利用するパスワードマネージャーなどでは10万回や100万回のストレッチをしている物があります。これらの数値は参考になると思います。

Answer 3

安全かどうかを検討するには、まず想定される脅威を定義する必要があります。
脅威の分析から始めてください。

追記
パスワードのハッシュ化は、総当たり攻撃や単純なパスワード対策としては意味を持ちません。
別の方法を検討する必要があります。

一般的にハッシュ化が有効と言われるのは、「DB データ流出時の時間稼ぎ」です。
これも適切なハッシュ化とストレッチングやパスワード文字列の複雑性の保証等の複合評価なので、質問にある内容では不十分です。

一方で、質問にある方法は「DB 管理者のカジュアルな覗き見」に対しては有効です。

想定する脅威がわからなければ、安全性の評価は無意味です。

Answer 4

安全かどうかを質問されると恐らく多くの方は’保障はねぇ’となるでしょう。

私の回答は’とりあえず使えるかも’でも破る気になれば。となる気がします。

Answer 5

何をもって安全と考えるかです。もっとも、セキュリティにおいて完全な安全はありえません。

また、最低限の機能要望を提示しなければ、極論、全サービスを捨てるという結論になりかねません。

平時の利益はどれだけか？
異常の発生率はどれだけか？
異常時の損害はどれだけか？
→結局、採算が取れるものか？

と、リスクを定量分析しなければセキュリティに答えは出ません。

Answer 6

システム構成がよく分かりませんが。

まずハッシュ化と暗号化は違います。
パスワードに対してsha256を使ってハッシュ化するのではなく鍵導出関数を使用してくださいな。
PHPならpassword_hash、他ならArgon2

---

暗号という言葉を回答に入れたのが間違いでした、暗号という言葉は忘れてください。
私が言いたいことは、暗号ハッシュ関数(SHA-256)を使って自作するのではなく、鍵導出関数(Argon2)を使用してください。
質問文にストレッチングという文字がなかったので、ハッシュ化するときにストレッチング処理が入っていないのではと思いましたので。

◇参考情報
パスワードはハッシュ化するだけで十分?
ユーザー アカウント、承認、パスワード管理に効く 12 のベスト プラクティス

Comments

[MasahikoHirata]

そうですね。回答していて’モヤモヤ感’がありました。ただ質問が’これで安全か？’の質問でしたので。

[退会済みユーザー]

ハッシュ化→平分を復元しづらくする。
個人的にはこれでパスワードは盗まれても復元に苦労するかな、と思ったのですが、
ハッシュ化する前に暗号化することは何に対する対策なのでしょうか？

[退会済みユーザー]

ハッシュ化することによって、パスワードを盗まれても復元に苦労するかなと思いました。
なので、ハッシュ化で十分と思いましたが、
暗号化は何に対する対策なのでしょうか？
これも、復元に苦労するようにするためなのでしょうか？

Answer 7

DBのデータのみが流出した場合、ユーザーIDがわかるのであれば、ID+想定パスワード等で認証を試みることが出来ると思います。
この場合は、パスワードの設定要件(文字数や文字種)と利用ユーザーの設定パスワード次第になると思われます。
また、他サイトで流出したパスワードに、対象ユーザーのIDとパスワードがあれば、認証できる可能性が高いかと。

DBデータとソルトが分かれば、解析するのもありかと思います。
(やったことはないので、想像の範囲ですが・・・)

Answer 8

「パスワード」と「パスワードをハッシュ化したもの」はまったく別の情報です。
したがって、「パスワードをデータベースで保存」したことにはなりません。
パスワードを保存したくないからハッシュ化します。

ハッシュ関数の程度として sha256 は十分だと考えますが、
そもそもハッシュ化によってどんなメリットを得ようとしているかによると思います。

Answer 9

It is safe because mostly sha-256 implemented for security purpose, if need more security then use merkel trees with sha-256