2016-08-08 14 views
0

学習の練習として最初のログインページを作成しようとしています。単純なユーザー名とパスワードの検証java

たとえば、ユーザー名の塩を使用してパスワードを事前にハッシュすることでした。それをテキストファイルに保存し、ユーザーがログインしたときに同じ塩を使用してパスワードをハッシュし、その結果をテキストファイルと比較します。

私はセキュリティなどの完全な初心者ですので、これが安全かどうかわかりません。小規模アプリケーションの標準は何ですか?この方法が推奨されない場合、適切な単純な選択肢は何ですか?

EDIT私はそれを動作させることができる場合、1つの可能な解決策。パスワード保存のために

String unpwfield; 
    unpwfield = userId.getText()+passwordfield.getText(); 
    if (BCrypt.checkpw(unpwfield, passwordhash)) 
     System.out.println("It matches"); 
    else 
     System.out.println(userId.getText()+passwordfield.getText()); 
+0

これは私にとっては良いことであり、多くのアプリケーションの標準です。安全なハッシュアルゴリズムを使用していることを確認してください。通常、この情報はデータベースに書き込まれます。 –

+0

私はここでユーザーにファイルを作成させようとしていましたが、http://aes.online-domain-tools.com/ を入力して、それらのユーザーにそのキーを使用するよう依頼してください。これは、キーがユーザ名であることを知っているセキュリティ上の欠陥ですか? –

+0

@ user1274820 [tag:password-encryption]と[this answer](http://stackoverflow.com/questions/2283937/how-should-i-ethically-approach-user-password-storage-for)のタグwikiを参照してください。 -later-plaintext-retrie/2287672#2287672)なぜそれはひどい考えです。 – EJP

答えて

1

、あなたは遅いハッシュアルゴリズムを使用するようにするつもりです。暗号化ハッシュが速すぎるため、オフラインパスワードの推測で攻撃者が遅くなることはありません。たとえば、多くの場合、bcryptが最適なアルゴリズムです。

Bcryptは独自の塩を生成するので、これらを生成する安全な方法について心配する必要はありません。

私は塩としてユーザー名を使用しないでください。塩は、同じパスワードが複数回使用された場合、同じバイト表現で保存されることを避けることです。

理由は、ユーザーが同じパスワードを再使用すると、パスワードハッシュデータの可視性を持つ攻撃者はすぐに明らかになります。また、あなたのシステムが公開されている場合、アプリケーションのすべてのインスタンスは、全く同じ方法で保存されたadminユーザのハッシュを持っています。つまり、攻撃者はadminを塩として虹のテーブルをあらかじめ作成できます。

詳細情報とガイダンスについては、OWASP Cheat Sheet on Password Storageを参照してください。

+0

私はBcryptを見始めました。私はランダムな塩と組み合わせるためにユーザー名とパスワードの両方を一緒に渡したかったのです。これが可能かどうか知っていますか?私は試してみるとnullポインタを取得します。編集を参照してください.. –

+0

Bcryptは独自の塩を生成します。独自のものを渡す必要はありません。そうすることに利点はありません。 – SilverlightFox

+0

私はユーザー名とパスワードの両方のチェックを処理する方法がわからないので、私はハッシュを作成する前に両方を一緒に組み合わせることができると思った。それから私はそれらを比較したいときに私は両方の文字列を一緒に追加して比較するだけです。 –

関連する問題