回答:
SANS日記とは異なるテイクがあり
ます：パスワードルール：25年ごとに変更します
1つの実用的な利点があります。誰かがあなたのパスワードを持っている場合、あなたが望むのはあなたのメールを読んで検出されないことだけである場合、最終的にサインインシークレットを変更しない限り、彼らは永久にそうすることができます。したがって、定期的にパスワードを変更しても、誰かがあなたの商品に侵入してそれをやめることにはあまり役立ちませんが、アカウントにアクセスしている可能性のあるストーカーやスヌーパーを振り払う機会を与えてくれます。はい、これは良いです。しかし、これだけで利益が面倒な価値があると90日ごとにパスワードの変更をユーザーに強制の欠点を述べたかどうか、私は疑問を持っています。
推測したときにパスワードの変更を強制する（すべてのユーザーに対してパスワード推測プログラムを常に実行することにより）。
「なぜ？」に対する答えが「パスワードを変更する必要がある」と主張するのは困難です。「盲目に推測できたから」です。パスワードを推測するのが難しいと選択したユーザーに自動的に報酬を与え、ユーザーにパスワードが弱いことを教えます。「password1」を選択した場合、一度ログインできるようになる前に期限が切れます。ユーザーがランダムで大文字と小文字が混在する16文字の英数字のパスワードを選択した場合、それを推測することはできません。EMは、それは非常に長い時間維持し、彼らもそれを暗記することができるでしょう」してみましょう。
パスワードの変更を強制することに関する最悪のことは、実際に人々にパスワードを変更させているということではありません。通常、警告はほとんどまたはまったく表示されず、すぐに対処する必要がある問題にすぐに襲われるため、誰かに良いパスワードを考え出す時間を与える代わりに、安全性の低いパスワードである可能性が高くなりますしかし、覚えて、以上確保しやすいが、それはちょうどので、セキュリティ上の利点を否定、ダウン書き込まれます。
パスワードが簡単に推測できないほど複雑であり、システム間で共有されておらず、危険にさらされている可能性が低い場合、パスワードの変更はおそらくそれほど重要ではありません。
ただし、これらのいずれかが発生し、最初の2つがおそらくより一般的である場合、ユーザーが定期的にパスワードを変更することは、少なくともパスワードを共有する可能性が低いことを意味します。
そうは言っても、私はあなたのユーザーに良いパスワードが何を意味するのか、そしてそれらを共有することが非常に悪い理由について教育することを選ぶでしょう。あなたが何をしようとも、それらを書き留めることは一般的です。
あまり知られていない引用を覚えたり、フレーズを作成したりして、知っている本からパスワードを選択することをお勧めします。各単語の最初の文字を使用し、その中のどこかに2つの数字を追加します。ほとんどの人は、数回タイプした後にそれを覚えています。
私はその実践にはまったく利点がありません。
強力なパスワードははるかに重要です。強いとは、9 +の英数字+特殊記号、または15+ [az]のみの非辞書パスワード/フレーズのいずれかを意味します（これは、AmazonのEC2を使用したパスワードのブルートフォースのコストに関する最近の調査に基づいています）。
リモートからアクセスするシステムでは、公開されるすべてのサービスにブルートフォース検出および防止ソフトウェア（fail2banなど）が必要です。これは、通常のパスワード変更ポリシーよりもはるかに重要です（IMO）。
基本的な問題は、セキュリティメカニズムとしてのパスワードが悪臭を放つことです。
頻繁に変更するように人々に頼むと、彼らはそれを書き留めます。少なくとも3つの数字、4つの大文字、および制御文字を含む30文字のパスワードを使用するように依頼した場合、彼らはそれらを忘れたり、書き留めたり、他の愚かなことをします。単純な場合、ユーザーはbunny7やBunny7などの愚かなパスワードを使用します。そして、ポルノアカウントやhotmailアカウントなど、すべてに同じ不正なパスワードを使用します。
ユーザーが携帯電話を2要素認証ツールとして使用できるモバイルOTPなどのツールが好きです。
長期的には、ユーザー識別メカニズムとして暗号化された証明書を使用して、どういうわけか世界にたどり着くでしょう。以下のようなものはOpenIDとCASの簡素化、ユーザー認証と便利なシングルサインオンを可能にします。
長期的には、ユーザーが資格情報を発行する必要がある回数を減らすことをお勧めします。「HR」パスワードと「タイムシート」パスワードと「CRM」パスワードを取り除きます。ユーザーを資格情報を1回発行する必要がある共通の認証インフラストラクチャに統合します。次に、MobileOTPや2要素認証を使用するRSA SecurIDなどを使用するようにします。
短期的には、パスワードポリシーが宗教戦争のトピックになるでしょう。上司があなたに求めていることは何でもしてください。あなたが上司であれば、ユーザーベースと期待されるセキュリティプロファイルに基づいて判断してください。
幸運を！
完全に役に立たないわけではないこのプラクティスは、ずっと前にもっと重要でした。このポリシーを議論することは、実際にははるかに深刻な現在の脅威から注意をそらすため、逆効果です。
考慮してください：
Windows / ADを使用していて、「アカウントは機密で委任できない」のチェックボックスがアカウントにない場合、そのアカウントは偽装経由で使用でき、パスワードは不要です。これを行うコードは簡単です。
ユーザーのWindowsワークステーションがセキュリティの脆弱性により侵害された場合、メモリ内のWindowsセキュリティトークンを使用して他のコンピューターにアクセスできます。繰り返しますが、パスワードは必要ありません。
ちなみに、その2番目は、日常の通常のユーザーアカウントとは異なるアカウントを使用してのみサーバーにアクセスする必要がある理由です。また、どちらのシナリオも、最も堅牢な2要素認証メカニズムでさえ完全に無効にすることに注意してください。
パスワードのセキュリティに関して発生する可能性のある最善のことは、パスワードの議論をやめ、より現代的で深刻な脅威に集中することです。
詳しくは：
ルークジェニングスのプレゼンテーション「すべてを支配する1つのトークン」をご覧ください。
http://eusecwest.com/esw08/esw08-jennings.pdf
不眠症シェル-ASP.Netサーバー上のトークンを侵害するために必要なコードの例：
http://www.insomniasec.com/releases/tools
方法：ASP.NET 2.0でプロトコル移行と制約付き委任を使用する
http://msdn.microsoft.com/en-us/library/ms998355.aspx
「パスワードなし」を検索します。
パスワードが変更される時間が長くなるほど、パスワードが侵害される可能性が高くなります。これは、パスワードが侵害される状況が発生する可能性が高くなるためです（無制限の時間が与えられた場合）。また、ユーザーが古いユーザーに慣れているため、将来変更するのが難しくなります。さらに危険なのは、それが危険にさらされ、ユーザーがその事実に気付いていない場合、ユーザーのアカウントの深刻な進行中の誤用が起こる可能性があるということです。定期的な変更は、少なくとも次にパスワードの変更が強制されると、侵害されたパスワードが役に立たなくなることを少なくとも軽減します。
私の経験では、ユーザーがパスワードを書き留める可能性が最も高いシナリオは、セキュリティインフラストラクチャの結合思考が不足していることです。ユーザーにそれらの5つを投げると、復stickで黄色の付箋メモ症候群を取得します。
ユーザーが覚えやすいが解読しにくいパスワードを選択できる合理的なパスワードポリシーと、優れたユーザー教育、強固な統合認証、適切なロックアウトおよび有効期限ポリシーがあり、すべてパスワード共有を明示的に禁止するAUPによってバックアップされます最良の方法。
資格情報をキャッシュする場合（ほとんどの人は可用性のために行う）、これは必須です。コンピューターが物理的に盗まれ、資格情報のキャッシュが有効になっている場合、泥棒はアカウントロックアウトポリシーがアクティブ化されることを恐れることなく、マシンをネットワークからブルートフォースオフできます。その後、ネットワークリソースに対する有効な資格情報を持ちます。これらのパスワードを定期的に変更すると、この損害を最小限に抑えることができます。
これは、特権アカウントでログインすることはなく、常に制限付きユーザーとしてログインし、個々のプロンプトを上げる正確な理由です。これにより、盗難/侵入の際に特権資格情報がブルートフォースされるのを防ぎます。
私は、パスワードの変更を決して必要としないキャンプにいます。または記事が言うように-25年ごとに-ええ、私はその時死んでしまいます。良い。理由は...仕事で覚えておくべき12個のパスワードがあります。それらのほとんどは変化し、変化するものは全く異なるスケジュールにあります。それらはすべて異なる強度要件を持っています。弱い人間はどうやってこれに対処できますか？私が見たいくつかの方法：それらをホワイトボードに書く。紙にそれらを書き、ロックされていない引き出しに保管してください。または私の好みの方法：かなり安全でないGoogleドキュメントのスプレッドシートに保存します。これらの方法（非常に一般的）のいずれも、変更を要求することによって得られる小さなセキュリティ上の利点を完全に相殺しないことを私に納得させる方法はありません。
ITサポートの誰かが私のアカウントの1つをアンロックするのを待っているので、この投稿を書く時間があります。どうやら私はきちんと私のスプレッドシートの最後の時間を更新しませんでした。このナンセンスに失われたBILLION $$$を計算する研究はありますか？