Webサイトには本当に長くて複雑なパスワードが必要ですか？
重要な情報を扱うほとんどのWebサイト（Gmailなど）には、何らかのブルートフォース保護機能があります。 X回以上試行すると、アカウントがロックされるか、少なくとも解決するためのキャプチャが表示されることがあります。
現在、すべてのセキュリティ専門家が同じことを言い続けています：長くて複雑な文字、高エントロピーのパスワードを作るこれは、RSAキー、またはオフラインで解読される可能性のあるものについて考える場合、非常に理にかなっていますが、オンラインアカウントのパスワードについて話すときに本当に重要ですか？
たとえば、英語のアルファベットから6文字だけを使用してGmailのパスワードを作成します。これは約26 ^ 6 = 3億900万の組み合わせです。 1秒あたり1つのパスワードをテストできると考えた場合（Gmailのキャプチャを考慮に入れると、実際よりも速いと思います）、解読に最大10年、平均で5年必要です。
考慮すべき点：
- 別のWebサイトで同じパスワードを使用すると、別のWebサイトがハッキングされ、パスワードが漏洩する可能性があります。パスワードは一意であると想定しています。 Gmailでのみ使用されます。
- 誰かがデータベースを入手できれば、パスワードのハッシュをブルートフォースでオフラインにすることができます。 Webサイトが少なくともソルトハッシュを使用している（ハッカーがすべてのパスワードを解読しようとする可能性は非常に低い）か、データベースがハッキングされる可能性は非常に低い（Gmailでの公正な仮定です）
- また、パスワードが辞書の単語や推測しやすいものではないと想定しています。これにより、複数のアカウントのブルートフォースが排除されます（たとえば、複数のアカウント間で同じ共通パスワードをテストする）.
他のセキュリティ対策を講じればすぐに、Webサイトへの長いパスワードは必要ないと想定しても安全ですか？通常、他のセキュリティアドバイスに従っていないために長いパスワードを使用することをお勧めします（アカウント間で同じパスワードを使用するなど）。原因ではなく、症状を修正しようとしているのではないですか？
PS：他のいくつかの質問はほとんど同じことを扱っていますが、答えは常に、その人がWebサイト全体で同じパスワードを使用している、またはWebサイトのデータベースが簡単に盗まれると考えています。
以下は実際にはこの正義を行いませんが、要約すると...
理想的な世界では、オンラインリソースに複雑なパスワードは必要ありません。
しかし、その理想的な世界では、システムの管理者がシステムを強化して「パスワードファイル」への不正アクセスを防止することに依存しているため、次のことがリスクを最小限に抑えます。
- インフラストラクチャを安全に構成します。
- パッチをすぐに適用してください。
- ゼロデイのエクスプロイトシナリオが発生した場合の侵害を特定するために、何らかの形で監視する（ユーザーがパスワードを変更するように「言われる」ことができるようにする）。
- 「安全な」プログラミング/開発方法論を用意し、それに従ってください。
- 信頼できる個人のみを雇用してください。
その完全な組み合わせは、多くのサイトでは考えられません。
上記のリストの弱点mayパスワードを完全にバイパスできるエクスプロイトが発生しますが、エクスプロイトの成功の性質に関係なく、システムへの不正アクセスを取得した後、攻撃者は攻撃を試みますパスワードファイルを引き出し、その後、ブルートフォースで他のシステムの（パスワードのリサイクルを悪用することによる）侵害を助長する。
したがって、強力な（より強力な）パスワードがすべての悪いことを防ぐ保証はありませんが、プロバイダーのソリューションの弱点（既知であるかどうかにかかわらず）を緩和するのに役立ちます。
誤解を避けるために、私たちはサービスプロバイダーに次のことを任せています。
- パスワードにハッシュとソルトを適用します。
- パスワードが平文で交換されないようにします。
ほとんどのエンドユーザーにとって、パスワードの複雑さと長さについての決定は、サイト（つまりパスワード）がアクセスを提供する情報に帰着すると思います。
私の推奨は、システムが危険にさらされた場合に他の人のパスワードが最初に発見される可能性があるように、何か重要な場合は複雑なパスワードを使用することです。しかし、それが簡単で便利なことがより重要な場合は、弱いパスワードを使用する可能性がありますが、ハッキングによってアカウントへのアクセスが失われたり、アカウントから情報が漏洩したりする可能性があることを受け入れてください。
多くのサイト所有者にとって、複雑なパスワードを要求する決定はFUDと、パスワードのブルートフォースを実行する時間を増やすことでコントロールの重大な障害の影響を最小限に抑え、実際の修正と最小化に要する時間を長くすることの組み合わせであると思います。ユーザーアカウントの侵害（攻撃者がパスワードハッシュにアクセスできる場合でも、おそらく他の方法でシステムを侵害するのに十分なシステムアクセス権を持っています）。
長いパスワードの推奨事項は、誰かがそのパスワードのハッシュにアクセスできる場合にパスワードが解読されるのを防ぐことです。
Hashcatのようなツールは93800M c/s md5ハッシュを（gpuを使用して）簡単にテストできます
ユーザーは通常、サイトがパスワードをどのように保存するかを知らないため、長いパスワードを使用して攻撃を緩和することをお勧めします。
良いパスワードを選ぶのは難しいです。人間とパターンに対する私たちの好みは、単純にそれがあまり得意ではありません。時間をかけて蓄積した数十のアカウントを掛けると、これが問題の根源です。
したがって、不正なパスワードとパスワードの再利用をなくすことで、ソフトターゲットの作成の問題を解決できますが、これらのアカウントとパスワードをすべて維持するという根本的な問題は解決されません。場所。したがって、「適切なパスワードセキュリティポリシーに従ってください」と言っても安全ですが、アカウント管理の問題に取り組むことなく、何も解決できません。
それで、答えは何ですか？パスワードマネージャを使用します。これは問題を解決します。パスワードの作成と管理の問題を、その目的のために特別に設計されたツールにオフロードすると、デフォルトで強力なパスワードが取得され、パスワードを再利用する必要がなくなります。これは完全な解決策ではありません（何もありません）が、現時点では最善であり、パスワードの複雑さと長さの問題について疑問を投げかけます。なぜなら、パスワードを作成して覚える必要がない場合は、もう気にしないからです。それがどれほど複雑で長いか、それを強力にするのに十分なエントロピーで生成され、パスワードマネージャーがそれを与えるだけです。
ローカルパスワード認証を使用するWeb開発者の唯一のsane仮定は次のとおりです。
ユーザーがすべてに同じパスワードを使用すること。
サイトの作成がまだ完了していない場合でも、サイトは既に侵害されている。そして
その妥協の結果に付随するいくつかの本当に高価な法的責任があります。
（私が示唆しているわけでも、示唆しているわけでもないことに注意してください。すべて、あるいはどれでも— Web開発者は正気であるか、彼らが何をしているのかを十分に知っています。彼らがしていることを知っていれば、insaneになります。単純なハッシュは、プレーンでもソルトでも、計算上、プレーンテキストに十分近づいているため、最近はまったく気になりません。しかし、プレーンテキストや無塩のMD5などが、いわゆる「チュートリアル」でウェブ全体に散らばっていることに気付き、どこにいてもサーバーのプロダクションに対処して貼り付けています。
これらの前提は、私がサイトを実行していて、人々がオーガニックで放し飼いの、地元で育てられたグルテンフリーのハムスタートリートに関する推奨事項を一覧表示できるように専用の非常にローカルなアプリケーションを使用している場合でも、パスワードをあたかもPaypal、eBay、および電子メールのアカウントをすべて組み合わせます（効果的になる可能性がかなり高いため）。つまり、私自身のかなり貴重な背後を保護するためには、少なくともいくつかの最小限の手順を実行して、あなたがそれを気に入っているかどうかに関係なく、あなたの貴重な背後を保護する必要があります。理想的には、それはパスワードを簡単にブルートフォースできないものにして（暗号ランダムソルトと高価なキー導出関数を使用して）、文字数に絶対的な下限を設定することを意味します（理想的には上限なし、上限なし） ）、覚えやすいものを使用できるようにします（「少なくとも1つのアクセント付き文字、1つの絵文字、1つのひらがなを使用する必要がある」という意味はありません）。言い換えると、本当に短いパスワードを使用できるようにすると、私の個人的な尻が不当な危険にさらされるため、許可しないでください。 それが私のサイトが秘密を守らない場合ですexceptあなたのパスワード私に責任があるあなたに関連付けられている実際の個人データがある場合、あなたに代わって私のパラノイアが劇的に増加することを期待してください。
単一の安全なサイトに複雑なパスワードを使用することは、アパートのドアに特別なロックを使用するようなものです。これにより、ドアを開くのに時間がかかり、すべての強盗の1％からよりよく保護されます
ほとんどの回答は、パスワードを危険にさらす可能性のあるあらゆる種類の攻撃シナリオを扱っていますが、妥当なセキュリティを備えた1つの単一サイトでのみ使用する場合は、短いパスワード（6文字）で十分かどうかを判断するには、1つの数字を比較するだけで済みます：
強力なパスワードよりも弱いパスワードの方が、はるかにうまく機能する攻撃はいくつありますか？
オンラインのブルートフォース保護が十分に強力な場合（問題の前提）、関連する唯一の攻撃シナリオはオフラインのブルートフォースです。他のすべての攻撃シナリオ（プレーンテキストのパスワード読み取り、セッション盗難、ソーシャルエンジニアリング、フィッシング、ユーザー偽造）では、パスワードの複雑さは何の役割も果たしません（標準のパスワードでない場合）
では、アカウントまたはGmailに対する攻撃の何％が、パスワードの実行可能なオフライン総当たり攻撃を使用するのでしょうか。おそらく次のどれにも。ブルートフォースは、パスワードのハッシュまたは暗号化されたバージョンに対してのみ機能します。それ以外の場所では、パスワードはプレーンテキストである（そのため、複雑さは関係ない）か、まったく関係がない（例：セッションID、インサイダーからメールストレージサーバーへの直接アクセス）
パスワードが暗号化またはハッシュされる唯一の例は、1。データベース内のソルトハッシュと2. HTTPSを介したパスワードの転送です。
データベースのソルトハッシュハッカーがすべてのユーザーパスワードが格納されているデータベースにアクセスできたが（おそらくインフラストラクチャで最も安全なポイントの1つ）、他のサービス（アクティブなセッションIDや直接アカウントアクセス）次に、ブルートフォース攻撃によるソルトハッシュに対するオフライン攻撃は、すぐにパスワードを使用します。
HTTP転送攻撃者がパスワードを分離するためにHTTPSストリームをブルートフォースする必要があるため、ほとんどあり得ないため、パスワードの長さはほとんど問題になりません。
したがって、長いパスワードが実際にあなたを保護する唯一のシナリオは、誰かが気づかずに（おそらく）最も安全なインフラストラクチャのデータストレージにアクセスし、アカウントに簡単にアクセスするための十分なアクセス権がない場合です。アカウントに対する脆弱性や攻撃の数が非常に多いため、これはありそうもない攻撃タイプの1つに過ぎないため、このシナリオは本当にありそうもないと思います。
いくつかの仮定に問題があります。
オフライン攻撃があった場合、309百万は笑えるほど少ない数です。そして、オフライン攻撃では、良い塩があったとしても、攻撃者はまず、ぶら下がっている果物を追いかけます。つまり。辞書にあるパスワードを探し、次に短いパスワードを探し、次に他の単純なパスワードを探します。ただし、これがどれほどの問題であるかについては、議論の余地があります。パスワードデータベースにアクセスした攻撃者が、他の何にでもアクセスできる可能性は十分にあります。 -これは、パスワードの再利用が行われていないことを前提としています。
309百万は、ご存じのように、オンライン攻撃で総当たりするには検索スペースが大きすぎます。ただし、この数につながるあなたの仮定は疑わしいです。種としての私たちは、2つの関連するタスクが悪名高く知られています。真にランダムなシーケンスを思い付き、ランダムなシーケンスを覚えています。これは、6文字のパスワードを選択した場合、エントロピーが大幅に低下することを意味します。これは、パスワードマネージャーまたは同様のユーティリティを使用する場合は回避できますが、その場合は、オフラインの攻撃から保護するためにより長いパスワードを使用することもできます。
結論として;パスワードで適切なエントロピーが得られるかどうかは、エントロピーpr文字とパスワードの長さに依存します。 -1文字あたりのエントロピーが良い場合は、短いパスワードを受け入れることができます。ただし、文字あたりのエントロピーが低い短い文字列よりも文字あたりのエントロピーが低い長い文字列をよく覚えているため、これはほとんどの人間にはあまり適していないアプローチです。ランダムな文字列を生成するときもそうですが、あなたが引用するアドバイスは、パスワードマネージャーを使用してパスワードを生成しない人向けです。
複雑なパスワードを作成する方が安全ですが、同時に簡単にすることを常にお勧めします。また、Webサイトごとに独自性を持たせることをお勧めします。これが脆弱性になる唯一の方法は、フィッシング詐欺に遭遇した場合です。このため、電子メールは他のアカウントを回復するための手段であるため、電子メールアドレスを回復する方法が複数あることが重要です。
私が個人的に使用するルールは次のとおりです。
- 8文字以上または10文字以上、できれば12文字以上
- あなたにとって何か意味のあるものを使う
- 省略形または文字の代わりに数字を使用することは簡単ですが効果的です
- 必要に応じて、プレフィックスまたはサフィックスを使用してパスワードを一意に保つことができます
だから例えば：ThisIsMyPassword14si
用途：大文字、数字、およびスタック交換のためのsiのサフィックス。1年は何か個人的に意味のあるものです。この種のパスワードは通常、強力なパスワードとして常に表示されます。
別のトークンベースのサービスを使用してサインインできるようにするサービスも他にもあります。これは素晴らしいアイデアだと思います。アクセスを削除したいときはいつでもログアウトでき、すべてのサービスにパスワードは必要ありません（開発者がプロセスを正しく設計したと仮定します）。ただし、そのサービスへのパスワードについてはより注意深く、何らかの理由でパスワードを紛失した場合に備えて、複数の回復オプションを用意する必要があります。
複数の回復オプションと2要素認証を使用することで、Googleはここで正しい方向に向かっていると思います。問題は、情報を要求している実際のページに注意を払わないと、ほとんどすべてがなりすまされる可能性があることです。
うまくいけば、将来的には、携帯電話のように、Webサービスのセキュリティクリアランスとして機能するデバイスがあなたの手元にあるでしょう。アプリはディストリビューターによって制御されるので、プラットフォームごとに1つのアプリを用意してアクセスリクエストを取得し、許可を求めることは、将来的にそれを処理する正しい方法となるため、この個別のパスワードについて心配する必要はありません。すべてナンセンス。
... ある日...
私の答えは単にイエスです。サイトがソルトハッシュ方式を使用しているとは限りません。たとえば、MD5はまだ実際に使用されており、人々はそれを完全に許容できると考えています。
しかし、強力なソルトハッシュメカニズムを使用すると、たとえ低い文字パスであっても、誰かが実際のパスワードにアクセスすることはできません。特に、サーバーが適切に保護されていて、APIがブルートフォース攻撃に対して適切な予防策を講じている場合は特にそうです。
ローカルの物理的な攻撃を忘れました！長い複雑なパスワードを使用すると、ショルダースポッティングが成功する可能性がはるかに低くなります。誰かが私のキーボードを見つめても、彼がレインマンでなければ、彼は私のパスワードを取得しません。 （コメントできません）
信頼性の高い2要素認証システムを使用する場合は、安全性の低いパスワードを使用するのが妥当です。大文字と小文字、数字、記号を使用してパスワードジェネレーターによって生成された難しいパスワードを使用するのが依然として最善です。
しかし、そのような安全なパスワードを導入しない人たち。 2要素認証を提供するサービスの場合、それらの人々はかなり安全だと感じることができます。
誰かが1つのターゲットをブルートフォースする必要がないことを忘れないでください。彼らは多くのターゲットで同じパスワードを試すことができ、最も一般的なパスワードを持つユーザーを脆弱にします。