ハッカーが強力なパスワードを解読する時間を推定する方法
親切なハッカーが私たちのWebサイトにSQLを挿入しただけで、10個の小文字の管理者パスワードのハッシュが取得されました。 SALTを知らずに半日かけてクラックしました（サイトはオープンソースであるため、「sha256」を使用していることを知っています）。
今、マネージャーは幸せではありません。明らかに、そのsql-injectホールにパッチを適用することを除いて、アルゴリズムを予測不可能な何か、強力な管理パスワードに変更する必要があります。
考慮すべき点：
パスワードは「MyB0y6thJan @）！％」のように強力です。私の男の子は2015年1月6日->覚えやすいです。またはパスフレーズ「私たちはこのウェブサイトが大好きです」
通常、ハッカーはプロのハッカーであり、常に私たちを攻撃します。彼らは10〜100台の強力なコンピューターにアクセスできる場合があります。
ハッカーはオープンソースのようにsha256を使用していると思うかもしれませんが、bcryptのような強力なものに変更します。
毎月パスワードを変更します。
質問：将来的にSQLインジェクションを使用してハッシュを取得できた場合、ハッシュをすばやくクラックできるでしょうか？
P/S：私は多くの同様のトピックを読みました：
bcryptを使用してパスワードをクラックする時間を見積もります 。
ブルートフォーステクニックを使用してハッシュをクラックするのにかかる時間をどのように見積もるか
しかし、私は今でもとても混乱しています。多くの人々（ハッカーを含む）は、ハッシュパスワードは時間の問題で元の形式に解読される可能性があると主張しています。多くの人が、たった1つを解読するには数年かかると言いますが。
パスワードの作成方法がわからないまま、パスワードの解読にかかる時間に答えることはできません。あなた（または親戚）の誕生日、住所、ミドルネームなどに基づいてパスワードを作成する場合、 Kerckhoffsの原則 のため、週のパスワードであると想定されます。攻撃者がこの情報を知っているかどうかはわからないので、攻撃者が知っていると想定し、使用することに決めた形式を知っていると想定するのが最善です。
デモのために、彼らはあなたの家族について何も知らないが、彼らはあなたがあなたのパスワードをMy[B0y or G1rl][day of month with suffix][abbreviated month][symbols on keyboard corresponding to year]としてフォーマットしたことを知っていると仮定しましょう。それは男の子か女の子の2つの可能性、月と日の365.25、そして寛大で、年の50としましょう。 2 * 365.25 * 50 = 36,525。それは何もありません。攻撃者は、相当数のハッシュを実行しなくても、数百の同様の方法を試すことができます。
パスワードの強度を確実に推定する唯一の方法は、パスワード生成方法に基づいて推定することです。パスワード生成方法が10のランダムな英数字を生成することである場合、62のセットからランダムに1つのパスワードを選択します。10 パスワード。平均して、攻撃者は可能なパスワードの半分を試した後でパスワードを推測します。したがって、非常に幸運でない限り、攻撃者はおよそ62のパスワードを推測する必要があります10/ 2 = 419649682934170112回推測します（もちろん、運が良ければ、これは高くも低くもなります）。
これは 8x GTX 1080ベンチマーク がしばらくの間浮かんでいるため、攻撃者がこれを使用していると想定すると、1秒間に2,000億回のmd5ハッシュまたは826 bcrypt *ハッシュを実行できます。 ASICでいっぱいの部屋があると心配している場合は、その10億倍かかります（ただし、bcryptはASICにある程度耐性があります）。 bcryptを使用した最悪のシナリオは6210/2/826000000000 = 508050秒、これはほんの数日ですが、私が知る限り、bcrypt ASICがまだ存在する可能性はほとんどありません（または、存在する場合はそれほど高速です）。もちろん、10個ではなく12個または15個のランダムな文字を使用することで、これを簡単に大幅に改善できます。
* 12のコストを想定します。ベンチマークはコスト5で105.7 kH/sを与えるため、105700/2 ^（12-5）≈826 H/sです。
簡単に言えば、答えはなく、パスワードを解読する時間の長さは、1）長さと2）複雑さに直接比例します。これは、SANSの組織から直接です。
強力なパスワードは長く、文字数が多いほど強力なパスワードになります。パスワードは14文字以上にすることをお勧めします。さらに、複数の単語で構成されるパスフレーズ、パスワードの使用を強くお勧めします。たとえば、「休暇の時間だ」や「好奇心旺盛な晴れ葉」などがあります。パスフレーズは覚えやすく、入力も簡単ですが、強度の要件を満たしています。
複雑で長いパスワード（16文字以上など）を使用している場合、解読に何年もかかる可能性があります。ただし、辞書の単語を使用したり、Wordを使用して文字を数字で並べ替えたり、記号（例：P @ $$ w0rdには、数字、大文字、記号が含まれていますが、適切なパスワードではありません）。
this one のようなランダムパスワードジェネレータを使用することをお勧めします。
最後に、パスワード自体は、自分のサイトやインフラストラクチャを保護するには不十分です。定期的なペンテスト、スキャン、脆弱性評価、および fail2ban などのツールの実行を検討してください。 SQLインジェクションは、入力を無害化することで比較的簡単に保護できますが、最初に脆弱性を理解するのに時間がかかります。パスワードを保護するだけでも、他人がpass-the-hashなどのエクスプロイトを使用してサイトをハッキングする可能性があります。セキュリティは階層化されたアプローチであるため、特定のセキュリティ障害に焦点を当てることは賢明なアプローチではありません。
ここでの他の回答は尋ねられた質問に対処していますが、OPは実際には問題に対処していないという印象を受けます。つまり、これは答えではなくコメントです。
sALTを知らずに管理者パスワードのハッシュを取得する
これはむしろ、ソルトがハッシュとは無関係に保持されることを意味します。これは、ソルトがランダムに生成されておらず、アカウントごとに一意ではないことを示唆しています。それは良いことではありません。
私たちのウェブサイトにSQLを注入しただけです
あなたはすでにSQLインジェクションの脆弱性を防ごうとしていると思いますが、これはアプリケーションが認証情報を含むテーブルに直接アクセスできることも意味します。エーク！既知のSQLIの脆弱性を修正した場合でも、このデータへのアプリケーションのアクセスは、権限を分離したSQLプロシージャを介して仲介される必要があります。
明らかに、アルゴリズムを予測できないものに変更する必要があります
番号。
まず、 sha256 は、パスワードの検証に使用するアルゴリズムの一部にすぎません。他にも考慮すべきことがたくさんあります。 sha256を計算コストの高いものに置き換えるだけでは、パスワード検証の他の問題は解決されません。
より大きな画像を検討することをお勧めします。
彼の答えでは、SomeGuyは大きくランダムなパスワードの使用を提案しています。これは、ハッシュのブルートフォーシングに対処しますが、他の場所でミスを犯した場合には役に立ちません。また、どこかでパスワードを記録する可能性が高くなります。うまくいけば、ポストイットのメモではなく、適切なパスワードマネージャーでそれを実行できますが、前者でも100％信頼できるとは限りません。あなたは攻撃面を増やしました。
毎月パスワードを変更します。
NISTとGCHQはどちらも、この最近の知恵に比較的最近挑戦しています。確かに、あなたが説明した攻撃に対する保護は提供されなかったでしょう。パスワードの複雑さに関する議論のとおり、パスワードを頻繁に変更するほど、パスワードが伝達され書き留められる可能性が高くなります。
アプリケーションとそのオープンソースのコードを変更できるとすれば、私は次のことをお勧めします。
sha256（）の呼び出しに関するコードラウンドを詳細に調べます。パスワードストレッチ機能を使用していることを確認してください。
アカウントごとにランダムに生成された一意のソルトを使用する
2要素認証を実装します（特権またはユーザー設定に基づいてこれを有効にする機能があります）
あなたはパスワードハッシュデータの特権分離を検討します