ユーザーに強力なパスワードの使用を強制することは効果的ですか？
特に機密情報を保存するサービスを設計しています。この情報への不正アクセスを防止するために、パスワードから派生したキー（PBKDF2）で暗号化されます。パスワードは、BCryptハッシュ+ソルト形式でデータベースに保存されます。プレーンテキストで保存されることはありません。
保存される情報の性質上、強力なパスワードが必要です。一部のWebサイトでは、厳密な文字ガイドラインを適用することで、ユーザーにエントロピーの大きいパスワードを作成するよう強制しています。これらの複雑なパスワードは、さまざまなWebサイトでパスワードの再利用につながる可能性があります[1]。これはA Bad Thing™[2]です。
むしろ、ユーザーに強力で、再利用されたり、安全性の低い別のWebサービスで既に使用されている可能性が低いパスワードを選択してもらいたいと思います。そのため、ユーザーに母国語でXKCDのような[3]パスワードスキームを使用することを考えていました。
ユーザーには、6文字を超える大きなWordリストから4〜5個の異なる単語が表示されます（特殊文字が含まれる単語はなく、ASCIIのみ）。パスワード入力ダイアログは、パスフレーズのパラダイムを強化するために、通常の単一フィールドではなく4〜5フィールドでフォーマットされます。登録時にパスワードを自由に再生成できるので、ユーザーは覚えやすい単語で構成されるパスフレーズを選択できます。ユーザーは自分の言葉を入力できません。
個人的な経験から、CreeperHost [4]は、この方法をすでに使用していますが、4つの連結された英語の単語を含む単一のパスワードフィールドがあります。
私の質問は次のとおりです。
- この方法は、ユーザーが自分で選択できるようにするよりも安全/効果的でしょうか？
- 誰かが同様のスキームを実装した経験がありますか？それは効果的でしたか？
- パスワードフィールドを複数の個別のフィールドに分割することは有益ですか、それとも情報が多すぎますか？
私は、もしあれば、この特定の方法の実際のアプリケーションに関連する回答を具体的に探しています。このパスワード生成方法の理論的な長所と短所をよく知っています。
- もつれたパスワード再利用のウェブ- http://www.jbonneau.com/doc/DBCBW14-NDSS-tangled_web.pdf
- パスワードの再利用- http://xkcd.com/792/
- パスワードの強度- http://xkcd.com/936/
- クリーパーホスト- http://www.creeperhost.net/
具体的な質問：
この方法は、ユーザーが自分で選択できるようにするよりも安全/効果的ですか？
はい。パスワードの再利用を減らし、非常に一般的なパスワードをすぐに削除します。
誰かが同様のスキームを実装した経験がありますか？それは効果的でしたか？
私は過去に多くの「代替」パスワード方式を見てきました。ほとんどの場合、セキュリティを大幅に向上させることなく、サポートの問題と合併症を追加しました。
パスワードフィールドを複数の個別のフィールドに分割することは有益ですか、それとも情報が多すぎますか？
基本的に自動化された無知の攻撃を、単に違うだけですでに打ち負かしたと思います。それは標的型攻撃を残します。ただし、パブリックサインアップが利用可能な場合、攻撃者は5ワードなどが必要であることを発見できます。したがって、攻撃者にフィールドに分割してより多くの情報を提供しているとは思わない。
認証が失敗した場合でも、どのWordが間違っているかについてのアドバイスは明らかに提供しないでください。これはセキュリティを損なうことになります！
その他のアドバイス
ユーザビリティに関する他の回答には、他にもたくさんの良いアドバイスがあります。
セキュリティと使いやすさが重要な場合は、おそらくパスワードよりも良いものを検討してください。 SMS多分？
年齢を問わずパスワードを変更しても、リスクを適切に処理できない可能性があります。ユーザーのコンピューター上のトロイの木馬、ハッキングされた電子メールアカウントを介した認証のリセット、フィッシング...凝ったパスワードスキームやコントロールをいじることで対処できないものがあります*。
データが重要な場合は、パスワードよりも良いことをします。
（ユーザーのためにランダムなパスワードを生成し、ロックされた引き出しに安全に保管するように依頼するだけの方がよい場合もあります。これは、心配している脅威と攻撃、およびシステムの使用方法によって異なります。）
*リスクベースの2要素アプローチのgoogleオファーについては、2要素認証がたまにしかトリガーされないということはかなりたくさんあります。コストを抑え、セキュリティを大幅に改善します。しかし、あなたの手に多くの時間がない限り、私はこれを外部委託します:)
すべてのパスワードを許可します。結果を強調するだけです。
あなたのスキームは奇妙でユーザーにとっては異質であり、多くの人が準拠するよりサービスの使用をやめたいと思います。彼らに自分のパスワードを選ばせる代わりに、あなたが彼らのために選んだパスワードを覚えるように彼らに強いています。これはほとんどの人には受け入れられません。 「もう一度試す」ことで選択肢を与えていると思いますが、ユーザーエクスペリエンスの違いは、ATMと片腕バンディットとほぼ同じです。
最大の問題は人的要因であることを覚えておいてください。そもそも避けるべきことは、ホワイトボードに書かれたパスワードです。 これら みんなは非常に安全なパスワードを持っていました。そして、それはテレビで 放映 です。
あなたの側の誰もそれをクラックできないことを確実にしたいのであれば、あなたが必要としているのは、モンキートレーニングユーザーではなく、内部手続きです。おそらく、ソルト付きパスワードへのアクセスがユーザーログインパネルと同じ再試行制限によって保護されているシステムでしょう。また、労働者がアクセスできないようにすることは重要ではありません。店の店員はレジに無制限にアクセスできます。盗難を防ぐのは、避けられない結果への気づきです。管理セッションの記録を使用します。 「アクセスするのに最低2人」の手順を使用します。強力なユーザーパスワードではすべてを保護することはできないため、これが銀行のやり方です。
Diceware についてお読みください。はるかに小さなリストから4ワードで44ビットのエントロピーを取得できます。リストが2050程度の単語であり、置換せずに選択した場合、各単語は約11ビットのエントロピーになります。2（2048）= 11. 5,000ワードを使用すると、ワードあたり12ビットを取得できます。 （ログ2（4096）= 12）
ユーザーが覚えていると思う組み合わせが表示されるまでユーザーがクリックできる「再試行」リンクのアイデアが気に入っています。
あなたの質問についての一つは私を悩ませます。データが特定のユーザーのパスワードで暗号化されている場合、そのユーザーのみがデータを復号化できます。データがユーザーごとに保存されている場合、問題はありません。ユーザーが自分のパスワードを忘れた場合、パスワードが暗号キーであるとデータはトーストされることに注意してください。この点を考慮して、非対称鍵の配置を検討することをお勧めします。
アクセスするには、入力を4つのフィールドに分割しないでください。これにより、攻撃者が持つべきではない情報が攻撃者に与えられます。単語をスペースで区切るかどうかを決定し、ユーザーに伝えます。
このアプローチで私が目にする問題は、単純な非従来型の性質であり、人々がそれを使用する可能性を減らすことになります。
個人的には、従来のパスワード入力とは対照的に、これを我慢するためにサービスを使用する非常に説得力のある理由がなければなりません。以前、アプリケーション開発者はユーザーが強力なパスワードを使用できるようにするsome責任があると思います。しかしながら;最終的にこれはユーザーの責任です。
また、ユーザーにパスワードエントロピーを確保するための1つの特定の方法を強制することを検討してください。 XKCDの手法は問題ありませんが、それだけではなく、それが最良であるという絶対的で実証的な証拠もありません。今。
非常に大きく完全にランダムなパスワードを生成し、ユーザーに自動的に入力できるパスワードマネージャーの使用を検討してください。このアプローチでは、これらのアプリケーションを壊してしまう可能性があります。
また、次のように主張するgrc.com password haystacks 記事のようなものを検討してください。
D0g.....................
...これより強力なパスワードです：
PrXyc.N(n4k77#L!eVdAfp9
...単純に、全体のエントロピー（ランダム性）がかなり低いにもかかわらず、余分な文字が1つあるため、コンピューターがパスワードを総当たりで推測するのは95倍長くかかり、覚えやすくなります。
問題は、パスワードが長くなるとばかばかしい計算コストがかかるため、ブルートフォース攻撃は実際には特定の長さのパスワード（6〜8文字）までしか使用されないことです。しかし、非常に複雑な短いパスワードでさえ、総当たり攻撃に対して非常に脆弱です。新しい攻撃は、パターンベースのハイブリッド攻撃で、侵害されたパスワードをより大きなパスワード内のパターンとして使用します。強力なGPUはこのアプローチを実行可能にし、明らかに非常に効果的です。弱いパスワードに.を埋め込むだけでは、良い解決策にはならないようです。
この記事も参照してください パスワードの複雑さのルールは、長いものよりも煩わしく、効果的ではありません 。
したがって、少なくとも一部の最近の調査では、パスワードの強度に最も関連する要素はパスワードの長さであることが示されています。少なくとも部分的には、複雑なパスワードは短いとしても、ほとんどのユーザーにとって大きすぎるためです。 XKCDのアプローチは、非常に長いパスワードを覚えやすくすることで、パスワードの長さを確保するのに役立ちます。これらのパスワードは、よく知られた単純なパターンやフレーズではありません。それは（おそらく）それが究極の強さです-結果として得られるパスワードの長さだけです。そうは言っても、「正しい馬バッテリーの定番」が新しいハイブリッドパターンベースの攻撃にどれだけ耐えられるか疑問に思い始めています。
同じ結果を達成する他のアプローチがあるので、ユーザーをその1つに強制すると、実際にはセキュリティに見合った見返りがなければ、サービスの使用がより困難になる可能性があります。また、6か月後のXKCDアプローチに弱点が見つかった場合は、その問題に固執しており、サービスを変更するために多大な労力を費やす必要があります。
これは、パスワードの再利用を防止する優れた方法のように思えますが、ユーザーを快適ゾーンの外に押し出す可能性があるため、ユーザーがパスワードをテキストファイルに保存して、ユーザーが覚えられるようにする場合があります。ユーザーはパスワードを覚えている必要があることを強調するか、パスワードマネージャーを使用して安全に保管する必要があります（それがあなたとシステム）。また、複数のフィールドソリューションが一般的なパスワードマネージャーで機能することを確認しますが、この方法で単語を分割することによる他の問題は確認できません。
複数のフィールドがパスワードとして指定されているパスワードマネージャー機能を実装するのは難しい場合があるため、ユーザーにも独自のパスワードを使用するオプションを提供しますが、ユーザーは、使用されるものなど、安全に生成されたランダムシーケンスのみを使用する必要があることを述べる必要がありますKeepassまたはLastPassに含まれるパスワードジェネレーター。ユーザーがいつも使用しているのと同じパスワードを入力するだけで済まないようにするには、ユーザーが入力した場合にのみ、ばかげた制限を適用して、パスワードが実際に一意であることを確認します。例えば。最小20文字の数字を使用した50文字以上。小文字/大文字と少なくとも1つの記号を含める必要があります。これにより、エキスパートユーザーは幸せになりますが、他のユーザーからの弱いパスワードは防止されます（ただし、一部のユーザーは弱いパスワードに45 "2"sと1つの "! "）。このようなケースを試行して検出し、このオプションはパスワードジェネレーターでのみ使用するというメッセージを強化できますが、エッジケースに多くの労力を費やすと、収益が減少します。生成された異なる単語のオプションの方が有益であることを専門家以外のユーザーに試して説明すること。
特に機密情報を保存するサービスを設計しています。の私たちの側の誰もがこの情報を取得できないようにするために、パスワード（PBKDF2）から派生したキーで暗号化されます。パスワードは、BCryptハッシュ+ソルト形式でデータベースに保存されます。プレーンテキストで保存されることはありません。
パスワードベースの暗号化をオフライン攻撃に対して安全にするには（たとえば、傍らにいる人、または攻撃者が別の方法でアクセスした場合） 128ビット以上のエントロピーが必要です。つまり、これには、4つまたは5つではなく10個のランダムな単語が必要です 。キーを強化するためにPBKDF2を使用しているため、これにより16ビット程度のエントロピーが追加される可能性があります（反復によって異なります）。したがって、必要なのは9ワードのみです。私のポイントは、暗号化が適切であることを確認するために、計算を確実に行うことです。
これにより、平均的なユーザーがパスフレーズを覚えるのがさらに困難になります。ユーザーがパスワードマネージャーを使用している場合は、50文字のオプションを使用してログインすることもできます。他の人が指摘したように、これは潜在的に多くのサポートリクエストを生成する可能性があり、安全な認証とセッション管理システムの一部のみを開発するのは大変な努力です。
あなたの方法は面白いですが、私はそれが好きではないと思います。
ユーザーが好きなパスワードを見つけるまで、ユーザーが「ホイールを再スピン」できるようにします。 4桁の数字でこれを行った場合、一部の人々が1234または0000になるまで何度もスピンする可能性があります。これにより、攻撃者は幸福になります。
組み合わせはたくさんありますが、攻撃者は指定された構造のパスワードのみを試すように制限できます（実際、サービスを使用して、使用するWordリストを特定できます）。
パスワードポリシーを実装する前に、AppSecUSA 2014でのRick Redmanによる「パスワードの複雑さの要件は無価値」と題された次の素晴らしいプレゼンテーションをご覧ください。
https://www.youtube.com/watch?v=zUM7i8fsf0g
彼は、すべての人間がパスワードを作成するために使用するのと同様のパターンを使用してパスワードを解読することについて説明します。
ユーザーには、6文字を超える大きなWordリストから4〜5個の異なる単語が表示されます（特殊文字が含まれる単語はなく、ASCIIのみ）。パスワード入力ダイアログは、パスフレーズのパラダイムを強化するために、通常の単一フィールドではなく4〜5フィールドでフォーマットされます。登録時にパスワードを自由に再生成できるので、ユーザーは覚えやすい単語で構成されるパスフレーズを選択できます。ユーザーは自分の言葉を入力できません。
これは問題になるでしょう。
これは、パスワードフレーズで使用されている単語のリストが必要であり、そのリストからの逸脱がないことを意味します。
ハッカーが何らかの方法でリストを取得できる場合、それがブルートフォース攻撃からであれ、ソーシャルハッキングであれ、その他の方法であれ、彼らは単語のリストを持っているので、パスワードを理解するのははるかに簡単です。
代わりに、ユーザーが自分の単語を入力し、数字や特殊文字を許可できるようにすると、パスワードフレーズははるかに安全になり、{他のどこでも）と同じパスワードを使用できなくなります}パスワードフレーズに4〜5語を強制しているため。
いくつかのこと（そのうちのいくつかはすでに言及されています）
- 単語が2回以上繰り返されないようにしてください
- 単語を複数回繰り返すことを許可しない（
pass、Word、pass、Word） - データを暗号化するためのキーとしてパスワードを使用しないでください
- これは非常に悪い考えです。特に、ユーザーがパスワードを忘れてパスワードのリセットが必要な場合はなおさらです。
password schemeは使用しないでください- これは、ハッカーが単語やフレーズを排除する手がかりを残し、分野を狭めます。