SSCP 試験問題 531
ラティスベースのアクセス制御モデルはどのアクセス制御モデルの例になりますか?
正解: A
ラティス モデルには、最小の値の上限と最大の値の下限を持つ要素のペアが存在します。強制アクセス制御 (MAC) モデルでは、ユーザーとデータ所有者は、誰がファイルにアクセスできるかを決定する自由があまりありません。
クレメントからのヒント
必須アクセス制御は、サブジェクトに課されているアクセス許可があり、サブジェクトがそれらを任意に変更できない場合には必ず適用されます。ファイルのサブジェクト/所有者が権限を自由に変更できる場合、それは任意のアクセス制御となります。
以下は、主に Doug Landoll による説明に基づいた内訳です。私はダグが説明した通りではなく、私自身の言葉を使って以下に再現します。
最初: 格子
ラティスは、通常、強制アクセス制御 (MAC) の実装に使用されるアクセス制御ツールにすぎず、RBAC の実装にも使用できますが、これはそれほど一般的ではありません。ラティス モデルは、整合性レベルやファイルのアクセス許可にも使用できます。格子には最小の上限と最大の下限があります。これは、サブジェクトのセキュリティ クリアランスとオブジェクトの機密ラベルのペアなど、要素のペアを利用します。
2 番目: DAC (随意アクセス制御)
裁量アクセス制御について見てみましょう: これは、所有者 (オブジェクトの作成者と読みます) が自分の裁量で誰にアクセス権を与えるかを決定するアクセス制御方法です。誰もが知っているように、ユーザーは時々非常識です。ユーザーは自分の ID に基づいてファイルを他のユーザーと共有しますが、ユーザーがネットワーク上の他のユーザーとさらにファイルを共有することを妨げるものはありません。すぐに、情報の流れや誰が何にアクセスできるのかを制御できなくなります。低レベルのセキュリティだけが必要な、小規模でフレンドリーな環境で使用されます。
3 番目: MAC (強制アクセス制御)
以下はすべて強制アクセス制御の形式です。
必須アクセス制御 (MAC) (ラティスを使用して実装)
MAC はサブジェクトに対してセキュリティ クリアランスを利用し、ラベルもオブジェクトに割り当てられることを覚えておく必要があります。サブジェクトのクリアランスは、アクセスされているオブジェクトのクリアランスを上回る (同等以上である) 必要があります。オブジェクトに付けられたラベルは、機密レベルとオブジェクトが属するカテゴリを示します。カテゴリは、Need to Know を実装するために使用されます。
以下はすべて非任意アクセス制御の形式です。
役割ベースのアクセス制御 (RBAC)
ルールベースのアクセス制御 (この場合はファイアウォールを考えてください)
ISC2 の公式本には、RBAC (非任意アクセス制御と同義) は DAC の形式であると記載されていますが、それはまったくの間違いです。RBAC は非裁量アクセス制御の一種です。
非自由裁量は、ラベルや認可が関係しないため、強制的なアクセス制御と同等ではありません。
これにより、アクセス制御の世界の何が何であるかに関連するドラマ全体が明確になることを願っています。
同じ内容で、明示的アクセス許可 (ユーザーが独自のプロファイルを持っている) と暗黙的アクセス許可 (ユーザーがロールのメンバーになるなどしてアクセス許可を継承する) の違いを理解している必要があります。
次の答えは正しくありません。
任意のアクセス制御。これは不正解です。随意アクセス制御 (DAC) モデルでは、ユーザーに付与された承認に基づいてアクセスが制限されます。これは ID ベースのアクセス制御のみです。格子は使用しておりません。
非任意アクセス制御。これは不正解です。非裁量アクセス制御 (NDAC) では、ロールベースのアクセス制御方法を使用してアクセス権とアクセス許可を決定します。これは、役割ベースのアクセス制御である RBAC の同義語としてよく使用されます。ユーザーは、ロールに割り当てられるときに、ロールから権限を継承します。このタイプのアクセスはラティスを利用できますが、場合によってはラティスを使用せずに実装することもできます。
必須アクセス制御はこれよりも良い選択でしたが、RBAC はラティスを利用することもできました。ベストアンサーはMACでした。
ルールベースのアクセス制御。これは非随意アクセス制御 (NDAC) アクセス制御モードの例であるため、不正解です。すべてのユーザーにグローバルに適用されるルールがあります。ルールベースのアクセス制御ではラティスが使用されることはありません。
クレメントからのヒント
必須アクセス制御は、サブジェクトに課されているアクセス許可があり、サブジェクトがそれらを任意に変更できない場合には必ず適用されます。ファイルのサブジェクト/所有者が権限を自由に変更できる場合、それは任意のアクセス制御となります。
以下は、主に Doug Landoll による説明に基づいた内訳です。私はダグが説明した通りではなく、私自身の言葉を使って以下に再現します。
最初: 格子
ラティスは、通常、強制アクセス制御 (MAC) の実装に使用されるアクセス制御ツールにすぎず、RBAC の実装にも使用できますが、これはそれほど一般的ではありません。ラティス モデルは、整合性レベルやファイルのアクセス許可にも使用できます。格子には最小の上限と最大の下限があります。これは、サブジェクトのセキュリティ クリアランスとオブジェクトの機密ラベルのペアなど、要素のペアを利用します。
2 番目: DAC (随意アクセス制御)
裁量アクセス制御について見てみましょう: これは、所有者 (オブジェクトの作成者と読みます) が自分の裁量で誰にアクセス権を与えるかを決定するアクセス制御方法です。誰もが知っているように、ユーザーは時々非常識です。ユーザーは自分の ID に基づいてファイルを他のユーザーと共有しますが、ユーザーがネットワーク上の他のユーザーとさらにファイルを共有することを妨げるものはありません。すぐに、情報の流れや誰が何にアクセスできるのかを制御できなくなります。低レベルのセキュリティだけが必要な、小規模でフレンドリーな環境で使用されます。
3 番目: MAC (強制アクセス制御)
以下はすべて強制アクセス制御の形式です。
必須アクセス制御 (MAC) (ラティスを使用して実装)
MAC はサブジェクトに対してセキュリティ クリアランスを利用し、ラベルもオブジェクトに割り当てられることを覚えておく必要があります。サブジェクトのクリアランスは、アクセスされているオブジェクトのクリアランスを上回る (同等以上である) 必要があります。オブジェクトに付けられたラベルは、機密レベルとオブジェクトが属するカテゴリを示します。カテゴリは、Need to Know を実装するために使用されます。
以下はすべて非任意アクセス制御の形式です。
役割ベースのアクセス制御 (RBAC)
ルールベースのアクセス制御 (この場合はファイアウォールを考えてください)
ISC2 の公式本には、RBAC (非任意アクセス制御と同義) は DAC の形式であると記載されていますが、それはまったくの間違いです。RBAC は非裁量アクセス制御の一種です。
非自由裁量は、ラベルや認可が関係しないため、強制的なアクセス制御と同等ではありません。
これにより、アクセス制御の世界の何が何であるかに関連するドラマ全体が明確になることを願っています。
同じ内容で、明示的アクセス許可 (ユーザーが独自のプロファイルを持っている) と暗黙的アクセス許可 (ユーザーがロールのメンバーになるなどしてアクセス許可を継承する) の違いを理解している必要があります。
次の答えは正しくありません。
任意のアクセス制御。これは不正解です。随意アクセス制御 (DAC) モデルでは、ユーザーに付与された承認に基づいてアクセスが制限されます。これは ID ベースのアクセス制御のみです。格子は使用しておりません。
非任意アクセス制御。これは不正解です。非裁量アクセス制御 (NDAC) では、ロールベースのアクセス制御方法を使用してアクセス権とアクセス許可を決定します。これは、役割ベースのアクセス制御である RBAC の同義語としてよく使用されます。ユーザーは、ロールに割り当てられるときに、ロールから権限を継承します。このタイプのアクセスはラティスを利用できますが、場合によってはラティスを使用せずに実装することもできます。
必須アクセス制御はこれよりも良い選択でしたが、RBAC はラティスを利用することもできました。ベストアンサーはMACでした。
ルールベースのアクセス制御。これは非随意アクセス制御 (NDAC) アクセス制御モードの例であるため、不正解です。すべてのユーザーにグローバルに適用されるルールがあります。ルールベースのアクセス制御ではラティスが使用されることはありません。
SSCP 試験問題 532
必要なときに、必要な場所でデータにアクセスできるようにするには、次のどれですか?
正解: D
可用性とは、いつ、どこにいてもデータにアクセスできるようにすることです。
必要です。
出典: KRUTZ、Ronald L. & VINES、Russel D.、『CISSP Prep Guide: Mastering the CISSP』
「コンピュータ セキュリティの 10 ドメイン」、2001 年、John Wiley & Sons、59 ページ。
必要です。
出典: KRUTZ、Ronald L. & VINES、Russel D.、『CISSP Prep Guide: Mastering the CISSP』
「コンピュータ セキュリティの 10 ドメイン」、2001 年、John Wiley & Sons、59 ページ。
SSCP 試験問題 533
データを保護する方法としてのデータ暗号化について正しいのは次のどれですか?
正解: D
暗号化では、「悪者」が暗号化アルゴリズムを持っていると常に想定されます (実際、DES、Triple DES、AES などの多くのアルゴリズムはパブリック ドメインです)。悪者に欠けているのは、そのアルゴリズムを完成させ、情報を暗号化/復号化するために使用される鍵です。したがって、キーの保護、配布の制御、計画的なキーの変更、適時の破棄、およびその他のいくつかの要素については、慎重な考慮が必要です。これらの要素はすべて、「キー管理」という包括的な用語でカバーされます。
もう 1 つの重要な考慮事項は、質問にあるように「データを保護する方法としてのデータ暗号化」の場合です。そのデータが長期間保存される場合 (バックアップなど)、暗号化された情報を復号化するために古い鍵が必要になる限り、鍵管理スキームで古い鍵を保存する必要があります。
他の答えは次の理由から正しくありません。
「パスワード ファイルに使用することもあります。」- 暗号化は、パスワード ファイル内に保存されているパスワードを暗号化するためによく使用されますが、通常、パスワード ファイル自体には効果的ではありません。ほとんどのシステムでは、ユーザーがパスワード ファイルの内容にアクセスできない場合、認証できません。
ファイル全体を暗号化すると、そのアクセスが防止されます。
「通常は簡単に投与できます。」- 過去数年間の開発により、暗号化の管理が大幅に容易になりました。しかし、それは依然として重要な課題です。
これは良い答えではありません。
「システムリソースに対する要求はほとんどありません。」- 暗号化は本質的に、大規模で複雑な数学的アルゴリズムです。情報を暗号化および復号化するために、システムはこのアルゴリズムを数百回、数千回、さらには数百万回、数十億回、数兆回も実行する必要があります。これはシステムリソースを大量に消費するため、非常に悪い答えになります。
もう 1 つの重要な考慮事項は、質問にあるように「データを保護する方法としてのデータ暗号化」の場合です。そのデータが長期間保存される場合 (バックアップなど)、暗号化された情報を復号化するために古い鍵が必要になる限り、鍵管理スキームで古い鍵を保存する必要があります。
他の答えは次の理由から正しくありません。
「パスワード ファイルに使用することもあります。」- 暗号化は、パスワード ファイル内に保存されているパスワードを暗号化するためによく使用されますが、通常、パスワード ファイル自体には効果的ではありません。ほとんどのシステムでは、ユーザーがパスワード ファイルの内容にアクセスできない場合、認証できません。
ファイル全体を暗号化すると、そのアクセスが防止されます。
「通常は簡単に投与できます。」- 過去数年間の開発により、暗号化の管理が大幅に容易になりました。しかし、それは依然として重要な課題です。
これは良い答えではありません。
「システムリソースに対する要求はほとんどありません。」- 暗号化は本質的に、大規模で複雑な数学的アルゴリズムです。情報を暗号化および復号化するために、システムはこのアルゴリズムを数百回、数千回、さらには数百万回、数十億回、数兆回も実行する必要があります。これはシステムリソースを大量に消費するため、非常に悪い答えになります。
SSCP 試験問題 534
現在、仮想プライベート ネットワークの作成に使用される可能性が低いのは次のうちどれですか?
正解: D
L2F (レイヤー 2 転送) は認証や暗号化を提供しません。これは、インターネット上での安全な仮想プライベート ダイヤルアップ ネットワークの作成をサポートするプロトコルです。
ある時点で、L2F は PPTP と統合され、ダイヤルアップ リンクだけでなくネットワーク上でも使用される L2TP が作成されました。
IPSec は現在、IP 環境に最適な VPN ソリューションとみなされています。
ある時点で、L2F は PPTP と統合され、ダイヤルアップ リンクだけでなくネットワーク上でも使用される L2TP が作成されました。
IPSec は現在、IP 環境に最適な VPN ソリューションとみなされています。
SSCP 試験問題 535
パスワード ファイル内でユーザー パスワードの一方向ハッシュを使用する主な目的は次のどれですか?
正解: B
セクション: 暗号化
説明/参照:
一方向ハッシュの背後にある全体的な考え方は、それはまさに一方向であるべきだということです。言い換えれば、攻撃者は、数学的に可能な方法 (または合理的な期間内) で、パスワードのハッシュ化されたバージョンからパスワードを割り出すことができてはなりません。
パスワードのハッシュ化と暗号化
ほとんどの場合、攻撃者がネットワーク ワイヤからパスワードを盗聴した場合、実際にパスワードの値を知る前に、まだやるべきことがいくつかあります。これは、ほとんどのシステムでは、パスワードが暗号化されていないことを保証するために、ハッシュ アルゴリズム (通常は MD4 または MD5) でパスワードをハッシュするためです。平文で送信されます。
世界は Microsoft によって運営されていると考える人もいますが、Unix や Linux など、他の種類のオペレーティング システムも存在します。これらのシステムはレジストリや SAM データベースを使用しませんが、巧妙に「シャドウ」と呼ばれるファイルにユーザー パスワードを格納します。さて、このシャドウ ファイルには平文のパスワードは含まれていません。代わりに、パスワードはハッシュ アルゴリズムを通じて実行され、その結果の値がこのファイルに保存されます。
Unixtype システムは、このプロセスでソルトを使用することで物事を盛り上げます。ソルトは、より複雑さとランダム性を加えるために暗号化プロセスに追加されるランダムな値です。暗号化プロセスにランダム性が加わるほど、悪者がパスワードを解読して明らかにすることが難しくなります。ソルトを使用すると、同じパスワードを数千の異なる形式に暗号化できることになります。これにより、攻撃者がシステムに適した形式を発見することがはるかに困難になります。
パスワードクラッキングツール
パスワードに一方向ハッシュを使用しても、パスワード クラッカーによるパスワードの推測は防止されないことに注意してください。パスワード クラッカーは、システムがハッシュを生成するために使用するのと同じ一方向ハッシュ アルゴリズムを通じて平文文字列を実行し、生成されたハッシュとシステムに保存されているハッシュを比較します。それらが一致する場合、パスワード クラッカーはパスワードを推測したことになります。
これは、パスワードを介してシステムに対して認証するために使用されるプロセスとほぼ同じです。ユーザー名とパスワードを入力すると、システムは入力したパスワードをハッシュし、生成されたハッシュとシステムに保存されているハッシュを比較します。一致する場合、認証されます。
現在、事前に計算されたパスワード テーブルが存在しており、レインボー テーブルを使用することで、非常に短時間で Lan Manager (LM) のパスワードを解読できます。レインボー テーブルは、通常はパスワード ハッシュをクラッキングするために、暗号化ハッシュ関数を逆にするための事前計算されたテーブルです。テーブルは通常、限られた文字セットで構成される一定の長さまでの平文パスワードを回復するために使用されます。これは、時間とメモリのトレードオフとも呼ばれる、空間と時間のトレードオフの実際的な例であり、試行ごとにハッシュを計算する場合、より少ないストレージを犠牲にしてより多くのコンピュータ処理時間を使用するか、または比較した場合、より少ない処理時間とより多くのストレージを使用します。ハッシュごとに 1 つのエントリを持つ単純なルックアップ テーブルに変換します。ソルトを使用する鍵導出関数を使用すると、この攻撃は実行不可能になります。
次のリンクで「Rainbow Tables」を確認してください。
http://en.wikipedia.org/wiki/Rainbow_table
http://www.antsight.com/zsl/rainbowcrack/
今日のパスワード クラッカー:
oclHashcat をご紹介します。これらは、ブルート フォース攻撃 (マスク攻撃として実装)、コンビネータ攻撃、辞書攻撃、ハイブリッド攻撃、マスク攻撃、ルールベース攻撃を使用する GPGPU ベースのマルチハッシュ クラッカーです。
この GPU クラッカーは、当時非常によく知られていたスイートですが、現在は非推奨になっている oclHashcat-plus と oclHashcat-lite の融合バージョンです。また、現在は非常に古い oclHashcat GPU クラッカーも存在し、plus と lite に置き換えられましたが、前述のように、これらは再び oclHashcat 1.00 にマージされました。
このクラッカーは、NTLM バージョン 2 の最大 8 文字のハッシュを数時間以内に解読できます。それは間違いなくゲームチェンジャーです。非常に大規模な GPU クラスター上で、1 秒あたり数千億回の試行を試行できます。一度に最大 128 枚のビデオ カードをサポートします。
パスワードを使用することができなくなりました。自分自身をよりよく保護するにはどうすればよいですか?
Bcrypt、PBKDF2、Scrypt などのより安全な代替手段を検討することもできます。
bcrypt は、Blowfish 暗号に基づいて Niels Provos と David Mazieres によって設計されたパスワードの鍵導出関数であり、1999 年に USENIX で発表されました。bcrypt は、レインボー テーブル攻撃から保護するソルトを組み込むことに加えて、適応関数です。時間の経過とともに、反復回数を増やして速度を下げることができるため、計算能力が増加してもブルートフォース検索攻撃に対する耐性が維持されます。
暗号化における scrypt は、元々は Tarsnap オンライン バックアップ サービス用に Colin Percival によって作成されたパスワード ベースのキー導出関数です。このアルゴリズムは、大量のメモリを必要とする大規模なカスタム ハードウェア攻撃の実行にコストがかかるように特別に設計されています。2012 年に、暗号アルゴリズムは情報提供 RFC となることを目的としたインターネット ドラフトとして IETF によって公開されましたが、この RFC はすでに期限切れになっています。
scrypt の簡易バージョンは、Litecoin や Dogecoin などの多くの暗号通貨で Proof-of-Work スキームとして使用されています。
PBKDF2 (Password-Based Key Derivation Function 2) は、RSA Laboratories の公開キー暗号化標準 (PKCS) シリーズ、具体的には PKCS #5 v2.0 の一部であるキー導出関数であり、Internet Engineering Task Force の RFC 2898 としても公開されています。これは、最大 160 ビット長の派生キーしか生成できなかった以前の標準である PBKDF1 に代わるものです。
PBKDF2 は、暗号化ハッシュ、暗号、または HMAC などの疑似ランダム関数をソルト値とともに入力パスワードまたはパスフレーズに適用し、このプロセスを何度も繰り返して派生キーを生成します。派生キーは、後続の暗号キーとして使用できます。オペレーション。計算作業が追加されると、パスワードのクラッキングがはるかに困難になり、キー ストレッチングとして知られています。この規格が 2000 年に作成されたとき、推奨される最小反復回数は 1000 回でしたが、このパラメータは、CPU 速度の向上に応じて時間の経過とともに増加することが意図されています。パスワードにソルトを追加すると、事前に計算されたハッシュ (レインボー テーブル) を攻撃に使用する能力が低下し、複数のパスワードを一度にテストするのではなく、個別にテストする必要があることになります。標準では、少なくとも 64 ビットのソルトの長さを推奨しています。
他の答えは間違っています:
「権限のないユーザーが 1 回のログオン試行で複数のパスワードを試行することを防ぎます。」パスワードがハッシュ化されていても、この種のブルート フォースによるパスワード推測の試みは防止できないため、これは誤りです。
「ユーザー パスワードに必要なストレージの量が最小限に抑えられます」は、入力の長さに関係なく、ハッシュ アルゴリズムが常に同じビット数を生成するため、誤りです。したがって、短いパスワードでもハッシュは長くなり、ストレージ要件は最小限に抑えられません。
「パスワードの暗号化に使用される処理時間を最小限に抑える」は誤りです。パスワードを暗号化する処理時間は、同じパスワードの一方向のパスワードを生成するのに必要な時間と基本的に同じであるためです。
この質問に使用された参考文献:
http://en.wikipedia.org/wiki/PBKDF2
http://en.wikipedia.org/wiki/Scrypt
http://en.wikipedia.org/wiki/Bcrypt
ハリス、ション (2012-10-18)。CISSP オールインワン試験ガイド、第 6 版 (p. 195) 。マグロウヒル。キンドル版。
説明/参照:
一方向ハッシュの背後にある全体的な考え方は、それはまさに一方向であるべきだということです。言い換えれば、攻撃者は、数学的に可能な方法 (または合理的な期間内) で、パスワードのハッシュ化されたバージョンからパスワードを割り出すことができてはなりません。
パスワードのハッシュ化と暗号化
ほとんどの場合、攻撃者がネットワーク ワイヤからパスワードを盗聴した場合、実際にパスワードの値を知る前に、まだやるべきことがいくつかあります。これは、ほとんどのシステムでは、パスワードが暗号化されていないことを保証するために、ハッシュ アルゴリズム (通常は MD4 または MD5) でパスワードをハッシュするためです。平文で送信されます。
世界は Microsoft によって運営されていると考える人もいますが、Unix や Linux など、他の種類のオペレーティング システムも存在します。これらのシステムはレジストリや SAM データベースを使用しませんが、巧妙に「シャドウ」と呼ばれるファイルにユーザー パスワードを格納します。さて、このシャドウ ファイルには平文のパスワードは含まれていません。代わりに、パスワードはハッシュ アルゴリズムを通じて実行され、その結果の値がこのファイルに保存されます。
Unixtype システムは、このプロセスでソルトを使用することで物事を盛り上げます。ソルトは、より複雑さとランダム性を加えるために暗号化プロセスに追加されるランダムな値です。暗号化プロセスにランダム性が加わるほど、悪者がパスワードを解読して明らかにすることが難しくなります。ソルトを使用すると、同じパスワードを数千の異なる形式に暗号化できることになります。これにより、攻撃者がシステムに適した形式を発見することがはるかに困難になります。
パスワードクラッキングツール
パスワードに一方向ハッシュを使用しても、パスワード クラッカーによるパスワードの推測は防止されないことに注意してください。パスワード クラッカーは、システムがハッシュを生成するために使用するのと同じ一方向ハッシュ アルゴリズムを通じて平文文字列を実行し、生成されたハッシュとシステムに保存されているハッシュを比較します。それらが一致する場合、パスワード クラッカーはパスワードを推測したことになります。
これは、パスワードを介してシステムに対して認証するために使用されるプロセスとほぼ同じです。ユーザー名とパスワードを入力すると、システムは入力したパスワードをハッシュし、生成されたハッシュとシステムに保存されているハッシュを比較します。一致する場合、認証されます。
現在、事前に計算されたパスワード テーブルが存在しており、レインボー テーブルを使用することで、非常に短時間で Lan Manager (LM) のパスワードを解読できます。レインボー テーブルは、通常はパスワード ハッシュをクラッキングするために、暗号化ハッシュ関数を逆にするための事前計算されたテーブルです。テーブルは通常、限られた文字セットで構成される一定の長さまでの平文パスワードを回復するために使用されます。これは、時間とメモリのトレードオフとも呼ばれる、空間と時間のトレードオフの実際的な例であり、試行ごとにハッシュを計算する場合、より少ないストレージを犠牲にしてより多くのコンピュータ処理時間を使用するか、または比較した場合、より少ない処理時間とより多くのストレージを使用します。ハッシュごとに 1 つのエントリを持つ単純なルックアップ テーブルに変換します。ソルトを使用する鍵導出関数を使用すると、この攻撃は実行不可能になります。
次のリンクで「Rainbow Tables」を確認してください。
http://en.wikipedia.org/wiki/Rainbow_table
http://www.antsight.com/zsl/rainbowcrack/
今日のパスワード クラッカー:
oclHashcat をご紹介します。これらは、ブルート フォース攻撃 (マスク攻撃として実装)、コンビネータ攻撃、辞書攻撃、ハイブリッド攻撃、マスク攻撃、ルールベース攻撃を使用する GPGPU ベースのマルチハッシュ クラッカーです。
この GPU クラッカーは、当時非常によく知られていたスイートですが、現在は非推奨になっている oclHashcat-plus と oclHashcat-lite の融合バージョンです。また、現在は非常に古い oclHashcat GPU クラッカーも存在し、plus と lite に置き換えられましたが、前述のように、これらは再び oclHashcat 1.00 にマージされました。
このクラッカーは、NTLM バージョン 2 の最大 8 文字のハッシュを数時間以内に解読できます。それは間違いなくゲームチェンジャーです。非常に大規模な GPU クラスター上で、1 秒あたり数千億回の試行を試行できます。一度に最大 128 枚のビデオ カードをサポートします。
パスワードを使用することができなくなりました。自分自身をよりよく保護するにはどうすればよいですか?
Bcrypt、PBKDF2、Scrypt などのより安全な代替手段を検討することもできます。
bcrypt は、Blowfish 暗号に基づいて Niels Provos と David Mazieres によって設計されたパスワードの鍵導出関数であり、1999 年に USENIX で発表されました。bcrypt は、レインボー テーブル攻撃から保護するソルトを組み込むことに加えて、適応関数です。時間の経過とともに、反復回数を増やして速度を下げることができるため、計算能力が増加してもブルートフォース検索攻撃に対する耐性が維持されます。
暗号化における scrypt は、元々は Tarsnap オンライン バックアップ サービス用に Colin Percival によって作成されたパスワード ベースのキー導出関数です。このアルゴリズムは、大量のメモリを必要とする大規模なカスタム ハードウェア攻撃の実行にコストがかかるように特別に設計されています。2012 年に、暗号アルゴリズムは情報提供 RFC となることを目的としたインターネット ドラフトとして IETF によって公開されましたが、この RFC はすでに期限切れになっています。
scrypt の簡易バージョンは、Litecoin や Dogecoin などの多くの暗号通貨で Proof-of-Work スキームとして使用されています。
PBKDF2 (Password-Based Key Derivation Function 2) は、RSA Laboratories の公開キー暗号化標準 (PKCS) シリーズ、具体的には PKCS #5 v2.0 の一部であるキー導出関数であり、Internet Engineering Task Force の RFC 2898 としても公開されています。これは、最大 160 ビット長の派生キーしか生成できなかった以前の標準である PBKDF1 に代わるものです。
PBKDF2 は、暗号化ハッシュ、暗号、または HMAC などの疑似ランダム関数をソルト値とともに入力パスワードまたはパスフレーズに適用し、このプロセスを何度も繰り返して派生キーを生成します。派生キーは、後続の暗号キーとして使用できます。オペレーション。計算作業が追加されると、パスワードのクラッキングがはるかに困難になり、キー ストレッチングとして知られています。この規格が 2000 年に作成されたとき、推奨される最小反復回数は 1000 回でしたが、このパラメータは、CPU 速度の向上に応じて時間の経過とともに増加することが意図されています。パスワードにソルトを追加すると、事前に計算されたハッシュ (レインボー テーブル) を攻撃に使用する能力が低下し、複数のパスワードを一度にテストするのではなく、個別にテストする必要があることになります。標準では、少なくとも 64 ビットのソルトの長さを推奨しています。
他の答えは間違っています:
「権限のないユーザーが 1 回のログオン試行で複数のパスワードを試行することを防ぎます。」パスワードがハッシュ化されていても、この種のブルート フォースによるパスワード推測の試みは防止できないため、これは誤りです。
「ユーザー パスワードに必要なストレージの量が最小限に抑えられます」は、入力の長さに関係なく、ハッシュ アルゴリズムが常に同じビット数を生成するため、誤りです。したがって、短いパスワードでもハッシュは長くなり、ストレージ要件は最小限に抑えられません。
「パスワードの暗号化に使用される処理時間を最小限に抑える」は誤りです。パスワードを暗号化する処理時間は、同じパスワードの一方向のパスワードを生成するのに必要な時間と基本的に同じであるためです。
この質問に使用された参考文献:
http://en.wikipedia.org/wiki/PBKDF2
http://en.wikipedia.org/wiki/Scrypt
http://en.wikipedia.org/wiki/Bcrypt
ハリス、ション (2012-10-18)。CISSP オールインワン試験ガイド、第 6 版 (p. 195) 。マグロウヒル。キンドル版。
- 最新アップロード
- 171NCLEX.NCLEX-RN.v2026-06-27.q583
- 115Juniper.JN0-232.v2026-06-27.q23
- 124BICSI.INSTC_V8.v2026-06-27.q59
- 163Cisco.300-710.v2026-06-26.q474
- 150ISACA.CISM.v2026-06-26.q913
- 131Salesforce.Integration-Architect.v2026-06-26.q116
- 171Cisco.350-401.v2026-06-26.q363
- 139Salesforce.MC-101.v2026-06-26.q44
- 140CheckPoint.156-315.81.v2026-06-26.q678
- 197Peoplecert.MSP-Practitioner.v2026-06-24.q75
