安全なパスワードを安全に保つための最良の方法は何ですか？
データベースに接続するWebプロジェクトに取り組んでいます。そのため、-データベースのユーザーのログイン/パスワードを平文で（対称的な方法で暗号化して）保存して、テーブルの作成、エントリの追加などのアクションごとに再接続できないようにする必要があります。毎回これらの資格情報を要求する必要があります。
パスワードを平文で保存するのはあまりにも安全ではなく、私の可能性から外れていることを知っています。
これが私の考えですが、それが正しいかどうか、および/またはより良い可能性があるかどうかを教えてもらえますか？おかげで:)
アプリケーションは、フロントエンドとバックエンドの2つの独立した部分に分割されます。
ユーザーがフロントエンド経由でログインすると、ログインとパスワードが平文で送信されます（HTTPSの使用を推奨します）。バックエンドはデータベースへの接続を試み、成功するとBlowfishを使用してログインとパスワードを暗号化します、およびそれらをフロントエンドに戻します。
後続のリクエストでは、フロントエンドは暗号化されたログイン/パスワードを送信する必要があります。暗号化されたログイン/パスワードは、明確なものを知らずに、暗号化されたものだけです。
誰かがこのユーザーのデータ（XSSなど）にアクセスした場合、そのユーザーは暗号化された資格情報にのみアクセスでき、明確な資格情報にはアクセスできません。
攻撃者がMITMを実行できる場合、最初のログインのみが危険であり、次の要求はすべて暗号化された資格情報を使用します。
クッキー/セッションの使用を考えましたが、同じです。値はクリアに保存されるか、base64でエンコードされます。本当に安全ではありません！
Blowfishのアイデアは、PhpMyAdminがそれをどのように使用するか（別名、同じ）に由来しています。また、PhpMyAdmin上でも、ログイン部分もクリアに送られます。
私の実装は正しいと思いますか、それとも提案するより良い何かがありますか？できる限り安全な方法でやりたいです。これまでのところ、私を悩ませているのはログイン部分だけです：/
あなたのアイデアをありがとう。
編集：
どうやら、私の質問は十分に明確ではないので、もっと明示的にしようと思います：
PhpMyAdminの代替を構築したいと思います。 PhpMyAdminは、そのデータベース内の任意のユーザーのログイン/パスワードを与えることによってMySQLサーバーに接続するミドルウェアです。 Webフォームで要求される資格情報は、MySQLデータベースに使用されるものです。
したがって、ユーザーが正常にログインした後のセッション全体の間、PhpMyAdminはBlowfishを使用してパスワードを暗号化することにより、ログイン/パスワードをセッションに保存します。
これは、ユーザーがリクエスト（テーブルの作成、データの挿入、データの更新または削除など）を行うたびに、ログイン時に指定された資格情報を使用してデータベースに再接続する必要があるため、CAN NOTを回避できます。次に、ユーザーが要求したアクションを実行します。
その場合不可能 PhpMyAdminは資格情報のハッシュのみを保存するため、同じユーザーがその後に要求したときにデータベースに再接続することはできません。
平文で取得できるパスワードの保存はまったく良い解決策ではありませんであることがわかっています。これがthisの質問の理由です。ハッシュの方が良いことを教えてくれませんなぜなら、私の場合は役に立たないだからですが、ユーザーが行うすべてのアクションに必要なパスワードを維持するために、対称暗号化+ HTTPSよりも優れた代替策があるかどうかを知るためです。
質問が修正されたので、あなたがもっとうまくやろうとしていることを理解しました。
短い答えは次のとおりです。データベースのパスワードを（サーバー側の）セッションオブジェクトに平文で保存するだけです。あなたはこれ以上何もできない。
必要に応じて、データベースのパスワードを暗号化してセッションオブジェクトに保存できますが、キーをどこに保存するのでしょうか。セッションオブジェクトよりも安全なキーを格納できる場所はありません。キーを構成ファイルまたはグローバル変数に格納することもできますが、実際には、これが現実的な脅威に対するセキュリティを追加するかどうかはわかりません。なぜ気にする必要があるのかを理解するのは難しいです-それは私にとってセキュリティシアターのようなものです。
そのため、セッションの最初にユーザーにデータベースパスワードを入力させ、データベースパスワードをセッション状態に保存して、それで終了するだけです。あなたができるより良いことは何もありません。
そして、天国のために、優れたWebアプリケーションプログラミング手法を使用してください。 OWASPリソースを確認してください。 Webの世界で見られる一般的なWebの脆弱性に精通していることを確認してください。適切なセキュリティプラクティスを使用して、コードを慎重に記述してください。また、セキュリティについて何か知っている人に、コードのセキュリティレビューを依頼してください。コードにセキュリティの脆弱性があると、悪いことが起こります。
資格情報が暗号化されている場合でも、資格情報を回復可能な形式で保持する必要はありません。バックエンドアプリケーションが何かを解読できれば、バックエンドアプリケーションをハッキングできる人も解読できます。実際、遅かれ早かれ、バックエンドアプリケーションが危険にさらされ、それを念頭に置いて設計されると想定する必要があります。
最も安全な方法は、bcryptやPBKDF2などのアルゴリズムを使用して、パスワードをソルトおよびハッシュとして保存することです。最近では、MD5やSHA1などを使用した定期的なハッシュ/ソルトは十分に安全ではありません。 hashcatのようなプログラムは、パスワードファイルのクラックを非常に高速に処理できます。 hashcatに関するこの記事は優れた記事です 。
誰かがCookieストアにアクセスするのを心配しているのは良いことです。 Cookieは基本的にパスワードに相当するため、これらを保存している場合は、おそらくソルトハッシュにもする必要があります。
そして、本当に、これは非常に簡単に思えますが、多くのコーナーケースがあります。 アプリケーションフレームワークにセッション管理を行う方法がすでにある場合は、独自にロールするのではなく、それを使用する必要があります。
OWASPセッション管理チートシート をチェックして、いくつかの推奨事項を確認してください。
最初：よろしいですか？まず、本当ににパスワードを保存する必要があるかどうかを確認しますクリアテキスト、または回復可能な形式。あなたの質問は、これがなぜ必要なのかを説明しませんでした。セキュリティ違反が発生した場合、誰もがあなたの決定を推測し、回復可能な形式でパスワードを保存したことが判明した場合、組織は評判を失う可能性があります。したがって、これが本当に必要であることを確認してください。
次：問題を定義します。では、具体的に何をしようとしていますか？質問はあまり明確ではなかったので、いくつか推測してみましょう。これらの推測が正確でない場合は、さらに考えてから質問を編集してください。
前提：ユーザーがWebアプリケーションにログインします。アプリケーションのユーザー名とパスワードを使用して、CyrilAppと名付けましょう。コードが他のアカウント（IMAP経由のメールなど）にアクセスできるようにしたいので、サーバーコードを後で使用するために、メールのユーザー名とパスワードを入力するように依頼します。次に、電子メールのパスワードをできるだけ安全に保存する方法を知りたいと思います。それはアイデアについてですか？
それが問題である場合、考慮すべきいくつかの問題があります：電子メールのパスワードを保存する方法？電子メールのパスワードを取得するとき、それを安全に使用するにはどうすればよいですか？メールパスワードへのアクセスを制限する方法
ストレージ。1つのオプションは、パスワードをハードウェアセキュリティモジュール（HSM）に保存するか、HSMが管理するキーで暗号化することです。ただし、HSMは非常に高価であるため、これは現実的ではありません。
より実用的なソリューションは、別個のサービスを構築することです。これを、EmailPasswordStoreと呼びましょう。これは、狭くてシンプルな機能を実行し、慎重にコーディングされており、Eメールのパスワードを安全に保管することが信頼されています。 CyrilAppコードがユーザーの電子メールパスワードを入力できるようにするAPI（ユーザーが入力した場合）と、CyrilAppコードがパスワードの使用を要求できるようにするAPI（たとえば、EmailPasswordStoreがIMAP接続を開いてIMAPサーバー、ユーザーのメールユーザー名とメールパスワードを送信し、CyrilAppとIMAPサーバーの間でバイトをやり取りします。
このアーキテクチャでは、EメールパスワードがEmailPasswordStoreを離れることは決してありません。EmailPasswordStoreの仕事は、CyrilAppが侵害されたり、他のサーバーが攻撃者によって攻撃されたりした場合でも、EmailPasswordStoreが防止する必要があることです。攻撃者が電子メールのパスワードを取得することから。 CyrilAppとEmailPasswordStoreの間のVPNを使用して、EmailPasswordStoreを別のマシン（またはおそらく別のVM）で実行し、EmailPasswordStoreコードの慎重なセキュリティレビューを行うことができます。
使用します。電子メールのパスワードを安全に保存するだけでは十分ではありません。ある時点で、それらを使用したいからです。暗号化された形式で電子メールのパスワードを保存し、それらを使用するときに復号化するだけでは、セキュリティ上のメリットはあまり得られません。Webアプリケーションを侵害する攻撃者が静かに座って、使用されている各パスワードを盗む可能性があります。 、または場合によってはすべてのパスワード自体を復号化します。したがって、いくつかの使用コントロールが必要です。
上記の提案されたEmailPasswordStoreアーキテクチャは、これらのコントロールを提供します。電子メールのパスワード自体を使用し、CyrilApp Webアプリケーションにパスワードを明かすことはありません。あなたの設定でそのようなことができるかどうかを試してみてください。
アクセスを制限します。最後に、パスワードを使用するためにEmailPasswordStoreをリクエストできるユーザーを制限したい場合があります。良い出発点は、EmailPasswordStoreがそれに接続しているサービスを認証することです。たとえば、CyrilAppとEmailPasswordStoreの間にVPNをセットアップし、EmailPasswordStoreが他のすべての接続試行を確実に拒否するようにします。
より高度なアーキテクチャでは、現在ログインしているユーザーのIDを確認し、その電子メールパスワードのみにアクセスを制限する場合があります。たとえば、EmailPasswordStoreは、ユーザーがCyrilAppへのログインに使用するハッシュ化されたパスワードのリストを保存し、CyrilAppがユーザーのメールパスワードをロック解除する前に、確認のためにユーザーのログインパスワードをEmailPasswordStoreに送信するように要求できます。ただし、設定によっては不要な場合があります。
参考資料も参照してください ソースが表示されているシステムのキーをどこに安全に保存しますか？ および 暗号化用のキーを保存する場所 。
- ユーザーがフロントエンド経由でログインすると、ログインとパスワードが平文で送信されます（HTTPSの使用を推奨します）。バックエンドはデータベースへの接続を試み、成功すると、Blowfishを使用してログインとパスワードを暗号化し、フロントエンドに返します。
代わりにソルトハッシュを使用する必要があります。
- 後続のリクエストでは、フロントエンドは暗号化されたログイン/パスワードを送信する必要があります。暗号化されたログイン/パスワードは、明確なものを知らずに、暗号化されたものだけです。誰かがこのユーザーのデータ（XSSなど）にアクセスした場合、そのユーザーは暗号化された資格情報にのみアクセスでき、明確な資格情報にはアクセスできません。
JavaScriptでのフグの実装によって？攻撃者が暗号化されたパスワードを知っていれば、JavaScriptをオフにして、元のパスワードを知らなくても送信できます。
- 攻撃者がMITMを実行できる場合、最初のログインのみが危険であり、次の要求はすべて暗号化された資格情報を使用します。
誰かがMITM HTTPSを試みると、無効な証明書の警告が表示されます（秘密鍵を取得できなかった、またはなんらかの方法で偽造された場合を除いて、これは非常にまれです）。
フロントエンドサーバーは認証を処理し、暗号化されたパスワードを保存する必要があります。ハッシュされたパスワードは、このサーバーのハッシュと比較されます。
暗号化されたパスワードが 塩漬け。そうすれば、データが盗まれた場合、解読が難しくなり、レインボーテーブルの効果が低下します。
バックエンドサーバーにはクリアテキストのパスワードが含まれ、内部ネットワークからの接続のみを受け入れます。パスワードの変更は、最初にここで更新され、次にフロントエンドサーバーで更新されます。
このサーバーには厳密なファイアウォールルールを必ず記述してください。このサーバーへの更新のみを許可し、ドロップ すべて 他のパケット。
このサーバーはインターネットからアクセスできないようにする必要があり、おそらくローカルサーバーによって更新する必要があります。
MITMに関しては、それを防ぐ効果はありません。
パスワードがハッシュ表現とソルトと一緒にバックエンドデータベースのrsaで暗号化されたセットアップを見ました。復号化キーは、インターネットのない別のマシンに保管されていました。バックエンドからパスワードをフェッチして復号化し、暗号化してプッシュバックできます。次に、バックエンドサーバーはハッシュをフロントエンドサーバーにプッシュできます。フロントエンドサーバーは、インターネットに接続する唯一のサーバーでした。
まず、[〜＃〜] no [〜＃〜]です。一般的にはもっと良い方法があります。
たとえば、パスワードをハッシュとして保存し、ユーザーがログインしてハッシュに対して正常に認証されると、パスワードをセッションでのみメモリに保持し、必要な接続に使用して、パスワードを忘れます。必要なくなったらすぐに。保存されることはありません。
次に、needを不条理な要件のためにパスワードを保存する場合、それを半可逆的にするための良い方法は、公開鍵暗号（RSAなど）を使用することです。公開鍵（秘密鍵が存在しないもの）での暗号化は、ハッシュとまったく異なりません。それはハッシュほど良くありませんが、それを復号化するためのパスワードが存在しないため、対称暗号化（フグ、AESなど）よりもはるかに優れています。思い出させます：プライベートキーは、同じサーバー上や同じネットワーク上などではなく、パブリック環境からアクセス可能であってはなりません。プライベートキーは、設計が必要とする愚かな緊急事態にのみ使用してください。
ただし、一般的に実装されている公開鍵暗号は、実際にはRSAラッパーを使用した対称暗号です。実際に使用しているプロトコルを把握します。