問題タブ [password-storage]

ログインにパスワードが必要で、データベースがないページが必要です。

ページにハードコーディングすることを考えていました。

それとも暗号化してテキストファイルに保存しますか?

アドバイスをいただければ幸いです。

name 属性usernameを持つテキストボックスと name 属性passwordを持つ別のテキストボックスを持つフォームがあります。userとpassという列を持つデータベースもあります。ユーザーがサインアップすると、ユーザー名がユーザー列に、パスワードがパス列に追加されました。

フォームが正しいユーザー名とパスワードを送信したかどうかを確認し、成功した場合にコードを入力できるブランチがあるかどうかを確認する MySQL クエリを作成するにはどうすればよいですか?

私は本当にいくつかのコードが必要です.このビットはうまくいきません.私はそれが何かのようなものであるべきだと知っていSELECT * FROM table WHERE username == $username AND...ます. 助けてください。:)

ありがとう

ユーザーがアプリケーションを使用する前にログインする必要がある vb.net でプログラムを作成しています。Windows のインストール時の動作と同様に、プログラムのインストール時にメイン ユーザーが作成されます。

メイン ユーザーは、プログラムにユーザーを追加できます。パスワードを暗号化して保存する必要があることはすでにわかっています。私の質問は、ユーザー名とパスワードをどこに保存すればよいですか? レジストリ、分離ストレージ、または .config ファイル。他のユーザーは明らかにログインできないため、ユーザーがそのファイルを変更/削除できないようにしたくありません。また、このファイルは、コンピューターにログインするすべてのユーザーがアクセスできる必要があります。

コンピューターはインターネットへの接続が保証されていないため、ローカルに保存する必要があります。

ありがとう

私がパスワードを持っているとしましょう：

AAABBBCCCDDD 人 A に最初の部分 (AAA)、人 B に 2 番目の部分などを簡単に与えることができます。

しかし、4人のうちの 2 人が、私が提供したテキストの一部からパスワードを解読/形成できるオプションはありますか? 明らかに、AAA と DDD の部分だけからパスワードを作成することはできません。

どのように？:)

パスワードに対して、ユーザーごとおよびサイト全体のソルトを正しく実行しようとしています。これが私が持っているものです：

これは正しいですか？ありがとう

ソルトとハッシュを使用して、データベースに保存できる安全なバージョンのパスワードを作成することに関する投稿をいくつか見てきました。

ただし、1 つの質問が私を困惑させ、問題が見当たらないので、ここに質問を投稿して、他の人がアイデアの欠陥を指摘できるかどうかを確認することにしました。

私の基本的な考え方は、公開鍵と秘密鍵のペアを生成してから、秘密鍵を破棄することです。公開鍵/秘密鍵の暗号化に関する私の限られた理解は、秘密鍵を持っていない場合、公開鍵で暗号化されたメッセージを復号化することは「数学的にありそうもない」ということです。

公開鍵を使用してパスワードを暗号化し、暗号化されたバージョンをデータベースに保存します。誰かがログインしようとすると、公開鍵を使用してパスワードを暗号化し、保存されているものと一致するかどうかを確認しますか?

この考えには恐ろしい欠陥がありますか？ソルトとハッシュはどういうわけかより安全でしょうか?

Javaデスクトップアプリケーションにパスワードを保存するための推奨される方法は何ですか?

ユーザーが資格情報を一度だけ入力できるようにし、再度プロンプトが表示されないようにしたい。

個人的なプロジェクトでは、Preferences API を使用してきましたが、これはプレーン テキストで保存するのと変わらないと思います (セキュリティ上の観点から)。

どうもありがとう

編集：

ご提案いただきありがとうございます。質問をあまり明確にしていない可能性があるため、間違いなく混乱があるようです...

仮説的なシナリオを示します。

ユーザー名/パスワードで接続文字列を作成するリモートデータベース用の単純なフロントエンドを作成しているとします。通常、ユーザーは、アプリケーションが起動するたびにユーザー名とパスワードの組み合わせを入力するよう求められます。

そのパスワードを再入力する必要なく (アプリケーションの起動時に自動的に接続する)、そのパスワードをユーザーのマシンに保存する最良の方法は何でしょうか。

一種の「記憶」機能 (それ自体はあまり良い習慣ではないことを私は知っています...)

EDIT2：

皆様、ご回答ありがとうございます。Paŭlo Ebermann は目前の問題について非常に有益であり、Chris Smith のリンクは興味深いものでしたが、JVerstry のリンクを受け入れました。キーストアが私が取っているルートかもしれないからです。

想定される知識
ハッシュ、ソルティング、PBKDF [1-2]

問題
PBKDF2のようなスケーリングされたハッシュ/ソルティングアルゴリズムを使用してデータベースにパスワードを保存しています。「ねえ、パスワードを20000回ハッシュすれば、ブルートフォース攻撃に対して十分に安全なはずだ」と思いました。そしてその真実。より良いコンピュータが出てくる来年まで。

考えられる解決策

暗号化キーの長さとソルトの長さ（このソリューションにも組み込むことができます）の問題は別として、N日ごとにデータベース内のすべてのパスワードを再ハッシュするとどうなるかと思いました。つまり、2万回ハッシュされ、1週間後、さらに500回ハッシュされ、合計で20,500回ハッシュされます。ハッシュされた回数をデータベースのどこかに保存します。アイデアは、技術が進歩するにつれてハッシュ数を増やすことです。

既存の同様の実装
BCryptは、パスワードのハッシュにかかる時間を増やすための作業要素を導入しています
。PBKDF2は、同じことを行うために多数の反復を使用します。これは、Mac OS-X、Windows、およびLinuxでファイルレベルの暗号化に使用されます。Wi-Fiネットワークもその実装を使用します。

誰かがこれに関する問題を見ることができますか？これはすでに試されていますか？事前にハッシュされたパスワードを受け入れ、それを「N」回再ハッシュするアルゴリズムはありますか？

編集
問題は、複数のハッシュが安全かどうかではありません（これは試行され、テストされています）。問題は、ユーザーにパスワードを再設定させずにセキュリティを強化するための再ハッシュに関するものです。

解決策： JVestryとの話し合いの礼儀

したがって、ハッカーはデータベースの古いコピーを使用してパスワードを解読できるため、「N」日ごとにすべてのパスワードを再ハッシュするのは時間の無駄です。ただし、時間の経過とともにハッシュ数を増やすという概念をパスワード更新ポリシーと組み合わせると、その概念は適切です。

実装
すべてのパスワードは30日ごとに期限切れになります。それらが更新されると、それらのハッシュカウンターが増加します。したがって、昨日のパスワードリセットは、20日前のパスワードセットよりも解読が困難になります。ハッシュカウンターは、保存することも、最終変更日を使用してアルゴリズムから導出することもできます。

ありがとう！

TTD

適度なセキュリティ要件を持つWebサービスを設計していたとします。ほとんどの場合、脅威モデルは退屈な大学生に関するものであり、スパイ小説でこれまでに見つけたものに関するものではありません。次のパスワードストレージスキームを使用することで、実際に何か問題がありますか？

塩|| ハッシュ（サイト||パスワード||ソルト）

ここで、siteはサイトの一意の識別子、passwordはユーザーパスワード、saltはユーザー固有のランダムソルト、hashはSHA-1などの汎用暗号化ハッシュ関数です。|| 連結を示します。

私はこのスキームを思い付く特定の問題を認識しています。

• ハッシュは（高速に設計されて）評価が速く、1回の反復では、特定の弱いパスワードが推測可能になります。

• 連結だけでは、ハッシュへの入力全体に「しゃれ」が発生する可能性があります。

現在、インターネット上に特定のセキュリティ専門家がいて、これが十分に優れたパスワードハッシュスキームの私の考えである場合、私はおそらく雇用に値することはできず、必死に学校に戻る必要があると信じさせます。彼らは、セキュリティの観点からはるかに優れたプロパティを持つよく知られたパスワードハッシュスキームがあることを指摘しています。彼らは私がもっと良いものに切り替えることを要求します。

しかし、本当に、私はすべきですか？ここに少し反論があります。

• これはおそらく私のサービスの中で最も弱いリンクにはならないでしょう。本当に侵入しようと決心した人には他にもたくさんの道​​があります。私は自分の時間を優先して弱い道を確保する必要があります。

• 私のサイトに本質的な価値がほとんどない場合、費用便益はすでに攻撃者の利益に反しています。大規模なクラスター/ボットネットが1日/週で弱いパスワードを回復する可能性があることは実際的な懸念のどれくらいですか？確かに、その日/週に行うことには、より価値のあることがあります。

• トロイの木馬、キーロガー、ソーシャルエンジニアリング攻撃などが原因で、アカウントが侵害される可能性が高くなります。テクノロジーは、このセキュリティの制限要因ではありません。

• 私のスキームが複雑になるほど、別のプラットフォームに移動/拡張するのが難しくなる可能性があります。私がbcryptを（仮に）使用した場合、bcryptラッパーを作成して組み込む必要がある可能性があります。

私はこのスキームが本当に好きです。とても簡単です。実装を間違えるのは難しいです。そして私は、平均的なサイトに関するすべての意図と目的のために、それは問題ないはずだと主張します。より良いハッシュスキームを導入するように私に頼むことは、チェーンソーに対してすでに非常に脆弱であるドアに大きなロックをインストールするように私に頼むように聞こえます。

私がここで何か間違ったことをしているとしたら、特に実際的で現実の世界に当てはまる懸念の観点から、誰かがそれを指摘してくれることを非常にありがたいです。

ありがとう。