自分のパスワードマネージャーをプログラミングするためのヒントはありますか？
私は主に、回避すべきことやこれを行う際に何を考えるべきかについてあなたが私に与えることができるあらゆる助けと提案を望んでいます。
私は合理的なプログラマーであり、自分のパスワードを保持するための独自のプログラムを作成したいと思っています。
既存のパスワードマネージャを使用しないのはなぜですか？
- 自分で作りたい。
- 彼らのコードが私のパスワードに対して何をしているのかわからないので、私は本当に彼らを信用していません（たぶんそれはそれらを中央サーバーに保存しているのでしょうか？...いいえ！）
私は銀行レベルのセキュリティを目指していませんが、できる限り安全にするように努めますが、暗号化されていないテキストファイルにパスワードを保存する人にとっては、明らかなアップグレードになるはずです。 ）（低く目指して、失望を避けてください）。
私は Automate と呼ばれるモバイルプログラミング用の「言語」を使用しています。これは、プログラムがオープンソースになることを意味します。そのため、誰もがそれらを表示および変更できるため、完全に安全にすることは不可能だと思いますローカルバージョンのコード（ただし、セキュリティを危険にさらすにはコードと他の誰かの保存ファイルの両方が必要であり、現実的にはすべてのセキュリティプログラムですでにゲームオーバーです）。
Automateを使用すると、私は豪華なライブラリやものにアクセスできなくなりますが、変数、リスト、辞書、ループ、ifステートメント、一部の組み込み関数（ これは使用可能なすべての関数のリスト ）。
いくつかの関数の例：テキストをバイナリに変換し、utf-8テキストをsha1（160ビット）またはmd5（128ビット）ハッシュに変換します。そして、テキストの再エンコードを必要なだけ行うことができます。次のような別の形式にする文字列：
utf-8 --> sha1 --> hex -->md5 --> binary --> sha1 again
文字操作もできるので、文字列を取り、各文字を抽出できます。そのcharのunicode-valueにいくらかのammountを追加して、次のようなことができるようにします。
string value_1 = "abc";
string value_2 = "def";
// assuming equal length strings for simplicity.
for( int index= 0; index < value_1.length(); index++ ){
string encoded = char( value_1[ index ] + value_2[ index ] ); // e=(a+d) at index 0
}
print( encoded ); // outputs: egi
「あいまいさによるセキュリティ」は悪い考えだと知っています（そのため、ここで質問します）が、他に何ができますか？
テキストをある程度安全にテキストファイルに保存し、後でデコードしてテキストを読み取ることができるように（できれば所有者のみが）、テキストをエンコードする "最善の"方法は何ですか。
他にどのようなヒントと提案がありますか？
しないでください。あなたはトピックの理解の欠如を示しています。
彼らのコードが私のパスワードに対して何をしているのかわからないので、私は本当に彼らを信用していません（たぶんそれはそれらを中央サーバーに保存しているのでしょうか？...いいえ！）
ソースを読んでください。例えば Keepass はオープンソースです。あなたはそれがどのように機能するか、そしてそれが何かを送信するかどうかを確認できます。
私は銀行レベルのセキュリティを目指していませんが、できる限り安全にするように努めますが、暗号化されていないテキストファイルにパスワードを保存する人にとっては、明らかに明らかなアップグレードになるはずです（低くして失望しないようにしてください）。
誤った安心感は、安心感よりも悪い場合があります。クリアテキストファイルであることがわかっている場合は、そのように扱います。安全に暗号化されていると確信している場合-実際にはそうではありません-妥協する可能性があります。
「残念ながら」Automateと呼ばれるモバイルプログラミングに「言語」を使用しています。つまり、プログラムはオープンソースになるため、誰でもローカルバージョンのコードを表示および変更できるため、完全に安全にすることは不可能です（ただし、セキュリティを危険にさらすためには、コードと他の誰かの保存ファイルの両方が必要であり、現実的には、それはすべてのセキュリティプログラムですでにゲームオーバーです。
Kerchoffs原理 について読んでください。要するに、あなたのスキームの唯一の秘密は暗号化キーであるべきです。攻撃者は暗号化の仕組みを正確に知っていると想定します。
使用する言語に関係なく、アプリの動作を理解することができます。 Javaを使用すると、Cの方が多少難しくなります。
自動化を使用すると、私は豪華なライブラリやものにアクセスできなくなりますが、変数、リスト、辞書、ループ、ifステートメント、一部の組み込み関数などの非常に基本的なものに依存する必要があります（使用可能なすべてのリストを以下に示します）関数）。
最初にこれを行う場合は、確立された暗号ライブラリで構築してください。なんらかのばかげた間違いによって強固な暗号化のように見えるものを破る可能性は非常に大きく、歴史は暗号の破綻で散らかされています。
シュナイアーの法則 も忘れないでください：
最も無知なアマチュアから最高の暗号学者まで、誰でも彼自身が破ることができないアルゴリズムを作成できます。
情報開示：私は1Passwordのダークアーツに対するチーフディフェンダーです。
この時点であなたがしようとしないようにします。他の人が指摘したように、（学習のこの時点で）主要な概念を理解できないという基本的な失敗は、パスワードマネージャーの設計における難しい質問に直面する立場にないことを意味します。私はこれを侮辱として意味するのではありません。特定のことを知らなくても恥はありません。
既存のシステムを使用する
信頼できるパスワードマネージャーを作成することが目標である場合は、詳細を知っていて、公の監視を受けているシステムを作成した人が作成したものを使用するほうがよいでしょう。独自に開発しても、現在利用可能な多くのシステム（オープンソースまたは商用）よりも安全なものは提供されません。セキュリティ上の懸念の多くは、特定のシステムを安全にする理由に関する知識の欠如を反映しています。
ただし、自分で作成するために自分で作成することが目標である場合は、以下をお読みください。次の手順を順番に実行します。
最初に：暗号の基本を学びます
まず、暗号化をよりよく理解する必要があります。非常に優れた暗号化入門のオンラインコースがあります。私があなたの出発点で誰かにお勧めする本はSerious Cryptographyとです 暗号化について。これらの本は教えていないので、安全なパスワードマネージャの構築に必要な種類の暗号設計の選択を始めることができるように十分に教えてくれます決定する必要がある根本的な決定の多くに十分深く入り込まないでください。しかし、どこかから始める必要があります。
2番目：既存のパスワードマネージャーの設計を調査する
他の人が述べたように KeePass は尊敬されオープンソースであり、おそらくセキュリティ設計の決定の多くは十分に文書化されています（私は見ていません）。KeePass1のデータ形式にも注意してください。 .xは約20年前に設計されたものであり、その時代は進んでいましたが、今日構築しているものについてはKeePass 2.xを参照する必要があります。
1Passwordの現在のセキュリティ設計文書 （OK、私はあなたをそこに指摘しただけです）を示す代わりに、あなたのニーズを超える機能を共有することを含むので、 当社のOPVaultデータ形式の設計 、2012年に導入されました。これは置き換えられましたが、おそらく必要なものに最も近く、はるかに単純です。
別の、より単純な、オープンソースのパスワードマネージャーは pass です。それは素晴らしくシンプルなデザインで、暗号化をPGPに渡し、同期をgitに渡します。 （その単純さの犠牲は、大量の機密メタデータが暗号化されないままであることです。）プログラムがGnuPG/PGPなどのよく吟味されたファイル暗号化ツールを使用するだけの設計を探すことは価値があるかもしれません。
最初に暗号化の非常に基本的なものをよりよく理解するまでは、これらを学ぶことはあまり役に立ちません。したがって、これらの手順を順番に実行してください。理解できないことをモデル化しようとしないでください。そうすることは、より多くの混乱につながるだけです。
第三：それを最初の実験的な試みをしてください
暗号化と安全なコーディング手法を十分に理解している人を含む多くの人々は、パスワードマネージャーを正しく取得することの難しさを過小評価しています。ただし、最初の2つのステップが完了したら、試してみてください。
比較的1台のマシンにのみ存在するデータ用のパスワードマネージャを開発するのは簡単です（ただし、思っているよりも難しいです）。しかし、複数のデバイス間でデータを同期することが望ましい特性になると、設計の他のほぼすべての側面に影響を与えます。これは試してはいけない理由ではありません（基本的な知識とスキルを身につけたら）。しかし、膨大な量の作業をせずに、開発者以外の人が安全で使用できるものを開発することを期待しないでください。
したがって、この最初の試みを破棄する準備をしてください。安全なパスワードマネージャーを開発する際に直面する問題をよりよく理解できるようにすることが目的です。
また、ソフトウェア開発言語の選択は、たまたま知っている言語ではなく、タスクによって行われるべきであることを理解する必要があります。自動化は、ジョブに適したツールではないようです。
4番目：パスワードマネージャーのセキュリティを調査する
さまざまなパスワードマネージャのセキュリティプロパティに関する学術文献が増えています。 Usenix SecurityまたはACM CCSで提示されるパスワードマネージャーに関するいくつかの論文が常にあります。しかし、学術論文を読むスキルを習得する必要があります。
このプロセスを通じて、場合によっては、他よりも安全であると言えるパスワードマネージャーが存在することがわかりますが、最も尊敬されているものについては、それらが異なるセキュリティのトレードオフを行っていることがわかります。このようなセキュリティのトレードオフの多くの例の1つは、ブラウザーの統合です。 Webブラウザーは敵対的な環境であり、プロセス間通信を正しく行うのは困難です。そのため、ブラウザ統合を備えたパスワードマネージャ（1Passwordなど）は、そうでないもの（KeePassなど）よりも攻撃範囲が広くなります。しかし、同時に、ブラウザを統合していないパスワードマネージャーは、フィッシング攻撃からユーザーを保護しません（当然、1Passwordは正しい決定を下したと思いますが、反対の選択をした人は十分に尊重できます。）
パスワードマネージャーのデザインには、私が尊敬できない他の選択肢があります。しかし、私はそれらについてのあなたの研究がそれらをあなたに知らせるようにします。
最も尊敬されているものと一緒に存在するパスワードマネージャーを構築したくない場合でも、その設計に入る難しい選択の理解を深めようとする必要があります。
最後に：もう一度お試しください
パスワードマネージャー開発の世界へようこそ！技術的には競争にありますが、パスワードマネージャーを使用する必要があり、その存在さえ知らない人が非常に多いため、私たち全員が市場を拡大しようとしています。うまく設計された別のパスワードマネージャーが提供されてうれしいですが、ヘビの油だけであり、いくつかの問題を深く理解していない人が構築したもので、そのシステムを使用する人に害を与えるだけでなく、また、パスワードマネージャの評判を落とします。
テキストをある程度安全にテキストファイルに保存し、後でデコードしてテキストを読み取ることができるように（できれば所有者のみが）、テキストをエンコードする「最良の」方法は何ですか
これは文字通り、正確には " encryption "です。これを行う最良の方法は、安全な cryptographic cipher （キーといくつかのプレーンテキストデータを入力として受け取り、理解できない「暗号文」を出力するか、またはキーといくつかを受け取る関数を使用することです暗号文と元のプレーンテキストを出力します）。キー（少なくとも、復号化に使用されるもの。一部の暗号化では、1つのキーを暗号化に使用し、ペアになっているが復号化に異なるものを使用）は秘密にしておく必要があり、攻撃者が予測できないようにする必要がありますが、ほとんどの暗号（正しく使用されている場合） ）キーよりはるかに長いデータを暗号化および復号化できます。たとえば、256ビット（32バイト）のキーを使用して暗号化された2TB（2000000000000バイト）のハードディスクがあります。
どの暗号が「最良」であるかという問題は多くの事柄に依存しますが、現在最も広く信頼されている暗号は AES（Advanced Encryption Standard） と呼ばれています。 AES自体はデータの小さなブロック（正確に16バイト）のみを暗号化できるため、 ブロック暗号化操作モード と組み合わされ、場合によっては パディング と組み合わせて再利用できますブロックの数が（ほぼ）無制限であり、ブロックサイズの整数倍ではないデータで同じキーを使用します。このように、私は本質的に任意の長さのいくつかの秘密データ（パスワードファイルなど）を持つことができ、適切な16バイトまたは32バイトのキー（実際には派生することができます）を持っていない人にはまったく読み取れませんパスワードから。ただし、ほとんどの実際のパスワードは、適切な暗号化キーよりもはるかに予測可能であるため、これにより脆弱になります）
適切なパスワードマネージャ（複数の利用可能な商用および/またはオープンソースのものを含む）は、「マスターパスワード」または「マスターキー」を使用して、保存されているパスワードを保護します。このマスターシークレットは、暗号化キー（完全にランダムに生成され、プレーンテキストには保存されませんが、暗号化されたパスワードとともに暗号化された形式で保存されます）の暗号化と復号化に使用され、暗号化キーは、実際に暗号化および復号化するために使用されますパスワード（これも、プレーンテキストで保存されることはありません）。マスターは、デバイスに保存されているキー（Yubikeyやフラッシュドライブなど、パスワードを復号化する前に入力する必要があります）、またはキー導出関数を介して実行することによって暗号化キーに変換されるパスワード自体にすることができます（本質的に非常に計算コストの高いソルト暗号ハッシュ関数）。
この追加の間接層（マスターキーを使用してパスワードをラップするのではなく、マスターキーが暗号化キーをラップし、パスワードをラップする）の理由は、マスターを変更したり、複数のマスターシークレット（たとえば、パスワードと、ハードウェアトークンに保存されているリカバリキーも含まれます）。暗号化キー以外は再暗号化する必要はありません。これにより、ユーザー間でのパスワード共有（1人のユーザーがすべてではなく一部のパスワードを他のユーザーに見られるようにしたい場合）を簡単に処理できるようになります（その機能を追加したい場合）。
残念ながら、Automateは暗号をサポートしていません（サポートするハッシュ関数は古く、非推奨ですが、必要に応じてそれらからKDFを構築できます）。 Automateを使用してBlowfishやAESのようなものを再実装するのではなく-絶対にしない-つまり、この言語は、機密データを処理する必要のあるアプリにはまったく適していません。
あなたはセキュリティについていくつかの誤った信念を持っているようですが、私はここでそれを片付けようとします。
つまり、プログラムはオープンソースになるため、ローカルバージョンのコードを誰もが参照および変更できるため、完全に安全にすることは不可能だと思います。
秘密のデータを保存するための非常に安全なオープンソースのツールがたくさんあります。いくつかの例：Gnu Privacy Guard（GPG）、TrueCrypt/VeraCrypt、OpenSSL、OpenPGPおよび/またはThunderbirdなどのS/MIME標準をサポートする多数の電子メールクライアントこれらのすべてのプログラムとアイデアの主な違いは、それらはすべて実際の暗号化を使用します。
彼らはセキュリティを侵害するためにコードと他の誰かの保存ファイルの両方が必要であり、現実的にはそれはすでにあらゆるセキュリティプログラムのためのゲームオーバーです
これは非常に間違っています。優れた暗号化の重要な要件は、攻撃者が完全な暗号文（パスワード保存ファイルなどの暗号化されたデータ、およびメッセージ認証コードや暗号化の初期化ベクトルなどの通常一緒に保存されるデータ）を持っている場合でも、暗号化に使用されたアルゴリズムの完全な詳細を知っている（オープンソースの「OpenSSL」ツールの特定のバージョンに実装されている、既知のIVを使用し、PKCS5パディングを使用するCBCモードのAES-256など）、攻撃者stillは、キーへのブルートフォース攻撃がなければ、データを復号化できません。そのような攻撃が完全に非現実的であるほど十分に長くされています（ここでは、「地球上に存在するすべてのプロセッサを使用しても、宇宙の熱死の前に終了しない」というレベルの非現実的です）。人々が「あいまいさはセキュリティではない」と言うとき、それは人々が意味することです。攻撃者がシステムがどのように機能するかを正確に知らない限り、システムが安全である場合、実際は安全ではありません。
私は銀行レベルのセキュリティを目指していません
より高く目指します。銀行は、現代の標準では、実際には非常に優れた暗号化（または一般にセキュリティ）を実際に使用していません。私の銀行は、私のパスワードマネージャーと同じくらい強力なパスワードの使用を許可していないため、私の銀行口座よりも私のパスワードマネージャーの金庫に入るのは難しいでしょう。番号+ルーティング番号、またはカード番号+郵便番号+ CVVまたはPIN）は、銀行口座のパスワードよりも推測や検索が簡単です（まだ簡単ではありませんが、おそらく簡単です）。
彼らのコードが私のパスワードに対して何をしているのかわからないので、私は本当に彼らを信用していません
100％オープンソースではないパスワードマネージャーでも、実際にパスワードをどう処理するかを確認できるはずです。例は LastPass です。これは商用ソフトウェアですが、ブラウザ拡張機能として提供されています。ブラウザー拡張機能はJavaScriptで記述されており、コンパイルされていないので、ソースコードを自分で読んで、その機能を正確に確認できます（また、ブラウザーの開発者ツールを使用して、機能しているときに拡張機能をデバッグし、生成するネットワークトラフィックを監視したり、受け取ります）。明らかに、あなたは個人的にこれを望まないかもしれませんが、あなたはそうすることができ、人々はそうします。アイデアは、十分な人々がこれを行うと、彼らがスケッチを引っ張ろうとすると、キャッチされて公表され、誰もそれを使用しなくなります。
たぶんそれは中央サーバーにそれらを格納しているのでしょうか？...いいえ！
一部のセキュリティ担当者は、自分が管理していないデバイス（パスワードマネージャーの会社のサーバーなど）にパスワードボールトを移動したくないことを認めています。しかし、実際のリスクをよく理解しているとは思いません。正しく行われる（そして、それが正しく行われたことを確認できることを忘れないでください）と、パスワードマネージャー会社はボールトを復号化できません。そのため、ボールトを保持しても、内部を覗くことはできません。上記のように、ボールト（暗号文）があり、暗号化の方法を正確に知っていても（暗号化したのは自分のコードであるため）、暗号化キーなしではコンテンツを解読できず、適切に設計されたパスワードマネージャーは決して暗号化キー（またはそれを導出するために使用される任意の素材）を保存または送信します。 いくらかのリスクはまだあります。なぜなら、彼らはそれが起こっていることに気付かずに何らかの方法でマスターキーを盗んだり推測したりできるためです（たとえば、「オフライン"攻撃）。暗号文（ボールト）がない場合は（効果的に）できませんが、おそらく思ったよりもはるかにリスクが低くなります。