パスワードを可逆的な形式で保存する-本物のユースケース

Question

何が問題なのですかクレイジーフール、プレーンテキストでパスワードを取得することができないはずです！

わかっています。聞いてください。

Mint.comに似たサービスがあると仮定します。 Mintに慣れていない人にとっては、次のように機能します。

ユーザーは、他のオンラインサービスと同じように、メールアドレスとパスワードを入力してMint.comにサインアップします。
ここが面白いところです。次に、ユーザーはドロップダウンから銀行名を選択し、オンラインバンキングのユーザー名とパスワードをMintに提供します。
これは、物事が本当に興味深いものになる場所です。Mintはこれらの資格情報を保存し、それらを使用してリストを取得しますユーザーによって自動的に行われたクレジット/デビットカードのトランザクション-一日のさまざまな時間。これは、オンラインバンキングサイトに自動的にログインすることによって行われます-ユーザーの資格情報を使用します（おそらくブラウザーエミュレーターから）。

現在、顧客のオンラインバンキングの資格情報を保護する安全な方法が必要です。

ここに大きな質問があります：あなたはどうしますか？

はい、すでにこの質問とこれを読みました。すべての回答は、サードパーティとのより安全な通信方法（APIキーを使用した認証、またはハッシュされたパラメーターの受け渡し）の使用を提案しています。私の意見では、それだけです-意見-私は本当の使用例のように思えます。私は信じられないほど機密情報をプレーンテキストで入手できる必要があります-少なくとも1日を通して定期的に。

興味深い事実：Mint.comには 1,000万人以上のユーザー

tylerl · Accepted Answer

あなたがユーザーに代わって情報を保存していることを説明し、ユーザーを認証するためにそれを使用していない場合。したがって、保存している内容にはパスワードが含まれますが（ほとんど排他的）、従来の意味では本当に「パスワードを保存する」ことはできません。 secretsを保存しています。

それに応じて戦略を調整します。

これらの問題はどちらも解決されています。あなただけの正しいソリューションを適用する必要があります。「パスワードを保存する」（つまり、ユーザーを認証する）ときは、使い慣れたハッシュ、ソルト、キーストレッチなどを実行します。しかし、secretsの保存についてはどうでしょうか。

何よりもまず、あなた回避可能であれば問題。これが、APIアクセストークンのような概念が存在する理由です。あなたはそれを使用できないので、あなたは私のFacebookのパスワードを必要としません。 Facebookが許可してくれたアクセストークンが必要です。

次善の策は、ユーザーのログインへのアクセスを結びつけることです。情報は、ログインに使用するパスワードから導出されたキーを使用して暗号化されます-私はそれを知らず、保存しません。したがって、私（サーバー所有者）は、パスワードを入力しない限り、データにアクセスできません。

これは強力なので人気があります。実際、Windowsはこれを長い間行ってきました。そのため、パスワードを変更すると、暗号化されたファイルにアクセスできなくなる可能性があります。これは、ログイン中にWindowsパスワードがプレーンテキストでメモリに保存される理由でもあります。実装を回避することをお勧めします。。

次のリストでは、プロセスを分離できます暗号化されていないデータが外向きのマシンで使用できないようにします。 HSMが関係する場合はボーナスポイント。ここでの要点は、ユーザーがWebサーバーにシークレットを提供することです。これは、接続されていないため完全にアクセスできないシークレット暗号デバイスへの公開鍵を使用してすばやく暗号化されます。単純な秘密はすぐに忘れられ、暗号化されたデータはどこかのコールドストレージに送られます。

結局、秘密はその暗号化の助けを借りてどこか他の場所で解読されて使われます。ただし、これが発生するポイントにはインターネットアクセスがありません。または、少なくとも外部からの進入路はありません。

最後に、上記の解決策を試すことができますが、惨めに失敗します。他のすべての解決策は、上記の解決策のくだらないバリエーションです：データベースでの暗号化、アプリケーションパスワードの使用、保存別のサーバーでのパスワード、別のサーバーでのデータの保存、[ここでのばかげたアイデア]による暗号化キーのソルトなど。

そして最後に、このような質問に対する私の標準的な警告が適用されます。私はそれを本当に大きく書くでしょう：

あなたがこの質問をしているという事実は、あなたがそれをするべきではないことを意味します

真剣に。人々の銀行の資格情報を保存していますか？自分がどのような問題に陥っているのかが分からない場合、インターネットにこれを行う方法についての提案を求めている場合、私が言及したすべての解決策が正しくなかった場合は[〜＃〜 ] already [〜＃〜]only実行可能なオプションであるそれから、これを実装すること。

人々はあなたがこれを正しく行うと信頼しています。そしてあなたはこれを正しく行うつもりはありません。あなたがしなかったからではありませんt適切な質問をしますが、この問題を十分に解決していないため、見落としている隠れた落とし穴を理解できません。これは難しいことです：することは難しくありませんが、間違いをしないことは困難です。

自分の頭の中に入って顧客の信頼を裏切らないでください。

mgibsonbr · Answer

私はこの慣習に同意しませんが、サーバーに非常に機密性の高い情報を保持する必要がある場合は、次のようにします。

同じサーバーで小さなデーモンを作成し、人間のオペレーターが起動時にパスワード/キーを入力するように要求します。
- それから対称暗号化キーと非対称キーペアを派生させます。
これらのキーをRAMのみ、スワップを防止に保持します。
ユーザーが機密情報をサーバーに送信する場合は、公開鍵を使用してブラウザー自体で暗号化してください（デーモンだけがそれを読み取ることができます）。デーモンに対称キーを使用して暗号化させ、メインのWebサーバーに戻ります。メインのWebサーバーに保存できます。
システムが機密情報を使用して何かを実行したい場合は、暗号化されたデータをデーモンに渡します。次に、暗号化を解除して理想的にはすぐに使用し（たとえば、サードパーティの要求を行い、何もログに記録しない）、プレーンテキストを消去して応答のみを返します（つまり、メインのWebサーバーはプレーンテキストを「認識」しません）。どんな瞬間にも）。

もちろん、できる限り補足的なセキュリティプラクティスを使用する必要がありますが、この手法の核心は、ライブマシンにアクセスできる攻撃者のみが、RAM別のプロセスのコンテンツを読み取ることができる）取得できることです。プレーンテキストの機密データ。攻撃者がサーバーに独自のコードを挿入できる場合、次の再起動時に、オペレーターはパスワードをtheirデーモンに入力します。デーモンに任意のコマンドを送信するだけでデーモンが実行できるのと同じように実行できる場合（つまり、これらの資格情報から取得されたデータを読み取るが、資格情報自体は読み取らない場合）、デーモンが実行するようにプログラムされていないアクションも実行しない）。

そうは言っても、1000万ならばかセキュリティに関心のある人々が私と取引をしたのではなく、私自身の知識だけに頼るのではなく（今のように）最高のセキュリティ専門家を雇う余裕があるでしょう。これはmight攻撃者にとってどれほど魅力的になる可能性があるとしても、私のシステムが最も弱いリンクになるのを防ぎます。潜在的に有用ではあるものの、問題が発生する可能性がある野心的な作業を行う前に、このことを念頭に置いてください。もし物事がうまくいかないとき。

BeagleEagle · Answer

私のデータベースに誰も侵入できないと完全に確信していない限り、その情報をユーザーのデバイスに保存して、サービスがデータ漏洩の原因とならないようにしたいとは思いません。でもやらなければならないとしたら...

ユーザーがアカウントを作成するときに、AES-256キーを生成します（これをstorage_keyと呼びます）。次に、ユーザーのパスワードから派生したキーでそのキーを暗号化します（user_keyと呼びます）。いくつかの固体KDF（scrypt、bcrypt、PBKDF2 ...）を使用して、encrypted_storage_keyとして保存し、ソルト、反復、およびユーザーのアカウントでuser_keyを導出するためにKDFが使用するその他のパラメーターと一緒に保存します。

次に、データの入力/読み取りプロセスは次のようになります。

ユーザーがパスワードを入力します。
選択したKDFと保存されているパラメーターを使用して、user_keyを導出します。
保存されたencrypted_storage_keyをuser_keyで復号化し、元のstorage_keyを取得します。
このstorage_keyを使用して、機密データを暗号化/復号化します。
storage_keyを必要以上に長くメモリに保存しないでください。また、その形式で保存しないでください。

もちろん、このスキームがセキュリティを保持するためには、ユーザーが自分のパスワードを入力するための「回線」を保護することが最も重要です（たとえば、Webサイトについて話している場合、SSL/TLSは最低限必要です）。誰かが、スキーム全体がばらばらになる元のパスワードを取得できます。