このハッシュベースの個人パスワードスキームはどの程度安全ですか？

Question

私は少数の覚えやすい個人パスワードを保持するパスワード方式を使用しています。各サービスに直接パスワードを使用する代わりに、最初にハッシュアルゴリズムを実行し、実際のサービスの名前と一緒に一種のシードとして実行します。次に、結果のハッシュをサービスの実際のパスワードとして使用します。（さらにいくつかありますが、いくつかの通常のパスワード要件を満たすためにいくつかの固定文字を追加しますが、この質問ではそれを避けましょう。）

パターンは次のようになります（SHA512を使用し、結果のハッシュの最初の12文字のみを保持します）。

"my_p4SSWord!" + => SHA512 => "d4679b768229" "Facebook" "my_p4SSWord!" + => SHA512 => "182c5c2d4a2c" "LinkedIn"

このパターンにより、すべてのオンラインパスワードを覚えるのではなく、必要なときにいつでも簡単にパスワードを再作成する方法を覚えることができます。

ハッシュを計算するための多くのオンラインサービスがあり、私は現在これを使用しています（これはJavaScriptのみなので、純粋にクライアント側です）。

https://emn178.github.io/online-tools/sha512.html

セキュリティの専門家への私の質問は、私の個人的な計画は本当にどれほど安全か？ハッシュを12文字に切り捨てます。それは私のパスワードの本当の解読性にどのように影響しますか？また、SHA512を使用しています。たとえばbcryptを使用するのとは対照的に、それは私のスキームにどのように影響しますか？

コメントは？

edit：私はここでひどく反応しているので、感謝します。これが締め切られる前に、簡単なコメントをいくつか付けておきます。

特に、使用しているハッシュの暗号化の特性、および実行している切り捨ての結果として、それらに対するブルートフォース攻撃が成功する可能性が高くなることについて尋ねていました。

また、多くの人が使いやすさについて言及しています。覚えておくべきことは、ほとんどのパスワードは実際に入力する必要がないということです。ただし、OSのパスワードは例外です。私の場合、私のOSへのハッシュ化されたパスワードを覚えているだけです。残りについては、ハッシュを検索して再生成する必要があるたびに、それはマイナーな不便です。迅速で、ツールは標準化されており、どこでも利用できます。

また、特定のサイトのパスワードをdo変更する必要がある場合に使用できる簡単なルールがあります。簡単に覚えることができ、書き留める必要がないルール。

最後に、これはほとんど何もしない代わりの手段として主に意味します。結局のところ、これは、ほとんどの人が、加入しているすべてのオンラインサービスで同じパスワードを無差別に再利用するときに行っていることです。

最後に、親切にしてください！

edit2：ハッシュの暗号化プロパティではなく、回答のメソッドに多くの焦点があります。これは、私が元々意図していたものです質問。

メソッドに重点を置いているので、追加の情報を1つだけ追加します。つまり、脇に小さなテキストファイルを保持します。テキストファイルは、私が知る限り、ケルクホフスの原則に従って、物事を明らかにしますが、キーは明らかにしません。これが、私の最初の質問がハッシュの暗号特性とその強さに焦点を合わせている理由です。

Esa Jokinen · Accepted Answer

SHA-512

長所：

雪崩効果により、接尾辞を変更するたびにSHA512の合計が完全に変更されます。これは、あるハッシュの最初のN文字から、別のハッシュの最初のN文字について何も言うことができず、パスワードを完全に独立させることを意味します。
SHA512は一方向の圧縮関数であるため、ハッシュからパスワードを推測することはできません。同じSHA512合計を与えるブルートフォースパスワードを試すことができます。ハッシュの一部しか使用しないため、一致する複数のパスワードを見つける可能性が高くなります。

短所：

長さが12文字で文字と数字の両方が含まれているため、強力なパスワードを持っていると思いますが、実際には非常に制限された文字セットが_0-9_ + _a-f_（これは16進数です）。これにより、_16^12_、つまりlog2(16^12)=48ビットのエントロピーのみが得られます。これは、_a-z_ + _0-9_の10文字未満で、_a-z_ +の8文字に近い値です_A-Z_ + _0-9_。
オンラインサービスは、作成したハッシュを保存できます。代わりに、ハッシュにはローカルツールを使用してください。
すべてのケースでシードを思い出せない可能性があり、パスワードを失う可能性があります。
- パスワードを変更する必要がある場合、または変更が必要な場合はどうなりますか？シードは_my_p4SSWord!Sitename2_または何か他のものになりますか？どのようにカウントを追跡しますか？
- サイト/サービス名は常に明確であるとは限りません。 GmailのパスワードサフィックスはGoogleまたはGmailでしたか、それとも最初にYouTubeを使用しましたか？ MicrosoftアカウントはMicrosoftまたはLiveまたは_Office365_でしたか？
- これらの組み合わせは物事をさらに醜くします。
サイトにパスワードの複雑さの要件がある場合、ハッシュ後に文字を追加したり、一部の文字を手動で大文字に変換したりする必要がありました。これらの変更を追跡する方法は？
誰かがまだあなたの手順を知ることができます。単一のパスワードを作成/使用しているのを見ることによって。それはすべてのパスワードを一度に侵害します。

bcrypt

Bcryptの人はするだろう

Radix-64 64文字のエンコーディングを使用して、よりエントロピーを与えます。
ASCII 32（スペース）〜95 ___
（!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_）
計算が遅くなる
ユーザーが定義した反復回数を使用して、希望する速度まで遅くすることができます

...saltingを組み込んでおり、毎回異なるハッシュを与えるため、現在の手順と互換性がありません：

_$ htpasswd -nbBC 12 Elling my_p4SSWord\!Sitename Elling:$2y$12$jTkZQqYzWueA5EwKU1lLT.jbLLXUX.7BemHol.Q4SXhoJyeCVhcri Elling:$2y$12$c1lDwR3W3e7xlt6P0yCe/OzmZ.ocKct3A6Fmpl8FynfA.fDS16bAa Elling:$2y$12$eAciSW6iGxw/RJ7foywZgeAb0OcnH9a.2IOPglGGk.wL9RkEl/Gwm Elling:$2y$12$EU/UDJaZYvBy6Weze..6RuwIjc4lOHYL5BZa4RoD9P77qwZljUp22 _

...静的ソルトを排他的に指定しない限り（ PyPI bcrypt などの一部の実装で可能）。

パスワードマネージャー

すべての短所は、パスワードマネージャーで解決されます。

ランダム
まったく無関係
異なる要件（異なる文字セットと最小/最大長）を持つことができます。

schroeder · Answer

使いやすさの観点からは、それはひどいです。ログインするたびにハッシュを生成する必要があります。パスワードマネージャーを使用して真にランダムな文字列を検索する場合でも、作業は少なくなります。

セキュリティの観点から、クライアント側のハッシュとパスワードパターンの使用の問題を組み合わせました。

はい、クライアント側でパスワードハッシュを使用すると、プレーンテキストのパスワードがサーバー側の機能の脆弱性から保護されます。しかし、クライアント側で妥協がある場合、これは役に立ちません。
Kerckhoffsの原則は生き残りません。これがあなたのプロセスであることを攻撃者が知っている場合、特定のサービスのパスワードはmy_p4SSWord!のみです。それがわかったら、すべてのアカウントにログインできます。パターンを再利用すると、パスワードが判明するとすべてのパスワードが公開されます。

tim · Answer

スキームの主な目的の1つは、1つのパスワードが侵害された場合にすべてのアカウントへのアクセスを防ぐことです。単純なパスワードの再利用よりも優れていますが、攻撃者によって簡単にバイパスされ、imhoは追加された複雑さを正当化するのに十分な値を追加しません。

あなたが暗号の特性に焦点を当てたいと言っているように：

sha512はひどく速い関数で、パスワード保存用の暗号化ハッシュ関数として不適切です。

漏えいしたパスワードからキーを取得しようとする場合、ハッシュの切り捨ては関係ありません[*]。衝突が増加しますが、攻撃者はハッシュを生成する入力だけでなく、正しいキー（_my_p4SSWord!_）を必要とします。

したがって、攻撃者があなたのアプローチを知っていて[**]、1つのWebサイトだけでプレーンテキストのパスワードを危険にさらすことができたと仮定した場合[***]、おそらくsha512([key_guess]compromisedwebsite)適切な時間を確保し、他のWebサイト上のすべてのアカウントにアクセスします。

私がリンクしていたツールはJavaScriptのみなので、クライアント側のみ

これを確認しましたか？変更が加えられていないことを毎回確認していますか（所有者によって、またはサイトまたはJS依存関係の1つが侵害されているため）。

個人的には、とにかくパスワードスキームにサードパーティの依存関係が必要な場合は、パスワードを安全に保つために特別に設計されたオンラインパスワードマネージャー（または、それが実用性の点で実現可能なオフラインパスワードマネージャー）を信頼したいと思います。

_{[*]攻撃者がハッシュされたバージョンのパスワードにしかアクセスできず、最初にそれを解読する必要がある場合に関連性があります。したがって、不要と思われるため、切り捨てをスキップします。}

_{[**]それは今です:)}

_{[***]登録した偽のWebサイトをセットアップした可能性があります。パスワードをプレーンテキストで保存/ログ/送信するサイトに登録した可能性があります。登録したサイトにRCEがあり、すべてのパスワードをそのまま記録する可能性があります。入りました}

Schwern · Answer

コメントは、全体を見るのを難しくすることをめぐって行き詰まっています。もぐらたたきをするのではなく、ここに要約があります。

まず、パスワードスキームはベストプラクティスを改善する必要があることを覚えておいてください。ベストプラクティスは、適切なパスワードジェネレーターを備えた適切なパスワードマネージャーを使用することです。

また、セキュリティは最も弱いリンクと同じくらい強力であることも覚えておきましょう。私が窓から入ることができれば、あなたのドアがどれほど素晴らしいかは関係ありません。単一の弱点は、スキーム全体を無効にします。すべての弱点に対処する必要があります。

最後に、システムのセキュリティは理想的ではなく、実際にどのように使用されているかとして評価されます。 OPの質問は理想的なものでしたが、コメントや編集の過程で、実際にはかなり異なって使用されていることがわかりました。

パスワードはキーと同じくらい強力であり、すべてのパスワードはキーを攻撃にさらします。

このシステムの主な欠点は、すべてのパスワードがキーを公開して攻撃することであり、すべてのパスワードの強さは、キーをブルートフォースすることがどれほど難しいかにかかっています。

キーをブルートフォースで強制するには、パスワード、salt、プレフィックス、およびプロセスが必要です。

パスワードのセキュリティは管理していません。パスワードが漏洩すると想定する必要があります。 salt は、設計上、簡単に推測できます。プレフィックスは、複数のパスワードを比較することで発見できます。 Kerckhoffsの原則プロセスが公開されていると想定する必要があると述べています。

不適切なハッシュアルゴリズムを選択すると、ブルートフォーシングが本来よりも簡単になります。そして、後で見るように、いったんパスワードを作成し始めると、これを修正するのはますます困難になります。同様に、キーは変更できません。あなたはますます弱い鍵で立ち往生しています。

パスワード管理者にはこれらの欠陥はありません。

理想的な対実践

このスキームの理想的なバージョンは、その使いやすさについてこれらの主張をします。

鍵を覚えるだけで十分です。
それは無国籍であり、書き留める必要はありません。
塩を選択するプロセスはシンプルで簡単に覚えられます。
第三者を信頼する必要はありません。
「私のすべてのオンラインパスワード」を処理できます。

これらは実際には成り立たない。

キーとプレフィックスの2つを覚えておく必要があります。
塩と接頭辞は書き留められているのは...
コーナーケースは、ソルティングが複雑で、複数のプレフィックスが必要であることを意味します。
キー、プレフィックス、およびパスワードを使用して、安全でないサービスを信頼することを選択できます。
セキュリティと使いやすさを損なうことなく、すべてのオンラインパスワードを処理することはできません。

対照的に、優れたパスワードマネージャー...

マスターパスワードを覚えておく必要があるだけです。
状態がありますが、すべて暗号化されています。
覚えておくべきアルゴリズムはありません。
は専門家による監査です。
すべての秘密を処理できます。

ユーザーは、あまりにも多くの重要な決定を行わなければなりません。

ユーザーは、ハッシュアルゴリズム、ハッシュ方式、キー、プレフィックス、ソルトプロシージャを選択する必要があります。これらはすべて、ユーザビリティとセキュリティに影響を与えます。これらはユーザーが作成することはできません。

たとえば、OPは不適切なハッシュアルゴリズムを選択したため、ブルートフォースを簡単に強制できます。彼らは信頼できないサイトを使用してハッシュを行い、すべてを公開しました。それらのソルトプロセスは、一部のサービス名を書き留めてユーザビリティを低下させる必要があるすべてのケースをカバーするには不十分です。選択したプレフィックスは、すべてのパスワード要件をカバーするには不十分な場合があります。

このスキームは、専門家にユーザーの選択を推奨させることで改善できますが、ユーザーはそれらを無視できます。

優れたパスワードマネージャには、これらの欠陥はありません。プロセス全体が専門家によって作成され、絶えず見直しおよび改善され、ソフトウェアによって処理されます。

悪い選択は修正できません。

このスキームでは、パスワードは4つの要素に依存しています。

キー
接頭辞
塩プロセス
ハッシュアルゴリズム

これらのいずれかを変更し、allパスワードを変更する必要があります。これにより、システムが非常に脆弱になり、セキュリティと使いやすさに多くの影響があります。

言うまでもなく、優れたパスワードマネージャーには、これらの欠点はありません。

残りについては、簡潔にするために、「変更できない」と言った場合は、「すべてのパスワードを変更しないと変更できない」をお読みください。変更が困難な場合、ユーザーはセキュリティに妥協する可能性があります。

ハッシュアルゴリズムは変更できません。

弱点が露呈した場合は、ハッシュアルゴリズムを変更できることが重要です。優れたシステムは、今後のパスワードをより適切にアルゴリズムで静かに交換できるでしょう。

SHA-512は不適切な選択であり、すでに露出オーバーのキーをブルートフォースで簡単に強制することができます。

パスワードマネージャがこれを処理します。

キーはますます危険にさらされます。

必須のパスワードローテーションは流行しなくなりましたが、セキュリティ侵害の疑いがある場合にキーを変更できるようにする必要があるというセキュリティの要です。プロセスが単純であるほど、脆弱性のヒントで新しいキーを使用する可能性が高くなります。

弱いキーを選択した場合、より良いキーを選択することはできません。計算能力が強くなるにつれて、より強力なキーが必要になります。

パスワードマネージャーを使用すると、マスターパスワードを何度でも変更できます。

塩漬けの手順は不十分です。

ソルトを書き留めないようにするために、サービスのソルトを取得する手順は、すべての状況に対応できる十分な柔軟性があり、覚えて頭の中で実行できるほど単純でなければなりません。

ユーザーが単純なスキームを選択して、それがますます不適切になることに気づくでしょう。ここにいくつかのコーナーケースがあります...

Github.comは「Github」または「GitHub」ですか？
Foo.comが "Foo"の場合、foo.usとは何ですか？
Foo.github.ioをどのように保存しますか？
Foo.ioがfoo.github.ioであったことに気付くでしょうか？

手順はすべての状況を予測できるわけではありませんし、非常に複雑なので頭の中で確実に行うこともできません。必然的な結果として、一部のサービス名は書き留める必要があり、使いやすさとセキュリティが低下します。

ソルティング手順は、より多くのEdgeケースに対応するために微妙に変更されているため、時間の経過とともにドリフトする可能性もあります。古いパスワードと互換性がなくなる可能性があります。

パスワードマネージャーはそのような手順を必要としません。

1つの接頭辞がすべてに当てはまるわけではありません。

パスワードポリシーはついに廃止されますが、まだ存在しており、多くの場合、無意味で矛盾しています。このスキームでは、すべての可能なケースをカバーするプレフィックスを前もって選択する必要があります。これはありそうもない、おそらく不可能です。

エッジケースでは、1つのサイトにのみ特別なプレフィックスが必要であり、書き留める必要があるため、使いやすさとセキュリティが低下します。

優れたパスワード生成プログラムは、ほとんどのポリシーに対応できます。そうでない場合は、生成されたパスワードを手動で変更できます。

安全に共有することはできません。

たとえば、一連のパスワードを共有したいとします。多分仕事またはプロジェクトのためにまたは家族と。

優れたパスワードマネージャーを使用して、3次キーを作成し、それらを配布して、最も重要なことに、それらを取り消すことができます。ボールトは、クラウドを介して、または単にコピーすることによって利用可能にすることができます。共有ボールトを作成して、共有するパスワードを選択できます。

このスキームでは、キー、プレフィックス、ハッシュアルゴリズムを共有し、ソルティング手順を説明する必要があります。受信者は、このシステムに限定されたこれらすべてのフープを進んで通過する必要があります。これを取り消すことはできません。将来のパスワードを含め、すべてのパスワードが公開されます。 1人がキーまたはプレフィックスを侵害すると、すべてが侵害されます。特定のパスワードのみを共有する場合は、新しいキーとプレフィックスを考え出して覚え、どのキーとプレフィックスでどのパスワードが生成されたかを覚えておく必要があります。

バックアップが難しい。

キーとプレフィックス、および特殊なソルトとハッシュアルゴリズムを安全な場所に保存できます。しかし、ますます複雑化する塩漬け手順の正確な説明を書き留める必要もあります。ドキュメントを読む人は誰でも、それがいかに難しいかを知っています。

優れたパスワードマネージャを使用すると、金庫のキーを安全な場所に保管し、金庫をバックアップできます。ボールトは暗号化されているため、どこにでもバックアップできます。

このハッシュベースの個人パスワードスキームはどの程度安全ですか？

覚えやすいパスワードをいくつか再利用するよりも安全です。優れたパスワードマネージャーやランダムに生成されたパスワードと比較すると、使用がはるかに難しく、機能が少なく、安全性がはるかに劣ります。

商用ソフトウェアにアレルギーがある場合は、オープンソースを使用してください。クラウドストレージを信頼しない場合は、ボールトをローカルに保存します。どこでも利用できるようにしたい場合は、保管庫とソフトウェアをキーホルダーのサムドライブに保存します。