パスワード強度ポリシーを使用できますか。つまり、少なくとも8文字を含める必要があります。大文字を1つ含める必要があります。小文字を1つ含める必要があります。数字を1つ含める必要があります。
OPAQUEなどのPAKEプロトコルが使用されている場合、強制されますか?これらのプロトコル(OPAQUEなど)を使用して、パスワードが上記に準拠していることを証明する方法はありますか? PAKEと同様に、パスワードがサーバーに到達することはなく、クライアント側のチェックは簡単にバイパスできます。これは、ユーザーが3文字または4文字(もちろんそれ以下)のパスワードを使用できるという意味ですか?
出力を暗号化して比較することにより、よく使用されるパスワードや特定のパスワード(履歴ユーザーパスワードなど)をチェックできることを知っています。しかし、もちろん、8文字までのすべてのパスワードの組み合わせの出力を確認することは現実的ではありません。
このポリシーに準拠している過去のパスワードと一般的なパスワードのみを確認したい。
サーバー側でクライアント側の入力がOPAQUEのようなプロトコルに準拠していることを証明する方法はありますか?パスワードがサーバーによって実際に見られることは決してないことを考えると。
これは、OPAQUEなどのPAKEを使用すると、パスワードのセキュリティが低下する可能性があることを意味しますか?
編集:私は最小限の文字要件(例:1つの数字など)を強制することに異議があることを認識しています。上記のポリシーは単なる例です。
いいえ、技術的な手段でクライアント側のポリシーを適用することはできません。ご指摘のとおり、実装に焼き付けた制限は、変更されたクライアントを使用する誰かによってバイパスされる可能性があります。しかし、これは、特別に脆弱化されたクライアントを使用することに意欲的なユーザーが少なくともいると想定しています。ユーザーが公式クライアントを回避する理由は何ですか?
誰かがシステムを最終的に実行するのを阻止することはできませんが、ポリシースティックを使用して、承認されたクライアントのみを使用するように要求することができます。システムを監査して、公式クライアントがインストールされていることを確認できます。コード署名、アプリケーションのホワイトリスト、ウイルススキャン、ファイル整合性監視などの技術的な手段を使用して、不正なクライアントをインストールしないようにすることができます。キーの生成や交換などを行うために外部のWebサイトを使用している場合は、そのWebサイトをファイアウォールのブラックリストに追加します。間違ったことを難しくします。
おそらく、ファイアウォールの背後で実行されている要塞ホストからのみ、これらの特定のパスワードを管理するように要求することができます。要塞ホストはロックされ、これらの特定のセキュリティ操作にのみ使用され、交換されたパスワードはすべてクライアントにコピーされます。これが最も安全な選択肢であると言っているのではなく、ユーザーの行動を制御する別の方法である可能性があるというだけです。同様に、PAKEシステムの前にラッパーサービスを提供し、そのラッパーを使用してパスワードの適合性をテストできます。もちろん、これらのアプローチでは、セキュリティで保護、管理、および検査する必要がある要塞ホストまたはラッパーサービスが残されます。
時々あなたができることはあなたの方針を述べ(そして非遵守に対する恐ろしい罰則)そして人々がそれに従うことを期待することだけです。ユーザーがそれを迂回していると主張される(または証明される)まで、ポリシーのみのアプローチを検討してください。