数年前、大文字、小文字、記号、数字で構成されるランダムな 8 文字のパスワードを解読するのは非常に困難でした。場合によっては、このようなパスワードの解読には何年もかかりました。
今日のテクノロジーの変化とレンタルデバイスのおかげで、この時間は数時間に短縮されました。しかし、そもそもこれらのパスワードはどのように保存されるのでしょうか?確認する パスワードは過去のもの:今年段階的に廃止される理由.

クイックリンク
パスワードはオンラインでどのように保存されますか?
システムがパスワードを保存するデータベースは攻撃者が制御できるため、システムはユーザーのパスワードをファイルやデータベースに直接保存しません。代わりに、システムはユーザーの詳細を暗号化し、攻撃者は各パスワードの暗号化されたバージョンに直面することになります。
システムがパスワードを暗号化するために使用する高度なアルゴリズムがいくつかあります。これらのアルゴリズムの 1 つは対称暗号化アルゴリズムです。これは、暗号化と復号化の両方に同じキーを使用できる暗号化のタイプです。対称暗号化アルゴリズムのセキュリティには、復号化専用のキーが 1 つしかないため、ある程度のリスクが伴います。このため、システムは通常、対称暗号化アルゴリズムを使用しません。
一般に、システムで暗号化に使用される方法はハッシュ アルゴリズムです。これは、データの暗号化ではなく、データの整合性と表現を検証することを目的としています。ハッシュ アルゴリズムは、データを固定サイズのハッシュに変換します。通常、データの一意のハッシュを表します。ハッシュ関数は、任意のサイズのデータの固定長データをマップとして作成する必要があります。
ハッシュ アルゴリズムのおかげで、攻撃者がパスワードを含むデータベースを乗っ取った場合、そこからパスワードに逆方向にアクセスすることはできなくなります。ここで注意すべき非常に重要なニュアンスがあります。理論的には、すべてのパスワードの組み合わせに同じハッシュ アルゴリズムを使用するシステムを侵害した攻撃者は、得られた結果を比較することができます。これらの比較の結果、攻撃者が同じ値を取得した場合、攻撃者はパスワードの公開バージョンを発見したことになります。この方法はすべて試行錯誤であり、このタイプの攻撃は一般にブルート フォース攻撃と呼ばれます。
8 年代初頭、一般的なハッシュ アルゴリズムを使用して暗号化された 123456 文字のパスワードの組み合わせをすべて試すには数百年かかりました。もちろん、「XNUMX」や「mypassword」などの非常に単純な組み合わせはこのグループには含まれません。今日のソフトウェアおよびハードウェア技術の発展に伴い、パスワードを解読する方法も大きく変化しました。確認する パスワード マネージャーのセキュリティは信頼できますか?
グラフィックスカードの登場による影響

グラフィックス プロセッサ (GPU) の並列データ処理能力は、時間の経過とともに向上してきました。グラフィックス カードは、汎用 CPU のような多彩な操作を実行できません。したがって、多くのコアと並列処理能力があるとしても、プロセッサのようにそれらをほぼすべての問題に使用することは意味がありません。
ただし、パスワードに使用される一部のハッシュ アルゴリズムは、GPU 上で非常に効率的に実装できます。従来の CPU で達成できる 1 秒あたりのハッシュ数は、新しいグラフィックス カードによって劇的に増加しました。
アイデアを得るには、以下の表で NTLM、MD5、SHA1 などのハッシュ アルゴリズムの 25 秒あたりのハッシュ数 (ハッシュ レートという用語は、コンピューターがハッシュ計算を実行できる速度を指します) を調べてください。現時点では、これらのアルゴリズムが単なるハッシュ アルゴリズムであることを知っていれば十分です。このテーブルを作成するために、XNUMX 個の AMD Radeon GPU のクラスターを使用しました。
| アルゴリズム | 1 秒あたりのハッシュ数 |
| NTLM | 350.000.000.000 |
| MD5 | 180.000.000.000 |
| SHA1 | 63.000.000.000 |
| SHA512クリプト | 364.000 |
| Bcrypt | 71.000 |
| スクランプ | 33.000 |
ご覧のとおり、このようなシステムを使用すると、NTLM ハッシュを 350 秒あたり 8 億回生成できます。つまり、6 文字のパスワードの組み合わせをすべて XNUMX 時間以内に試すことができます。さらに、この例のハードウェアは何年も前に遡ります。今日のパスワードクラッキングの力を想像してみてください。
ソフトウェア開発者は何をすべきでしょうか?

プログラマーが進むべき道は非常にシンプルです。パスワードを暗号化する際には、ハッシュ値の計算に時間がかかるアルゴリズムを優先する必要があります。開発者は、使用しているアルゴリズムが CPU 上でどのように動作するかだけでなく、グラフィックス カードの世界に対するアルゴリズムの回復力についても知る必要があります。
開発者が Django、Ruby on Rails、Spring Security などのパスワード暗号化も処理するソフトウェア フレームワークを使用している場合は、セキュリティの観点からフレームワーク内で正しい決定が行われているかどうかを確認する必要があります。
たとえば、次のように使用します 通貨 は、Ruby on Rails でのユーザー操作に最も広く使用されているライブラリの 1 つで、デフォルトのハッシュ アルゴリズムとして Bcrypt を使用します。また、別のメソッドをハッシュ アルゴリズムとして使用することもできます。 Bcrypt アルゴリズムは、グラフィックス カードが適切な点に到達するまでに依然として長い時間がかかるため、信頼性が高くなります。
つまり、ハッシュ値の計算に時間がかかるほど、安全性は高まります。
パスワードには何文字を含める必要がありますか?
使用する文字が増えるごとに、パスワードを解読して安全性を高めるために必要な試行錯誤の回数が幾何級数的に増加します。
この状況を 2 つの異なるシナリオを通して考えてみましょう。 NTLM ハッシュ アルゴリズムに関する上記の表の値を考慮し、パスワードを解読しようとしていると想像してください。 8 文字以上のパスワードをターゲットにすることを想像してください。
| 文字数 | 大文字/小文字と数字 | 大文字/小文字、数字、特殊記号 |
| 8 | 1分未満 | XNUMX分 |
| 9 | XNUMX分 | サイアスティン |
| 10 | サイアスティン | 一週間 |
| 11 | XNUMX日 | XNUMX年 |
| 12 | XNUMX年 | 200 |
| 13 | 100年以上 | 1000年以上 |
表を調べると、大文字/小文字、数字、特殊記号をすべて組み合わせて使用する場合、少なくとも 12 文字のパスワードを使用することが安全であることがわかります。特殊文字を使用しない場合、安全なパスワードの長さに達するには 13 文字を使用する必要があることがわかります。このシステムで NTLM ハッシュの代わりに Bcrypt ハッシュ方式を使用する場合は、8 文字で十分です。ただし、Web 経由で入力したパスワードを保持するシステムで使用されているハッシュ方式を知る機会はありません。だからこそ、あらゆる可能性を考慮する必要があります。
ソフトウェア開発者にとっての主な問題は、少なくとも 12 文字の長さのパスワードをユーザーに納得させるのがほぼ不可能であることです。現在では、この長さのパスワードの使用頻度は低いと言っても過言ではありません。したがって、開発されたシステムの使用シナリオに応じて、パスワードのセキュリティを向上させるためにユーザーが受け入れられる妥協点を見つける必要があります。
開発者への最後の提案は、ユーザーに提供したフォームを通じて受け取った入力の最小長だけでなく最大長も確認することです。特に、セキュリティ目的で Bcrypt のような計算速度の遅いハッシュ アルゴリズムの使用を有効にする場合、ユーザーが入力するパスワードの最大長を制御しないと、いくつかのリスクに直面する可能性があります。たとえば、攻撃者は、特別に作成されたいくつかのリクエストを使用して、数十の 100 文字のパスワードを同時に試行することで攻撃を実行できます。このような状況では、システムが他のユーザーに対して応答しなくなる可能性が非常に高くなります。確認する パスワードがオンラインで販売されているかどうかを確認する方法.
エンドユーザーへのアドバイス
パスワードは 12 文字以上にして、必ず大文字、小文字、数字、特殊記号の組み合わせを含めてください。パスワードを保存しているシステムがハッキングされ、情報が悪用される可能性があることを決して忘れないでください。システムがパスワードの暗号化にどのようなアルゴリズムを使用するかはわかりません。そのため、予防策を講じて強力なパスワードを作成するかどうかは完全にユーザー次第です。今すぐ閲覧できます 解読が困難な強力なオンライン パスワードを生成する方法.









