パスワードマネージャがなくても安全であることは可能ですか?

私はパスワードマネージャが多数のオンラインアカウントを保護するための最良の方法であることを何千回も読んだことがありますが、その理由はよくわかっていると思います。実際には、1つ問題があります。理想的な解決策は現在存在しないということです。

パスワードマネージャが理想的ではない理由

1PasswordやDashlaneのような最もよく知られた「クラウド」PMは有料であり、私が持っている最も重要なデータの一部を備えた独自のクローズドソースシステムを信頼することを私に要求します。 LastPassは、クローズドソースの問題を除けば、非常に悪い、中途半端なUIを持っていて、前回試したときにバグがいっぱいで、そのインターフェースは私の言語に部分的にしか翻訳されていません。ブラウザを開いてLastPassエクステンションを開き、エントリを検索し、ユーザ名をコピーし、ウィンドウを切り替え、ペーストしてからパスワードを入力する必要があるため、ブラウザ以外のアプリケーションで使用するのも面倒です。最後に、私はそれを快適にするために発見された脆弱性についてあまりにも多く読んでいます、そして私は通常「無料」(無料のビールのように)クラウドストレージを信用しません。

それから私が知っている最高の解決策であるKeePassがあります。それに関する主な問題は、2つのデータベースを同期させることができるiOSに相当するものがないということです(それと互換性のあるiOSアプリは、リモートバージョンをローカルのもので上書きするだけです)。

いずれの場合も、パスワードデータベースを自分の携帯電話と同期させるには、独自のシステムを使用するか、または標準的なクラウドサービスを使用する必要があります。 1つのファイルだけを同期して、自分のデータをクラウドで利用できるようにしたくない場合は、暗号化されたKPデータベースであっても誰でもデータを読み取ることができます。

それらを置き換えるもの

これらすべての理由から、私は現在パスワードマネージャとして自分の脳を使うことに戻ろうとしています。私は本当に気にしているいくつかのアカウントのためのいくつかの合理的に安全なパスフレーズを思い出すことができ、私は推測するのがかなり難しく、異なるサイトに異なるパスワードを提供するパスワードスキームに取り組んでいます。これらは通常、ユーザーが覚えている秘密の値と、サイトの名前などのサイトに関する情報を組み合わせたものです。

私はこの方法を機能させることはできますが、たとえば、セキュリティがよくないWebサイトでパスワードが漏洩し、1つか2つの "セキュリティが低い"パスワードを分析してスキームを推測することができます。解決すべき主な問題は、時々いくつかのパスワードの漏洩に耐えながら、実用的になるのに十分簡単であるようなスキームを設計することにあるようです。

それが私の質問に私をもたらします。

17
@YdobEmos Lastpassは(少なくとも伝えられるところでは)クライアント側を暗号化するので、「私は喜んで自分のパスワードをすべて送信します」と記述するのは正確な方法ではありません。
追加された 著者 Joshua,
あなたが長いユニークなパスワードを使う限り、あなたは安全であるべきです。
追加された 著者 dandavis,
@everyone:有効(悲観的な場合)のポイント。変更不可能なパスワードの問題もあります。クライアント側の派生は、セキュリティの苦情を軽減することができます。 stckxchng (キーボードの左側にあるもの)の代わりに arxjzxgbf を使うような速記法も考えてください。前述のような標的型攻撃を防ぐために。
追加された 著者 dandavis,
@AaronFranke:どのように、あるいはむしろ誰によって盗まれたのですか?誰かがそれらを推測することができれば彼らはキーキャッチャーを使用しているに違いない。 38文字のパスワードをクラックする方法を知っているなら(MD5の後ろでさえ)あなたはそのようなパスワードがいくつかの非常に困難なリストに載って見つけられないでしょう...私達は話す必要があります!
追加された 著者 dandavis,
ええ、フレーズ内のいくつかの基本文字は、それを "塩"にドメインから子音を追加しました。たとえば、 this 1は英国です。 4 me 2 stckxchngで使う彼らは他のサイトのリークからのパターンを見つけることができません...
追加された 著者 dandavis,
@dandavis Ydobは、パスワードを保持するための40以上のサイトを持っていると述べています。それらすべてが安全であるとは限りません。ちょっと、ハッシングさえ邪魔しないと私が見た場所がまだあります...それに必要なのは、信頼できないサイト管理者数人だけです。
追加された 著者 AndrolGenhald,
私はパスワードカードと(多かれ少なかれ)決定論的だが推測しにくいものも使っていますパターンを決定する方法。
追加された 著者 Mehrdad,
私はmSecureを使っています。これはアップルのエコシステムに限定されていますが、デフォルトではローカルのみです。あるいは、DropboxやiCloudの暗号化されたファイルを介して同期を有効にした場合。
追加された 著者 Mehrdad,
iOSはあなたの専売のクローズドソースの不信から免除されていますか?
追加された 著者 Wing_Dinger,
問題はそれらをどのように覚えるかということです...私は最も重要なサイトに対してそれをすることができますが、私は全部で40以上のパスワードを覚えておく必要があります。そして、そのニーモニックは欠陥です。私は、安全なものを作ることが可能かどうかを主に尋ねています。
追加された 著者 Arno,
しかし、私はクライアントサイドの暗号化が適切に実装されていることを期待して、何らかの形でパスワードを送信します。それはクローズドソースであり、無視するよりも多くの脆弱性が発見されています。私は数年前、メタデータを暗号化することすら気にしていなかったので、すべてのサイト名はデータベース内で明確になっていました。おそらく真面目な警備会社で働いている誰かがそれをして、「ええ、私はそれが十分だと思う」と思うだろうということはばかげています。要するに、クライアントサイドの暗号化コードが公開されるまで、私はそれらを信用しません。
追加された 著者 Arno,
これには選択肢がありません。唯一の合理的な選択は、アップデートが混乱しているAndroidと、セキュリティをもう少し真剣に考えることが知られているiOSです。どちらも独自のコードでいっぱいです(AOSPが存在するという事実は、コンパイルされたバイナリがそれに由来するという意味ではありません)。その上、「私はすべてのパスワードをこの無料サービスに喜んで送ります、彼らがそれを正しく実装してこのデータを売らないことを願って」と「私はこのOSを使って私の個人情報を送らないことを信じます」の間に大きな飛躍があります背後の開発者へのデータ "#:。
追加された 著者 Arno,
@dandavisあまり安全ではありません。パターンを理解するために盗まれたパスワードをいくつか取るだけです。
追加された 著者 Ishan,
@dandavis MITM攻撃、またはパスワードを平文または単に暗号化して保存している悪意を持ってプログラムされたサイトによって盗まれた。アドビのような大企業でさえも、あなたが思う以上に起こります。 haveibeenpwned.com
追加された 著者 Ishan,
それらすべてを覚えていることができれば、そして確かに。
追加された 著者 Hugo Zink,

7 答え

Personally I have ~5 >= 12 character entirely random passwords memorised. These are used for key sites and the password is used between at most two sites and if reused then the two sites have different email addresses and usernames for me..

他のそれほど重要でないサイトのために私は3つのランダムな8文字の文字列+サイト名をマッピングします。たとえば、 "4QvkmvBt-StackExchange"と私は "4QvkmvBt-reddit"もあります。サイトをランダムな文字列にマッピングするための独自のスキーマがあります。私はまたパスワードポリシーが私がこれを使用することを可能にしないサイトと非常に気が狂います。個人的に私はこれを十分に安全だと考えています。あるサイトが危険にさらされていることに気付いた場合は、そのランダムな文字列を使用してすべてのパスワードを置き換えます。

個人的にはこれで十分です。パスワードマネージャが提供できるパスワードほど強力ではありませんが、便利でもあり(私の頭の中では常に利用可能です)、十分に優れています。サイトによって適切に保管されているならば、彼らは力ずくで不可能であるべきです。どういうわけか誰かが平文のパスワードを入手したならば、損害は限られています。また、誰かが私のアカウントに侵入するために平均以上の努力を払うと信じる理由もありません。

パスワードマネージャは、単一障害点であるため、嫌いです。脆弱性が発見された場合、主要なパスワードマネージャも、すべてマスターゲットになります。しかし、長いランダムな文字列を覚えていない人々のために私はまだそれらをお勧めします。

5
追加された
各パスワードクラスを使用したWebサイトのリストをどのように保存しますか? (そのランダムな文字列を使ってすべてのパスワードを置き換えるために必要です)
追加された 著者 Barend,
@AndrolGenhald実際にセキュリティが強化されていることもわかります。 md5ハッシュをパスワードリークから盲目的に解読している人にとっては、 4QvkmvBt は十分に高度なMD5クラッキングリグを解読できる範囲内ですが、 4QvkmvBt-StackExchange は長すぎます。
追加された 著者 Conor Mancone,
「個人的にはこれで十分です。」 - この部分は強調する価値があります。セキュリティの性質が「安全」や「安全でない」ことは決してありません。それは「私の目的のために十分な安全性」を備えたものです。リスクと利益を首尾一貫して考えた場合(そしてOPがそうであるように思われる場合)、セキュリティのバランスが取れた最終結果で個人的に問題ない限り、別の「安全性の低い」ルートをたどっても問題はありません。 、使いやすさなど
追加された 著者 Conor Mancone,
なぜ "-sitename"を付け加えたのか私は興味がありますが、私の頭の上にはそれに対する明確な利点はありません。
追加された 著者 AndrolGenhald,
@Ángel - 私はリストを保管していません。バックアップされたテキスト文書で十分ですが。私の一般的なルールは、私が覚えておくのに十分気にしていないサイトに私が漏れることを心配している少しの情報も置かないことです。
追加された 著者 Hector,
@AndrolGenhald - 侵害されているサイトへの保存が不十分な場合、自動化されたツールによって他のサイトに挿入されるのを防ぎます。それはまたハッシュに対するブルートフォースに対してそれらを改善します。ほとんどの攻撃者はデフォルトでそれをランダムな文字列に追加しようとはしません。したがって、理論的には実際には実際のセキュリティは追加されません。
追加された 著者 Hector,

私はあなたがパスワードマネージャの使用を破棄する必要がないかもしれないことを示唆することによって分岐します。

あなたは実際には技術的な問題を抱えているようです:iOSアプリがデータベースをインテリジェントに同期させることはできません。しかし、彼らはクラウドプロバイダーではない信頼できる場所にファイルをコピーすることができるようです(?)

いくつかの選択肢があります。

キーパスファイルを同期しない

デスクトップと携帯にあるすべてのパスワードが必要ですか。たぶん、あなたは別々のキーパスファイルを使ってできるでしょう。

機能を実装するためのアプリを入手

必要な知識、リソース、時間がある場合は自分で実装するか、他の人にそれを実行するように説得してください。それは単にバグレポートを開くこと/メーリングリストで問題を言及することからそれをするためだけに開発者を雇うことまで及ぶかもしれません。

しかし、一般的に、要求に賞金を添付することは助けになるはずです。

手動で同期する

パスワードをあまり頻繁に追加しない(読むのとは対照的に)ので、手動で実行することは可能です(不足しているエントリを手で入力するか、ファイルを正しい方向に移動することによって)。 。

携帯にのみエントリを追加

(あなたのkeepassアプリがリモートコピーが可能な場合)

モバイル版でのみ新しいパスワードを生成します。デスクトップは読み取り専用として機能します。したがって、常にマスターバージョンが存在するため、損失はありません。

デスクトップで同期する

(あなたのkeepassアプリがリモートコピーが可能な場合)

ローカルのキーパスを使用しているフォルダとは異なるフォルダにデスクトップに保存するには、モバイルアプリでファイルを同期させます。次に、デスクトップ上の2つのファイル間でスマート同期を起動します(iPhoneにコピーバックするか、より大きなデスクトップファイルで作業します)。必要に応じて「デーモン」を手動で実行できることに注意してください(したがって、バックグラウンドプロセスは節約されます)。

3
追加された

私はあなたに典型的なITの答えをあげる:それは依存する。それは何に依存しますか?セキュリティを確保するために耐えたい複雑さのレベル。

数年前のセキュリティ会議で、私は講演者が彼のパスワード手続きについて話すのを聞いた。彼がログインする各システムはそれ自身のパスワードを持っています。これらは30日ごとに変更され、彼は自分の金庫に紙にパスワードを保存します。これはおそらくパスワードを管理するための最も安全な方法です。しかし、PITA係数は本当に高いです。

Hector has a good scheme, but it has one failing—it lists the site in the password. Once a password gets compromised, a bad guy can figure out that algorithm and unravel the whole shootin' match.

覚えておいてください:あなたのパスワードが長ければ長いほど、ブルートフォースにかかる時間が長くなります。悪人がパスワードを推測しようとしている場合、文字を追加するたびに期間が指数関数的に長くなります。

優れた解決策は、多くのサイトで使用するパスワードを1つ設定することです。それから、金銭的価値があるものや価値のあるものはすべて、独自のパスワードを取得します。そのため、電子メール、銀行、投資の各アカウントには、それぞれ無関係で長いパスワードが異なります。それ以外のすべて(ベンダーのWebサイト、学校、ピザ店など)には「標準の」パスワードがあります。

3
追加された
@AndrolGenhald:壊れやすいアルゴリズムを使用しており、財務を含むすべてのサイトで使用されているように思われるので、私はそれを失敗と見なしています。そのシステムでは、ピザ店のパスワードを解読するとRedneckBankを試す可能性があります。私のシステムでは、ピザ店のパスワードをクラックしても、学校のポータルやその他の些細なWebサイトのパスワードは得られますが、私のEメールや銀行のパスワードは得られません。私は自分のシステムが完璧であるという幻想の下にいません。 :)
追加された 著者 baldPrussian,
「それは1つの失敗があります - それはパスワードでサイトをリストします」 - なぜこれは失敗ですか?これは、あまり重要でないサイトに単一のパスワードを再利用するというあなたの提案よりも悪くありません。
追加された 著者 AndrolGenhald,
彼は、重要なサイトには12文字以上の個別のパスワードを使用すると述べています。正直なところ、あなたの提案は私にはほとんど同じであるように思われます、彼はちょうど彼がパスワードをどうやって思いつくかについてもっと詳細に入ります。
追加された 著者 AndrolGenhald,
@baldPrussian - すべての銀行サイトおよび重要なアカウントには、12文字以上の専用パスワードがあります。これらは、アクセスがあったとしてもイムが煩わしくないサイト用です。例えば、誰かが私の評判をここで捨てるならば、最悪の場合、私はそれを私の履歴書から取り除きます。
追加された 著者 Hector,

https://lesspass.com/ などのステートレス(またはボールトレス)のパスワードマネージャを使用できます。基本的にそれはあなたが手動でしていたことをします(それは function(master_password、website_name)としてパスワードを生成します)、ただ今回は function が連結ではなく安全なハッシュ関数です。

Webサイトごとの「カウンタ」トークンを使用することで、同じWebサイトのパスワードを変更できます。

これはあなたの懸念を解決すると思います。

3
追加された
「カウンタ」トークンのデータベース、および各Webサイトで使用できる文字のリスト(したがって、アカウントを所有しているWebサイトのリスト)はどこに保存しますか。元の問題に戻りました。あなたのファイルで暗号化されたストレージを持つパスワードマネージャの場合、彼らがあなたのマスターパスワードを推測するのであれば(他に何もすることなく)、彼らはあなたのすべてのパスワードを取得するでしょう。他のサイトからのダンプからパスワードを見つけることができれば、それが彼らがあなたのマスターPWを攻撃するのに使用できる情報であるという追加の脆弱性を伴う、「ボールトレス」PWマネージャにも同じことが言えます。
追加された 著者 Ben,
それが私の主張です。あなたのPW DBもローカルに保存することができます。 2.「金庫のない」システムによる追加のセキュリティはありません。 3.「ボールトレス」システムからのさらなるセキュリティ。せいぜい、それは洗浄です。追加された(ありそうもない)攻撃面で、漏洩したパスワードからあなたのマスターパスワードを推測することができますが、これは従来のPWマネージャでは理論的にさえ不可能です。
追加された 著者 Ben,
@ el.pescadoここでいう「ステートレス」とは、厳密にはコンピュータ科学者が期待することを意味するのではないとあなたに同意します。 "vaultless"はもっとふさわしい名前です。 Lesspassには、サイトごとの長さと文字セットを設定する設定があります。ハッシュ関数を調整するためのコードを書く必要はありません。上の図を参照してください。たとえあなたがこの「状態」を同期しなくても、「金庫のないもので、あなたはちょうど同じ方法でいくつかの設定を再設定しなければなりません。
追加された 著者 Joshua,
1.ボールトベースのパスワードマネージャで、DBをローカルに保存する場合は、すべてのデバイスでパスワードを手動で同期する必要があります。金庫のないものでは、同じ方法でいくつかの設定を再設定する必要があります。手でやる方がずっと簡単です。 2、3。私は同意する:ボールトレスパスワードマネージャはボールトベースよりも安全性が低く、より安全ではない。 OPはセキュリティではなく、利便性(同期のしやすさ)を重視するように思われるので、(私は自分では使用しません)1つをお勧めします。
追加された 著者 Joshua,
@ベン1。地元で。同期しないようにすることができます。それらは単に便宜上保存されています。 2.はい、彼らがあなたのマスターパスワードを見つけたならばあなたはねじ込まれています。これは世界中のすべての暗号化システムに当てはまります(私たちが議論していなかった他の「1つのバスケットにすべての卵」問題がある2要素認証は別として)。 3.あなたがあなたのマスターパスワードとして安全でないパスワードを使用するなら、暗号化の量はあなたを救うことができません---上記を見てください。
追加された 著者 Joshua,
サイトごとにパスワード要件が異なるため、ステートレスソリューションにはユーザビリティの問題があります。サイトAとは特殊文字を使用する必要があり、サイトBでは文字と数字のみが許可されていますか。最小/最大長の要件はどうですか?サイトごとにハッシュ関数を調整する必要があります。これはステートレスを無効にします。
追加された 著者 Poiera,

パスワードマネージャとクラウドストレージの代わりに、ブックマークレットで次のようなものを使用します。

これを新しいブックマークのURLに貼り付け、貼り付け後にsalt(123456789)を編集します。

javascript:function s2a(s)%7Bvar a=new Uint8Array(s.length);s.split('').forEach((x,y)=>a%5By%5D=x.charCodeAt(0));return a;%7Dfunction a2s(a)%7Breturn%5B%5D.slice.call(new Uint8Array(a)).map(x=>x.toString(16)).join('');%7Dcrypto.subtle.digest('SHA-256',s2a('123456789'+location.host)).then(a2s).then(function(r)%7Bprompt(location.host,btoa(r).slice(2,22))%7D);void(0);

もう少し読みやすいコード(JS、[F12]開発者ツールからコンソールで実行):

function s2a(s) {
    var a = new Uint8Array(s.length);
    s.split('').forEach((x, y) => a[y] = x.charCodeAt(0));
    return a;
}
function a2s(a) {
    return [].slice.call(new Uint8Array(a)).map(x => x.toString(16)).join('');
}
crypto.subtle.digest('SHA-256', s2a('this is MY [email protected], use yer 0wn' + location.host))
    .then(a2s)
    .then(function(r) {
        prompt(location.host, btoa(r).slice(2, 22))
    }
);

このサイトで実行すると、 c5ODI5NDMzMzQxNzRlZG がコピー可能なプロンプトインターフェイスで提供されます。

これは、ユーザー定義のsaltとサイトのドメインを使用してhttpsサイトでクライアント側のハッシュを実行します。たとえ上手な塩であれば、攻撃者が上のコードが使用されたことを知っていても、元に戻すことは不可能であるはずです。サイトごとに異なり、サイト間の関連付けは事実上不可能です。

あなたがこの道をたどる場合、あるいはソースコードがあなたの式を明らかにしないようにするためにあるユーザ提供のsaltに対して prompt()をしなければならないなら、あなたはおそらくあなたのブックマークを同期するべきではありません。

これらの種類の自己定義パスワードの派生は安全ですが、大きな欠点が1つあります。1つのパスワードを変更せずに変更することはできないということです。それは不完全な選択肢の分野における単なる別の選択肢なので、私はそれをそこに出したいと思った。

1
追加された
@エミール:私はそれがパスワード全体を作り出すことを提案していました、しかしあなたはもう一つの攻撃の角度を持ち出します。
追加された 著者 dandavis,
私は混乱しています:あなたは記憶したパスワードに派生文字列を追加することを提案していますか?もしそうなら、あなたはおそらくそれを言及する必要があります!
追加された 著者 PAK-9,

イントロ

私は実際にこのことについて私自身しばらくの間考えていました、そして、私はパスワードマネージャを使うことがパスワードセキュリティのために理想的でないことに同意します。

  1. Because it イントロduces a single point of failure, which in my book is too great a risk. I don't want to entrust a third party with my security, or place the weight of security for all my accounts onto the strength of one password.
  2. Because you either need to store your passwords in the cloud which is potentially accessible to everyone, or keep local copies and run the risk of losing the data and access to all of your sites with it.

私が考え出すことができる最善の解決策は、すでにいくつかの異なる答えで言及されているものです:パスワードを生成するためのアルゴリズムの使用。それは以前に言及されましたが、私は他の答えのどれもまだこの方法の良い実装を全く提供していない、そしてそれらがいくつかの注目すべき点に触れていないと感じます。

ハッシュ/暗号化を使用してパスワードを生成する

安全なパスワード生成アルゴリズムは3つのことをするべきです:

  1. 安全なパスワードを生成する
  2. ユーザーが自分のパスワードを簡単に取得できるようにする
  3. 最初の入力なしでは非効率的に元に戻せる

だから、これに対する私の解決策は、次の一般化されたアルゴリズムを通してあなたのパスワードを実行することでしょう:

ENCODE(HASH("password" + "salt"))

私の理想的な提案は次のものを使うことです。

Base85(SHA3-512("password" + "salt"))

基本的に、あなたのパスワードはまずハッシュアルゴリズムを通して実行され、ランダムで不可逆的な出力を生成します(この例では SHA3-512 )、そしてエンコードしてパスワードに広範囲の文字値を与えることでハッシュクラッキング(ここではを選択しました) Base85 )。
私はあなたがログインしようとしているサイトのベースドメインとしてパスワードを設定し、あなたの「パスワード」としてsaltを設定することをお勧めします。

具体的な例:

Base85(SHA3-512("security.stackexchange.com" + "MyPassword"))

文字列 "security.stackexchange.comMyPassword" に対するSHA3-512の実行 ゆき

8b6fe2cfd65d5faf4f3babe823afa844a9eb9c36dc6c1459b0f430a0f77318052318ce6b607eab0114f990aa52bb2a7acd06735f8590c2886bbc68ca42d05328

そしてBase85を介してこれを実行した後にあなたが得る

<~3+=dXAMRb-A2Z;U2.g9/[email protected]:Ee-1,[email protected])#@6%n.3Faj'[email protected]5kAiDY)0fUjE1,[email protected]@[email protected]([email protected]:CoF0f3K&3A=lM2)8WM11<[email protected]`!='3&N][email protected]#'2I^-*2E52T1brSq2)@!I~>

私はあなたが上記のパスワードが強力なものであると主張することができると思います、そしてあなたがしなければならないのは「MyPassword」を覚えていることだけです。

私の例を変える

明らかに、この概念は任意のハッシングアルゴリズムと符号化方式、そしてあなたが入力として望むどんなパターンにも適用することができます。しかし、注意してください、あなたが生成したパスワードの安全性はあなたがそのアルゴリズムのために選んだもの(そしてあなたのベースパスワード!)に依存します。注意すべき点がいくつかあります。

  • When it comes to hashing, hashing twice doesn't really add to the security of the password. If you use two different hash algorithms, in theory the resulting hash is only as secure as the weakest one in the chain. Take SHA1(MD5("pass")) for example. MD5() produces a 128 bit hash, where as SHA1() produces a hash of 160 bits. By doing this, you are essentially mapping 2128 inputs onto 2160 outputs. By theory of the pigeonhole principle, at a maximum this algorithm can only generate 2128 possible outputs, which undermines the security of SHA1().
    The same result occurs with MD5(SHA1("pass")), but what about SHA1(SHA1("pass"))? By using SHA1() twice, you are mapping 2160 inputs onto 2160 outputs, which theoretically should be fine, but in practice it is not because of hash collisions. Any two strings A and B that collide on SHA1() will collide on SHA1(SHA1()). Furthermore, two unique hashes SHA1("C") and SHA1("D") may collide on SHA1()! This means that not only will SHA1() output <2160, but it will also have roughly twice the chance at forming hash collisions.
    TL;DR hashing a string twice only weakens the security of that hash, because instead of mapping ∞ onto n bits you are mapping <�∞ onto n bits.
  • You could exchange a hashing function for an encryption function, but I would argue that this wouldn't increase the security of the algorithm at all. If we assume both the encryption function E() and the hashing function H() are equally secure, then they're essentially doing the same thing: On one hand E() is using the string "MyPassword" as a key to encrypt the domain "security.stackexchange.com" while on the other hand H() is using "MyPassword" to salt and hash the domain.
    I want to put a disclaimer here that I am well aware of the difference between encryption and hashing. They are two separate types of string permutation, but in the context of generating a password they are essentially the same. If you don't know the difference between hashing and encryption, you can learn more here, and this is another interesting, related article.
  • Changing the encoding is a possibility, but I think Base85 is that sweet spot. If you go with something lower like Base64 (or any encoding scheme that generates output from a smaller pool of characters) you're only making your passwords weaker. You could increase the encoding past Base85, but eventually you start to hit outputs with non-printable characters and issues would arise from there.
    One issue with encoding is that there are sites that actually limit the length and what you're allowed to input for passwords. This is utterly ridiculous because the only thing you should be doing with a user password is hashing it down to a fixed length and storing it. Password fields shouldn't offer any sort of vector for attack, not even SQL Injection because the data should be hashed before it even touches a query. Alas, there are sites out there that restrict password field inputs, so in rare cases Base85 might not work universally.
  • Lastly, it's completely acceptable to use multiple passwords for this solution, and even different Hashing/Encryption algorithms for different sites. If you choose 3 strong passwords and 3 strong Hashing algorithms, you now have 9 generators to draw from! Of course, if you extrapolate too much then you'll find yourself with the exact same problem this method aims to solve, but I believe there is a happy medium to this.
    Perhaps create 3 base passwords to insert into this algorithm, one for sites you don't care about, another for sites you partially care about, and a third for sites with sensitive information on them. Or you could do the same but with different Hashing/Encryption algorithms. The world is your oyster here, as long as you can remember them all, the more the merrier.

この方法の安全性

理論的には、このアルゴリズムを使用してパスワードを生成することは、そもそもあなたのパスワードを使用することよりも安全ではありません。これは、攻撃者があなたのベースパスワード( "MyPassword" )を見逃していて、そのアルゴリズムが公開されている(この方法が普及するためにはそれが必要である)と仮定すれば何も止まらないため訪問した各サイトのパスワードを生成していません。

しかし実際には、私はこの方法を IS より安全であると主張するでしょう。あなたはそれをいくつかの異なる攻撃ベクトルから見ることができます。

Database Breach
If an attacker were to breach a database and collect the stored password hashes, his only route of attack would be to crack them. Brute force would take too long and a Mask Attack wouldn't reasonably succeed either with the Base85 encoding.
If the passwords weren't hashed (pray for that DB Admin) then the attacker could easily decode the Base85 encoding. But then all he'd be left with is a hash. Although he wouldn't need to crack this hash (or even strip the encoding) to login as you on that site, he wouldn't gain access to any of your other accounts without first discovering your base password.

Man In The Middle Attack
Ultimately, the hashed and encoded password you generate is being sent over the wire to the website. Hopefully that site uses HTTPS, but not all of them do. If an eavesdropper is sitting on your connection and they manage to read this password they can login as you, but like mentioned above it will only be for that site. Without your base password the eavesdropper will have no way to access your other accounts. This is a better outcome than if you didn't generate passwords, because in that case the eavesdropper could login to any account in which you've used the same username/password combo.

Brute Force/Mask Attack
If a malicious actor is attempting to brute force your base password, then your generated passwords will be no more secure than using a regular, non-generated password (assuming the actor knows the algorithm you used to generate those passwords). In this case generating passwords doesn't add any extra security, but it doesn't diminish the security at all either. This attack vector requires you as an individual to be targeted as well, which in practice is much less likely to happen than the above methods. That said, it's still possible, so make sure to choose a secure base password.

Uncovering Your Base Password
As it stands, the ONLY way an attacker could generate the passwords for all of your sites is if they knew your base password. There are only two ways they can get this (without you directly telling them).

  1. 生成されたベースパスワードのハッシュを解読する
  2. 基本パスワードが見つかるまで、あなたのアルゴリズムをブルートフォースします。

まず最初に、#1を試みることによってあなたは実際に#2を使っています。ハッシュをクラックするための最も効率的な方法は強引なので、これらは本質的に同じものですが、わずかな違いがあります。

安全な基本パスワードを選択している限り、これらの方法はどちらも不可能に近いはずです。これは、攻撃者があなたのすべてのアカウントにアクセスするためにあなたの正確な基本パスワードを考え出す必要があるためです。攻撃者があなたの正確な基本パスワードを使って初めてあなたの他のパスワードを正しく生成できるのは、ハッシュ衝突がここでも要因になりません。

さらに説明すると、生成したパスワードがP1であり、P1 = G(S_1)およびS_1 </であるとします。 u = p + s 1(G =生成アルゴリズム、p =ベースパスワードストリング、s 1 =塩)。攻撃者がP 1 を入手し、P 1 = G(S 1 ')となるようなS'を発見した場合)ならば、S '1はS <1>に等しくなければ、攻撃者はあなたの他のアカウントにアクセスすることはできないでしょう。 S 1 'がP 1に評価されるからといって、S 1'がP 2に評価されるわけではありません。 P 2 = G(p + s 2)である。

うまくいけば、私はその説明で誰も失うことはありませんでした。

アウトトロ

OPの質問に具体的に答えるには:

このような優れたパスワードスキームを作成することは可能ですか?

私が私の投稿で概説した方法は十分に良いパスワード体系であると思います。それはあなたがあなたがアカウントを持っているすべてのサイトのためにあなたにユニークで強いパスワードをあなたに与えますすべての言われたパスワードを個々に覚えるためにあなたの頭脳に負担をかけることなく。覚えておく必要があるのは、使用したアルゴリズムと基本パスワードだけです。

この方法では、適切に設計されたパスワードマネージャに比べればそれほど劣らないセキュリティが提供されますか?

最悪の場合、私が指定した方法は通常のパスワードを使用するのと同様に安全であり、それらを保存するためのPMです。

  • PMを使用する場合、基本的にすべてのサイトの各(パスワード、Webサイト)ペアを単一のキーで暗号化しています。このキーを使用すると、自分のすべてのアカウントにアクセスできます。
  • パスワードを生成するときは、各パスワードを暗号化(またはハッシュ)して、そのパスワードを取得する唯一の方法はキーを知ることです。このキーを使用すると、自分のすべてのアカウントにアクセスできます。

ただし、最強の方法では、この方法はパスワードマネージャよりももっと安全であると合理的に言えます。つまり、基本パスワードを安全に保つように他人に委任していないからです。あなたが信頼しなければならない唯一のことはあなたの脳です、そしてあなたが夢中にならない限り、それはそうすることはそんなに恐ろしいことではありません。 :)

PS: If there are any oversights to my solution or extra tidbits that anyone thinks I should add, please comment and let me know. I would be happy to improve this answer by editing in any valid points you guys come up with.

1
追加された
実際に、あなたがハッキングしたデータベースがパスワードを不正使用した場合、User1のパスワードをクラックしても他のユーザーのパスワードは得られません。あなたは、同じsaltと同じパスワードを使っている他のユーザーをクラックしただけです。一方、 "ボールトレス"のパスワードマネージャは、あるソルトを設定ファイルに保存したくなければソルトを使うことができません。
追加された 著者 Ben,
Lesspassを使った私の解決策には同じ弱点があります(コメントに記されているとおり)。通常のパスワードマネージャはそれを持っていません、なぜなら彼らは彼らのデータベースにユーザごとの 'エントロピー'を含んでいるからです。特定のウェブサイトでKeepassなどのすべてのユーザーに対して同時にマスターパスワードをテストすることはできません。したがって、あなたの提案は単一のパスワードよりも安全ですが、通常のパスワードマネージャよりも安全性が低くなります。
追加された 著者 Joshua,
これは私の回答および dandavisの1つ。これはボールトストレージの問題を解決しますが、主な弱点はベンのコメント:1つの危険にさらされたWebサイトのハッシュされたパスワードを考えると、メインのパスワードを非常に効果的にブルートフォースすることを試みることができます。
追加された 著者 Joshua,
私が書いたことは、ユーザーの観点からは真実です。しかしそれでも弱点です。攻撃者の視点から見てください。妥協したwebsite.comのパスワードDBを取得しました。 Base85(SHA3-512( "defeisedwebsite.com" + "MyPassword"))を計算し、それがデータベースのパスワードと一致するかどうかを確認します。これで、マスターパスワードがMyPasswordの全員がハッキングされました。今、あなたは彼らの銀行口座のパスワードも知っています。ビンゴ!
追加された 著者 Joshua,
どちらがより安全に見えますか?シナリオ1(Keepass):Dropboxの所有者(あるいは誰かがそれらをハックする者)があなたのボールトファイルを盗んであなたのマスターパスワードを強引に試みることができます。成功すれば、彼らはあなたのパスワードをすべて持っている。シナリオ2(FRZpass):あなたがアカウントを持っているすべてのゴミサイトの所有者(あるいは誰かがそれらをハックする)はあなたのマスターパスワードをブルートフォースすることを試みることができます。 。成功すると、彼らはあなたのパスワードをすべて 持っています。ボーナス:彼らはすべてのFRZpassユーザーに同時にそれをすることができます。
追加された 著者 Joshua,
また、サーバーに送信する前にパスワードを変更することは、パスワードを変更することとまったく同じです。あなたがそれを "塩"にしたい場合は、(私が示唆したように)思い出に残る "塩"を使用することによって設定ファイルを避けることができます。 「ブルートフォース/マスクアタック」と「ベースパスワードの発見」のセクションも見てください。私はすでにこの問題に対処しました。そして、投票者はなぜ投票しなかったのかコメントしてください。
追加された 著者 Clint S Collins,
かなりありません。例1で、User1が自分のパスワードとして "MyPassword"を入力し、test.comで同じユーザー名とパスワードを使用した場合、test.comのフォームに "User1"と "MyPassword"を入力すると、両方のサイトで異なる塩を使用していても、ログインは完了します。ハッシュ化したときに "MyPassword"と衝突する文字列を見つけた場合、あなたの言っていることは真実ですが、攻撃者が前回のコメントでユーザーの実際のパスワードを見つけたことを意味します。また、ユーザー名なしのパスワードは技術的に価値がないことを示すための単なる例です。
追加された 著者 Clint S Collins,
あなたが言っているのは、パスワード生成の没落ではなく、一般にパスワードの没落です。このように考えてみましょう。私はデータベースをハックしてUser1のパスワードをクラックし、それが "MyPassword"であることを発見しました。技術的には、パスワード「MyPassword」を使用している世界中の他のすべてのアカウントにアクセスできるようになりました。しかし、私は彼らのユーザー名を知っていますか、それともどのアカウントがこのパスワードを使っていますか?いいえ。他のどのアカウントがどのパスワードを使用しているのかを判断することで(仮にあったとしても)、すべてのアカウントを個々に強制的にブルートフォースします。この脆弱性は、どのパスワードスキームにもほとんど存在しません(PMパスワードも)。
追加された 著者 Clint S Collins,
また、生成に対するPMのセキュリティには多くの要素があるため、パスワードの生成がPMよりも劣っているとは言えません。 1つには、それは問題のPMとジェネレータに依存します。また、パスワードが金庫に安全に保管されているからといって、それが優れたパスワードであるとは限らないことも考慮する必要があります。私(およびあなた)が提案したようなパスワード生成スキームは、生成されたパスワードが非常に強力であることを保証します。ジェネレータを使用すると、パスワードをオンラインにして第三者に委任する危険性もなくなります。代わりに、自分自身を信頼するだけで済みます。
追加された 著者 Clint S Collins,
さて、私はあなたが言っていることを見ますが、私はそれがPMより安全ではないとは思わないでしょう。攻撃者がすべてのユーザーのパスワードをテストできるというあなたの提案は、各ユーザーがまったく同じアルゴリズムでパスワードを生成するという仮定の下でのみ真実です。理論的にはあなたの主張は有効ですが、実際には(特に大多数の人はパスワードを生成していないので)あなたを特にターゲットにせずに強引なパスワード生成を試みることはありません。そして、泥棒があなたを特に標的としている場合、あなたがそれを使用したならば、彼らはちょうどPMのためのあなたのユーザー名/パスワードの後に​​行くことができました。
追加された 著者 Clint S Collins,
そう、そして私はすでに私の答えの中でこれに対処しました。私はあなたがここに着いているものを見ません。その攻撃経路をたどることによってあなたの生成されたパスワードはただ普通のパスワードを使うより安全ではないでしょう。攻撃者がPMをブルートフォースしようとした場合も同様です。マスターパスワードが "MyPassword"であることを彼らが発見した場合、彼らは今あなたのすべてのアカウントにアクセスすることができます。 LessPassによるあなたの解決策は、この同じ弱点の犠牲にもなります。
追加された 著者 Clint S Collins,
実際には、あなたは実際にあなたの3番目のポイントで弱ベースパスワードの問題にすでに対処しています。こちら
追加された 著者 Clint S Collins,
今、あなたが「1つの危殆化したWebサイトのためにあなたのハッシュされたパスワードを与えられた」と言うとき、攻撃者は「あなたのメインパスワードを非常に効果的にブルートフォースする」ことができます。少なくとも効果的に、または効率的に。これについては、「このメソッドのセキュリティ」のセクションで既に説明しました。これがまさに私がSHA3-512または少なくとも同等の安全なハッシュアルゴリズムを使用して、ブルートフォース攻撃の可能性をできるだけ少なくすることを提案し、それでも安全なベースパスワードまたはこのプロセス全体を選択する必要があると述べた理由です。無意味です。
追加された 著者 Clint S Collins,
そう、この答えは他の答えが以前に述べた解決策を説明します、しかし私は他の答えのどれも全く適切ではないかのように感じたので私はこれを書きました。あなたの答えの中であなたはlesspassを使用する解決策を提供しました、それは良い選択ですが、あなたはパスワード生成方法について詳細に説明したり、パスワード生成を使用することの安全性について全く議論しませんでした。 Dandavisは私達に走らせるためのスクリプトをくれました、しかし彼はまたPMを使うことに対する生成の安全性に触れませんでした。彼の答えはコードが説明の仕事の​​大部分をすることを可能にしました、そしてあなたはその方法でただ一つのパスワードを変えることはできません。
追加された 著者 Clint S Collins,

TLDR

各サイトに異なるマスターパスワードを使用して、ステートレスパスワード管理を使用します。


Let's go into detail

他の回答で提案されているステートレスなパスワード管理方法には1つの大きな欠陥があります。あなたのマスターパスワードを知っている人がすべてのサイトのパスワードを生成することができる場合です。サイトごとに異なるマスターパスワードを使用することで解決できます。

マスターパスワードのリストは、次のようにして保存することができます。

  1. 2つのリストを作成します。1つはサイトをリストし、もう1つはパスワードをマスターにします。
  2. 数値コードを使用してそれらをリンクします。たとえば、リスト1に 1234 - Stack Exchange 、リスト2に 1234 - secretmaster が含まれます。
  3. 複数のデバイスにまたがってリストにアクセスするには、Two Factor認証を使用して2つの異なるクラウドストレージを使用します。

あるいは、単一のリストを使用することもできます。使いやすさとセキュリティの間のトレードオフです。あなたに最適なものを選択してください。

私はまた時々サイトのマスターパスワードそしてそれによって実際のパスワードを変えることを推薦する。


この方法のセキュリティ

他の方法と同様に、これは100%安全というわけではありませんが、それは前の提案に対する改善です。

  1. 権限のない人が異なるクラウドプロバイダから2つのリストを取得し、それらを互いにリンクすることはほとんどあり得ません。
  2. 2つのリストを取得しても、サイトのパスワードを作成するために使用しているアルゴリズムがわかりません。
  3. この方法で、単一のサイトのパスワードを変更しても、そのサイトのマスターパスワードを変更してアルゴリズムを使用することができます。以前の方法では、マスターパスワードの変更はすべてのサイトに影響します。
0
追加された