web-dev-qa-db-ja.com

すべてのサイトがユーザーのパスワードを生成しないのはなぜですか?

私は この質問 に出くわしました。そして、それを行うサイトをこれまでに見たことがありません。これは危険信号です。ただし、このアプローチは適切に見え、強力なパスワードを適用するためにパスワードルールを実装する必要が出てきます。また、すべてのサイトがそうした場合、ユーザーがパスワードを再利用しないことが保証されます。それで、そのアプローチの欠点は何ですか?すべてのサイトがそのアプローチを使用しない正当な理由はありますか?

具体的には、その質問のコメントと回答で出てきた次のようなベストプラクティスに従うことを前提としています。

  • 長い(32文字以上の)ランダムな(ランダム性の良い)パスワードを生成する
  • 一度ユーザーに見せます
  • sHA256でそれをハッシュしてください
  • パスワードをリセットすると、別の長いランダムなパスワードが生成されます

実際、おそらくユーザーにパスワードを表示する代わりに、ブラウザやパスワード管理者がパスワードを入力できるようにパスワードフィールドに入力されたフォームを表示するだけで、アプローチはさらに強化される可能性があります。ユーザーはフォームを送信するだけで、フォームを表示する必要はありません。

13

ユーザビリティを犠牲にしたセキュリティは、セキュリティを犠牲にしてもたらされます

問題は、ユーザーに適切なセキュリティプラクティスを強制するために実行できるWebアプリケーションの数が限られていることです。この特定のケースでは、大多数のケースで何が起こるかを説明できます。人々は「安全な」パスワードをどこかに記録します。結果として、これは必ずしもより安全になるわけではありません。脆弱性が存在する場所をシャッフルするだけです。本質的に、このシステムには、ユーザーエクスペリエンスを非常に簡単にするために必要なサポートアーキテクチャが欠けているため、非常に安全です。結果として、基本的に3種類の人々が3つの異なる結果をもたらします。

  1. パスワードのセキュリティについて気にしない/理解しない人。彼らは、超解読可能な場所にその解読不可能なパスワードを書き留め、その結果、超安全性が失われます。これらは、すべてのサイトで同じ脆弱なパスワードを再利用する同じ人々です。その結果、あるセキュリティソリューションから別のセキュリティソリューションに移行します。これらはWebユーザーの大多数でもあるため、インターネットの大部分では、ソリューションに実際のメリットはありません。
  2. パスワードマネージャーやその他のパスワードヘルパーを使用している人は、パスワードシステムをWebサイトに統合できません。突然彼らの通常安全なシステムがもはや使用できなくなるので、これらの人々は悪化するでしょう。その結果、彼らはおそらくそれを書き留めてしまい、おそらく安全ではなく、以前よりも悪くなるでしょう。明確に言うと、これは間違いなく起こります。「パスワードマネージャーが記録できるようにフォームにパスワードを表示する」ソリューションは、一部のパスワードマネージャーでは完全に機能しません。ほぼ保証できます。
  3. パスワードマネージャーを使用するユーザー、およびそれらのパスワードマネージャーはシステムに適切に統合されます。彼らはすでに物を安全に保管していますが、今では別の障害点があります:乱数ジェネレーターです。ただし、全体的に見て、セキュリティは大幅に低下も増加もしていません。

したがって、全体として、私はこのシステムに本当のメリットはないと思います。

これは他のすべてのコンテキストで重要であるため、これを大声で言わなければなりません。パスワードのハッシュにSHA256を使用することは決してありません。この場合、パスワードが長すぎてブルートフォースを実行できないため、高速ハッシュを回避できます。

明白な答えを追加するために編集

このソリューションの最大の問題は、根本的な問題を修正するのに十分ではないことです。根本的な問題は、人々がパスワードを誤解していることです。私たちは、貧弱なものを選択するか、それらを再利用するか、安全に保管しません。解決策は、新しいパスワードシステムを考案することではありません。解決策は、パスワードをすべて破棄することです。多くの企業がパスワードなしのログインを導入し始めています。それがあなたが本当に望んでいる答えです。

22
Conor Mancone

あなたの解決策は、人々にパスワードマネージャーを使わせることです。人々はブラウザにパスワードを保存するかもしれませんが、それは常に暗号化されるわけではなく、多くの場合ローカルにのみ保存されるため、複数のコンピュータからサービスにアクセスできなくなります。 mostは、パスワードマネージャーが何であるかさえ知らないことに注意してください。

また、パスワードマネージャーを持っている場合でも、すべてのデバイスでパスワードマネージャーにアクセスできますか?誰かがランダムな32文字のパスワードを一度でも入力する必要がある場合、彼らはそのためにあなたのサイトを憎み始めます。

9
JPhi1618

私の頭に浮かぶ2つのこと:

  1. ユーザーが自分のパスワードを選択できないのは、パスワードマネージャーや何らかのシステムがない限り、覚えていないか、書き留めておくか、どこかに記録しておく必要があるためです。

  2. Webサイトが「ランダムな」パスワードを生成する責任を負う場合、パスワードを生成する方法が将来的に欠陥を含むことが判明し、既存のすべてのパスワードのセキュリティが一度に危険にさらされる可能性があります。最近、欠陥が発見されたコンピューターでBitLockerパスワードを生成するハードウェアチップがあったと思います。今では、これらすべてのBitLockerパスワードがAWSで約$ 40,000で解読される可能性があります。たくさん。

3
downwardCorgi

そのアプローチの欠点は何ですか?

まず、他の認証方法で大幅に削減された追加の手順です。これはユーザーにとって余分な労力です。パスワードは...忘れがちであり、それは彼らのまさに目的を無効にする問題になる可能性があります。最も重要なのは、現実には触れられない強力なパスワードルールは安全でないことです。

これは、いくつかのフォーラムで最も一般的なパスワードを試す人々を通して観察できます。彼らが忘れていたあいまいで異常なルールのために彼らが間違っていることを発見したため、彼らはオウムとユーザー名とパスワードの組み合わせを続けています彼らはこれまでログインフィールドに使用したことがあります。そのようなランダムな見知らぬ人とパスワードを共有するだけの場合、パスワードのポイントは何ですか?

これを行うサイトに気づいたときはいつでも、他のサイトのパスワードを巧妙にフィッシングしようとしているのではないかと疑っています。私が関係している限り、今日の銀行代理店でない限り、正当と見なされるようにしたい場合は、パスワードを保存しないでください。より信頼性が高く、より安全なより良い方法があります。

詳しく説明します。ユーザーに保護するものがない限り、ユーザーが望んでいることを何でもパスワードとして使用できるようにします。つまり、パスワードを使用する場合は、空白のパスワードでも許容されます。


すべてのサイトがそのアプローチを使用しない正当な理由はありますか?

他のユーザーにアクセスを許可する "サイト"を一般的に検討しているサイトを実行しており、パスワードを保存したり、パスワード要件を強制したりしませんまったく;私は認証に証明書を使用し(現代のテクノロジーと同様に)、人々は(選択した場合)末尾にパスフレーズを付けてそれらの証明書を保護できます。

私のサイトはサーバーであり、非常に理由があります私はそうではありません他人のパスワードを保存したい。ユーザーの1人がサーバーへの管理アクセス権を取得した場合、他のパスワードハッシュを取得する可能性があります。

同様に、thisサイトを観察できます。このサイトは、StackExchangeネットワークにすでにログインしているため、パスワードを入力する必要がなかった可能性があります... StackExchangeネットワークではFacebookやGoogleを使用してログインできるため、それも可能です。

証明書認証は新しいものではありません。これはPAMで長年使用されていますが、パスワード認証は必要ありませんので、銀行だけがパスワードだけでなく、より強力です。


長い(32文字以上の)ランダムな(ランダム性の良い)パスワードを生成する

あなたはこれを行うことができますが、パスワードを忘れたまたはmisorganiseすると、一部のサービスのパスワードを他のサービスに提供することになります。あなたがそれに満足しているなら、そうしてください。銀行口座が解読されても、世界は止まることはありません。

申し訳ありませんが、ナンスソルトの署名に使用され、サーバー側に直接保存されることのない長いランダムなプライベート証明書を生成するよりも、長いランダムなパスワードを生成する方が安全であると主張する人はいません。


一度ユーザーに見せます

あなたはすべきではないユーザーを表示する(パスワードが何かのためのものでない限り重要でない(インターネットフォーラムと同様)ですが、代わりに、SSHキージェネレーターは、キーが生成されるときにパスフレーズを繰り返すようユーザーに要求する必要があります。肩越しに見ている人に「パスワード」をプレーンテキストで表示しないことを除いて、これは視覚的検証と同じ効果があります(おそらくさらに強力です)...


sHA256でそれをハッシュしてください

saltを使用することを提案することもできます。問題は、まだdigestを保存していて、ユーザーが他のサービスのパスワードをまだオウムを使用している可能性があることです。 「パスワードを忘れた」問題の解決策は、これまでに使用したすべてのパスワードを試行することではなく、セキュリティを大幅に弱めることではなく、パスワードを削除します(サーバーから)。


パスワードをリセットすると、別の長いランダムなパスワードが生成されます

最も強力なパスワードベースの認証スキームでさえ、電子メールや携帯電話などの他のいくつかの技術が原因で、長期にわたる欠陥があります。それらのいずれかが最も弱いリンクになると、passwordオプションが完全に折りたたまれていることがわかります。

プライバシーとセキュリティの両方に関する今後の方法は、メール、電話番号、パスワード、PINコードではなく、暗号化キーを使用して認証することです。


実際、おそらくユーザーにパスワードを表示する代わりに、ブラウザやパスワード管理者がパスワードを入力できるようにパスワードフィールドに入力されたフォームを表示するだけで、アプローチはさらに強化される可能性があります。ユーザーはフォームを送信するだけで、フォームを表示する必要はありません。

解決策は、パスワードをメモリのどこかに保存して、そのメモリの場所にアクセスするだけでパスワードを見つけることです。それは私にはほとんど解決策のようには思えません。 USBペンドライブのパスフレーズで保護されたGPGキーなど、物理的なものを使用します。

3
autistic

多くの論文が同様のスキームを研究しているのを見たので、これを提案するのはあなただけではありません。ただし、通常、システムが生成したパスワードは、ユーザーが生成したパスワードと比較して、使いやすさが大幅に低下します。

システムで生成されたパスワードとニーモニックアプローチ では、研究者Sanjaykumar Ranganayakuluは次のように結論付けています。

一般に、この調査では、割り当てられたものよりも生成したパスワードやニーモニックを覚えている傾向があることがわかりました。システムで生成されたニーモニックは意味のある文章でしたが、参加者はパスワードや自分で作成したニーモニックと同様に、関係者との関係を築くことができませんでした。

Moshe ZviranとWilliam J. Hagaによる古い1990年の米海軍の調査では、いくつかのパスワードスキームを比較しました。数か月後にパスワードを思い出してください。システムで生成された発音可能なパスワードが最も効果的で、ユーザーが生成したパスワードとパスフレーズは問題​​なく機能し、英数字のシステムが生成したパスワードが最も悪かったため、すべてのユーザーが覚えるのではなくパスワードを書き留めました。読みやすいパスワードの驚くべきパフォーマンスにもかかわらず、ユーザーは自分のパスワードを選択することを好んでいました。

システムから生成されたランダムなパスワードをメモリから思い出すことはできませんでした...

覚えやすさに関してさまざまな方法をランク付けするように求められたとき、回答者はユーザーが生成したパスワードを最も簡単だと思ったものとして明確に選択しました...

ユーザーがさまざまな種類のパスワードを思い出す能力を調べると、[システムで生成された]読みやすいパスワード...パスフレーズ、ランダムなシステムで生成されたパスワード、またはユーザーが選択したパスワードよりもはるかに優れていることが証明されました

結局のところ、システムで生成されたパスワードの使いやすさは、スキームによって大きく異なります。ランダムな32文字の英数字を使用したシステムは、ユーザーフレンドリーになるように設計されていないようです。ただし、一部のシステム生成スキームは、xkcdの「ランダムな4つの単語を選択する」スキームのように、まともなセキュリティとかなり高いユーザビリティを備えています。他のユーザーフレンドリーなシステム生成スキームには、発音可能なパスワード生成、およびシステムによって生成された便利なニーモニックを持つランダムに生成された英数字が含まれます。調査されたこれらの種類のスキームは、あなたが提案しているようなシステムよりもはるかにうまく機能します。

調査されたユーザビリティの問題だけでなく、他の技術的な問題がありますが、他の回答はそれらの問題をすでにカバーしています。

したがって、あなたのようなスキームは、研究で数回評価されており、ユーザーからはあまり受け入れられていません。一般に、システムで生成されたパスワードはユーザーにうまく受け入れられず、注意深く実装しない限り、思い出すことが難しくなります。通常、パスワード強度メーター、疑わしい動作の通知、2要素認証、パスワードの長さの要件、一般的なパスワードの禁止、ブルートフォース攻撃やパスワードハッシュリークからの保護など、代替手段の方がはるかに適切です。

2
Cody P

弁護士ではありませんが、ユーザーからパスワードの責任を取りたくない企業にとって私が考えることができる重要な理由の1つは、誰かがパスワードを入手して何かをしたためにデータ侵害が発生した場合に、会社が責任を問われることになります。確かに、いったんパスワードが生成されたら何が起こるかはユーザーの責任ですが、誰か(または、さらに悪いことに、Yahoo!やAdobeなどの場合は誰かのクラス)が会社を保持することを決定した場合、法廷でそれを確立するのは費用がかかります単独で責任があります。

より現実的なレベルでは、人々には選択肢があり、セキュリティを強化するというある程度の一般的な慣行と利便性を捨てて、定量化の方法すらわからないような、根強いセキュリティ狂信者だけが行くことになります。サービスを試すことに決めたとしても、3回目または4回目のパスワードリセットで忘れてしまったため、文字を誤って入力した(パスワードフィールドの制限のために表示されなかった)ので、ペーストできませんでした。 。、彼らはあなたの競争相手を真剣に考えて、彼らのファンタジーフットボールチームの今日の様子をチェックするためだけにそのようなフープを通過させないでしょう。

2
Kaji