web-dev-qa-db-ja.com

ハードウェアセキュリティモジュールを使用すると、パスワードストレージのセキュリティが向上しますか？

基本的な仮定

従来のユーザー名とパスワードを使用してユーザーを認証することを目的とした会社で働いていると仮定します。同社は現在、Argon2、scrypt、PBKDF2などの低速の鍵導出関数を使用してパスワードをハッシュしています。

さらに、ネットワークHSMは、格納されたキーを使用して文字列のHMACを計算できますが、それ自体ではKDFを計算できないと想定されています。

アイデア

現在、開発者の1人は、ハードウェアセキュリティモジュールを使用して資格情報をさらに保護することを考えていました。彼は、鍵導出関数の入力としてパスワードのHMACを使用するという考えを持っていました。 HMAC関数の実際のキーはHSM内に格納されており、抽出できません。したがって、ここでの疑似コードは、古いログインコードと新しいログインコードの1つです。

// Old Login Code
function Authenticate(input)
{
    user = DB.getUser(input.username);
    if (user == null) return false; //User does not exist

    kdf = Argon2id;
    return kdf.verify(user.password, input.password);
}

そしてここに新しいログインコードがあります：

// New Login Code
function Authenticate(input)
{
    user = DB.getUser(input.username);
    if (user == null) return false; //User does not exist

    kdf = Argon2id;

    keyedHash = HSM.getHMAC(input.password, useInternalKey=true);
    return kdf.verify(user.password, keyedHash);
}

私の推論

データベースを盗むことができる攻撃者もキーをクラックするためにHSMにアクセスする必要があるため、これによりセキュリティが全体的に向上するようです。攻撃者が自分のパスワードを知っている場合でも、HSM内に格納されているキーは十分に長いため、キーをブルートフォースにしようとすることは不可能です。

データベースを制御できる攻撃者は、パスワード候補をHSMに送信して、キー付きハッシュを取得できる可能性がありますが、次のようになります。

  • 攻撃者が1秒間に試行できる候補の数を厳しく制限する
  • ネットワーク管理者が異常なネットワークトラフィックを確認し、違反を検出する可能性があります

考えられる欠点

私は「Never Roll Your Own！」を知っていますが、これは「自分自身のアルゴリズム」ではないと思います。

さらに、HSMが鍵を紛失した場合、ユーザーはもうログインできなくなることを理解しています。この問題は、バックアップHSMを使用し、そこにキーを保存することでも解決できます。

私の質問

このスキームは意味がありますか？それは実際に攻撃者がパスワードを回復することを防ぐことができますか？それとも、ITチームが多額の費用をかけて新しいものを手に入れることの言い訳にすぎないのでしょうか。

password-crackinghsm
2
MechMK1

これは、遅いソルトパスワードハッシュと「ペッパー」（または「シークレットソルト」）を組み合わせる標準の非常に安全な方法であり、認証データベースが完全に公開された場合でも、攻撃者はクラックできませんanyさらなる妥協のないパスワード。これはソフトウェアで実行できます。サーバープロセス、ユーザーモードプロセスのキーを公開しないOS保護領域、またはネットワーク経由の別のマシンに格納されている可能性がある秘密を使用してHMACを計算します。 RPCの形式（セキュリティレベルの向上）。最後のアプローチは事実上ソフトウェア「HSM」であり、本当のHSMのより安価な代替手段として使用されることもあります。

HMACとパスワードハッシュの順序を逆にすることは可能です-低速ソルトハッシュでパスワードを実行し、それをHMACしてDBの値と結果を照合します-しかし、これはkdf.verify関数のようなものでは機能しません。おそらくもっと興味深いことに、このようなスキームでは、HSM（またはHMACの計算に使用するもの）が十分に安全であることを十分に確信している場合は、遅いパスワードハッシュを完全に排除することもできます。 HSMまたはDBのいずれかを危険にさらしても、ユーザーの資格情報をクラックするのに十分な情報は提供されません（サーバー自体は単一障害点ですが、もちろん、両方にアクセスでき、ユーザーから送信されたパスワードも表示されるためです） ）。ただし、攻撃者が両方にアクセスできる場合、ブルートフォーシングは、攻撃者がHSMにHMACを要求するのと同じ速さで進行する可能性があるため、（IMO）低速のハッシュ関数を使用することをお勧めします。

1
CBHacking

まず、存在しないユーザーの「パスワード」も確認します。 （それ以外の場合は、アカウントが存在するかどうかにかかわらずリークします[ブラインドタイミングベースの攻撃]）。

HSMにパスワードを保存すると、データ漏えい（つまり、誰かがデータベースを盗んだ）による資格情報の公開が制限されます。

ただし、マシンへのアクセス権を持つユーザーを妨害することはありません（HSM自体に直接アクセスできるためです）。

より良い解決策は、認証を別のマシン/パーツに分離し、安全な（バックボーン）ネットワークを介してHSMまたは Vault のようなものに連絡させることです。シークレットはマシン自体に保存されないため、この方法でこの脅威に対して脆弱になることはありません。 HSMまたはボールトが同じ検証リクエストを連続して受信するときに制限（またはフラグ）することができます（侵害されたときに頻繁に発生するもの）。

つまり、HSMで認証プロセスをサイロ化するのではなく、認証プロセスを階層化することを目指します。

0
LvB