web-dev-qa-db-ja.com

既知のパスワードを使用してハッシュされたパスワードをクラックする

私は仕事で書いた新しいダッシュボードをデプロイしようとしている開発者です。古いものはハッキングされたライブラリのめちゃくちゃで、コードベースの約半分しかまだ使用されていません(削除されていないすべての場所でデッドコード、しかし何もしません)...

私はこのナンセンスなことにもう1秒間自殺するつもりはありません。ユーザーが(まれに)パスワードをデフォルトから変更したアカウントからユーザーノートを取得しようとしています。デフォルトのパスワードの保存されたハッシュ文字列、それがどのパスワードに変換されるか、使用されているハッシュメカニズム、使用されている暗号化方法、および他のパスワードのハッシュ文字列があります。

他のパスワードを解読するためにこの情報を使用する簡単な方法であるだけがある

これが不可能な場合、理由を誰かに説明してもらえますか?私はハッシュの一方向の性質を取得しますが、プロセスについてエンドツーエンドで多くの情報を持っているので、本質的にプロセス全体がわかっているので、この例で問題になるかどうかはわかりません...

要約するには:

ハッシュと暗号化のメカニズムの知識を、サンプルのハッシュ文字列とその平文の値とともに使用して、同じコードで作成された他のパスワードを解読できますか?

PS:役立つ場合、各デフォルトハッシュは、いつ作成されたかに関係なく同一です...

17
MJHd

あなたの質問は少しわかりにくいので、以下があなたの状況に完全に適合しない場合は、次の仮定を修正してください:

  • システムは複数のユーザーの暗号化されたデータを保存します。
  • 各ユーザーのデータは、ユーザーごとの一意のキー、またはユーザーごとのキーで暗号化(ラップ)されたマスターキーを使用して暗号化されます。
  • 各ユーザーのキーは、ユーザーのパスワードから派生した、またはユーザーのパスワードから直接派生したキーで暗号化(ラップ)されています。
  • 一部のユーザーのパスワードを知っているが、他のユーザーのパスワードを知らない。
  • 認証に使用されるパスワードハッシュアルゴリズムを知っています。
  • 認証ハッシュにアクセスできます。
  • 認証ハッシュはソルト化されていません(「各デフォルトハッシュは同一」)。
  • パスワードからの鍵の導出に使用されるアルゴリズムを知っているか、アクセスできる。
  • パスワードがわからないユーザーのデータを復号化したいとします。

システムについての詳細(使用されている暗号、使用されているハッシュ/キー導出アルゴリズムなど)がわからなければ、攻撃するシステムの最も弱い点を必ずしも見つけることができません。ただし、説明したように、脆弱なリンクはパスワードハッシュのようです。特定のパスワードで実際に同じである場合、それらはソルト化されていないことを示しています。これは、非常に弱いパスワードハッシュスキーム(おそらく単一ラウンドのMD5と同じくらい悪いもの)を意味します。無塩ハッシュの場合、おそらくレインボーテーブル(事前に計算されたハッシュダイジェストを入力値にマッピングするルックアップテーブル)を使用できます。ただし、それができない場合(たとえば、必要なパスワードが、見つけることができるテーブルに存在しない場合)でも、そのようなハッシュの総当たりは通常、非常に簡単です。最新のコンシューマーGPUは、文字通り数十億回の毎秒のハッシュを実行できるため、必要なのは適切なハードウェア(ローカルまたはクラウド)、候補のパスワードのセット(および、可能性のあるすべての文字を文字通りブルートフォースすることを含む、より多くを生成するプロセス)です。与えられた長さまで)、「ハッシュキャット」や「リッパージョン」などのソフトウェア、そしてしばらくの間。


質問にもっと直接対処するには:すべての最新の暗号化およびハッシュ標準は、攻撃者が正確にアルゴリズムのステップが何であるかを知っている場合でも、安全である必要があるという前提で動作します。アルゴリズムを知ること-ハッシュアルゴリズムの(入力、ダイジェスト)ペアを知ることの値を厳密に支配します。これは、入力とアルゴリズムがあれば自分でダイジェストを計算できるためです-すべての最新の暗号化が必要とするベースラインの仮定です。に対して安全である。暗号化またはハッシュアルゴリズムを解読するために数百万(寛大にしましょう)の100万の入力/出力ペアが十分である場合、暗号化はあまり価値がありません。

24
CBHacking

簡潔な答え:

ハッシュを復号化することはできません。それを回復するには、他の手段を使用する必要があります。

説明:

ハッシュの結果は、パスワードの暗号化バージョンではありません。ハッシュブラウンを取得して完全なポテトを再構築できる以上に、復号化できません。暗号化ハッシュの結果は、元のデータの多くが失われた、データのスクランブルされたバージョンです。失われたデータが何であったかは推測できますが、おそらく間違っているでしょう。暗号化ハッシュ関数では、ある時点で少し間違っていると、計算されたデータが元のデータと大きく異なります。

ただし、古いシステムのソースコードにアクセスできる場合は、別の方法でデフォルトのパスワードを回復できます。 3つの可能性があります。

  1. これはデフォルトのパスワードであり、このパスワードは誰にとっても同一であるため、元の開発者はパスワードのセキュリティをあまり考慮していませんでした。ユーザー作成に関するソースコードを確認してください。パスワードはプレーンテキストで保存できます。

  2. デフォルトのパスワードは、どういうわけか新しいユーザーに通知する必要があります。新しいアカウントを作成するか、IT管理者に問い合わせるか、または新入社員にパスワードを提供する人事担当者に問い合わせてください。

  3. (やや怪しい)パスワードを古いシステムから新しいシステムに卸売りでコピーすることもできます。ユーザーがデフォルトのパスワードを使用してログインすると、認証システムがそれを確認している間、それが平文で表示されます。パスワードは保存されたハッシュと一致します。これを機会として、全員のパスワードをPBKDF2、bcrypt、scrypt、Argon2idなどのキーストレッチアルゴリズムに切り替えます。

そして、これらすべてが失敗した場合は、ユーザーに電話をかけ、状況を説明し、彼らがあなたの仕事を見てすぐにパスワードをリセットできる時間をスケジュールします。 (これは回避したい状況であるとコメントで述べられているので、私はこれを最後のオプションとしてのみ使用しています。)

すべての場合において、パスワードをただちに期限切れにする必要があります(単に侵害したため)。ただし、デフォルトのパスワードを使用すると、アプリケーションにパスワードの有効期限機能が含まれていない可能性が高いため、これは問題になる可能性があります。

そして、認証システムに取り組んでいる間、 NISTデジタルIDガイドライン にアクセスし、全体を参照して、SP 800-63B。

40
Ghedipunk

簡単な例を挙げて、ここに答えを追加します。基本的なことを減らすことは、多くの場合非常に有益であることがわかったからです。重要なのは、ハッシュアルゴリズムがデータを破壊することです。 Argon2ハッシュalwaysは、Wikipedia全体にフィードした場合でも32バイトです。これを実現する唯一の方法は、大量のデータを破棄することであり、一度破棄すると消えてしまいます。

簡単な(そしてひどい)ハッシュアルゴリズムがあることを示すために。入力の大文字をチェックします。大文字が見つかった場合は、Trueを出力します。そうでない場合は、Falseを出力します。入力と出力の例をいくつか示します。

123456 -> False
asdfer -> False
rfjeif -> False
27_+$( -> False
weAdfy -> True
ErYHV1 -> True
12345W -> True
WERERE -> True

今私はユーザーのハッシュを持っており、それはTrueです。パスワードは何でしたか?

27
Conor Mancone

いいえ、既知のパスワードに関する情報は、未知のパスワードを解読するのに役立ちません。

ハッシュは一方向のトラップドア機能の結果です。ハッシュ化は暗号化とは異なりますが、ハッシュ化は元に戻すことができます。ハッシュは情報を破壊し、安全なハッシュから元のパスワードを再構築する方法はありません。元のパスワードにわずかな変更がある場合、結果のハッシュは完全に異なります。したがって、2つのハッシュを比較して、元のパスワードが類似しているかどうかを確認することもできません。

多くの open-source プロジェクトは、アプリケーションのパスワードがどのようにハッシュされるかを開示しています。これにより、ハッシュの安全性が低下することはありません。既知のパスワードとハッシュの組み合わせで構成されるデータベースもあります。これらは、データベースにとって未知のパスワードを解読するのに役立ちません。

パスワードをクラックする従来の方法に任されています。通常、パスワードをハッシュと一致するかどうかを確認するために、自動化された方法で可能なパスワードを試すことが含まれます。これは、58回の電話よりも簡単でも速くもありません。

7
ig-dev

短い答えはあなたが持っているすべての情報は助けですが、58回の電話をかけるのに時間をかけたくない場合は、あなたは気に入らないでしょうすべての内部情報があっても、数週間/数か月/数年かかる場合があります。

これを考慮してください。どこでもすべてのパスワードシステムはあなたのものと同じです。彼らはハッシュとシステムを知っており、テストするために自分のパスワードをいくつでも作成できます。また、ハッシュはstillであり、これらの条件下でも安全と見なされます。

あなたがハッシュを実行して、ハッシュに対してパスワード辞書を実行して、ユーザーが推測可能なパスワードを使用しているかどうかを確認します。しかし、それでも100%にはなりません。

4
schroeder

ゲディパンクはこの解決策に言及していますが、私はそれを拡張したいと思いました。

ハッシュメカニズムを正常に複製できる場合は、ユーザーのパスワードをジャストインタイムで更新できます。

つまり、ユーザーがログインするときに、アカウントの資格情報が古い方法を使用して保存されているかどうかを確認します。正しい場合は、古いメソッドに対して資格情報を検証し、すぐにアカウントを新しい(安全な)資格情報にアップグレードします。

新しいシステムでは、古い方法を使用してexpiringすべてのユーザーアカウントにパスワードの変更を強制することをお勧めします。

パスワードをハッシュとして暗号化して保存するポイントは、管理者を含む誰もプレーンテキストのパスワードを発見できないようにすることです。

最後に、あなたや他の人にとって、古い認証方法が安全であることが判明し、ベストプラクティスに従っている場合、新しい方法を利用する必要はありません。古い認証方法を新しいシステムに移動するだけです。

3
Nathan Goings

間違えている

「しなければならない」というものはありません。これを確認するには、これだけを考慮する必要があります。方法がある場合、前の従業員からパスワードを保護することはできません。そして、あらゆる従業員から。そして、誰からでも、本当に。

anybodyが元のデータを表示するのを防ぐために、パスワードは暗号化ハッシュで保存されます。これにはあなたが含まれます。

パスワードを解読する必要はありません

新しいシステムと新しい完全なログインプロセスを担当します。古いプロセス全体を知っています。したがって、新しいシステムでは、古いパスワードデータベースと古いプロセスのコピーのみが必要です。

新しいシステムでのログインが失敗した場合は、古いパスワードデータベースで前のプロセスを実行して、新しいシステムでの古いログインを自動化します。

また、新しいログイン認証情報を作成し、成功したら古いデータベースエントリを削除する必要があります。そうすれば、どのユーザーも問題なく移行できます。

2

他の回答では、パスワード直接を回復することはできません。

ただし、必要なデータがユーザーメモである場合、他のオプションがあります。

DB管理者ユーザー

バックエンドへの正当なアクセス権があると想定すると、データベースの管理者ユーザーとしてデータをプルできます。 (Trotski94のコメントを参照)

MITM

新しいダッシュボードをデプロイして、ユーザー(与えられたのパスワードが入力された場合にのみ新しいデータをインポートすることができます。これは事実上MITMです。 (Conor Manconeとeckesのコメントを参照)

ハッシュキャット

これらのオプションが失敗した場合は、hashcat(パスワード回復ツール)に対してハッシュを実行します。少なくとも、必要な電話の回数を減らすことができます。

結論

残念ながら、最初のオプションを除いて、電話をかけるだけの努力はおそらく少なくなります。

1
Glen Davies

番号。

まともな一方向暗号化の要点は、暗号化の仕組みを理解するだけでは、暗号化を元に戻すには不十分であることです。

そうでない場合、あなたのような人々は、あなたが私たちにあなたが持っていると私たちに伝えた少量の情報だけで他の人々のデータを解読することができます。

それがセキュリティではないことは自明です。

これらのアルゴリズムは、文字通り、ユーザーが実行しようとしていることを阻止するように設計されています。

また、この場合の暗号化はハッシュであり、ハッシュへのデータの1対1のマッピングはありません。あなたは一方向ハッシュの概念を理解していると主張していますが、あなたにはまだやるべきことがあるようです!

シンプルに定義します。

アルゴリズムを知っており、例を挙げてそれを検証できる場合、他のパスワードを「ブルートフォース」するのは簡単です。

十分なリソースと時間が与えられます。スペースをブロック(作業単位)に分割し、並行してテストすると、より簡単になります。クリックの狂乱によるリソースの干ばつがなければ、GPUインスタンスやCUDAがなくても、1日未満で10万のスレッドが15文字に達する可能性があります。これは、ブロックチェーン、自宅での折りたたみ、自宅でのSETIなどで日常的に行われます。

Hashcatは開始するのに適した場所ですが、ハッシュが切り捨てられているか部分文字列である場合でも、マスクと比較するためにコードを微調整する必要があります。おそらくこれのために「アントマイナー」をカスタマイズすることはできないでしょう。

もちろん、パスワードを既知の値に更新(上書き)して、強制的にリセットする方が簡単です。開発では、ハッシュを任意のパスワードのハッシュに更新するのが一般的です。

問題の根本にあるのは、ユーザー(または従来のシステム)がパスワードの有効期間や変更を追跡していないことです。パスワードを変更していない、または時間をかけた、または変更頻度の低い人のみのデータを抽出しますか?

「group by」と「order by descending」を試しましたか?それらがすべて同じデフォルトのパスワードを持っている場合、それらはその一番上に浮かぶでしょう。

私は、レガシーストアと「モダン」ストアを使用した、最終的な移行のアイデアをサポートします。

0
mckenzm