パスワードをユーザー名とは別に保存します。

Question

最近、ハイプロファイルWebサイトのハッキングなどのニュース記事に続いて、自分のサイトセキュリティの概要を確認しました。 LinkedInの

だから、私の質問は：

方法は、それが彼らのユーザ名と他の情報とは完全に別のユーザーのパスワードを保存することは可能でしょうか？このようにして、ハッカーは潜在的にパスワードを取得でき、対応するユーザー名は取得できません。

編集：私は既にパスワードをハッシュとして保存していると言っていることを忘れていました。

Answer 1

どのようにしても、認証メカニズムがユーザー名とパスワードを結びつける方法が必要なので、あなたが探しているものは無駄です。

そのルートに行くのではなく、解読できないハッシュ値としてパスワードを保存する必要があります。これはaccepted best practiceです。

http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database

Answer 2

パスワードを保存するのではなく、パスワードのハッシュを保管しないでください。幸い

は、MySQLはこのために、安全な（一方向）ハッシュ関数を提供します。

update user_table set 
password = PASSWORD(?) 
where user_id = ? 

が確認できます。PASSWORD()

あなたのクエリは、単にこのように、代わりにプレーンテキストのパスワードのハッシュを保存しますそれこのような：

select * from user 
where user_id = ? 
and password = PASSWORD(?); // returns the row if password correct 

公式mysqlのドキュメントのPassword Hashing in MySQL記事は徹底的にすべてを説明しています。

Answer 3

私はセキュリティを追加する最も良い方法は、Googleアカウントの使用と同じだと思います。適切なパスワードでログインすると（データベースにコード化された任意の文字を使用してコード化されますが、私はBcrpytを提案します）、あなたの携帯電話に秘密のコードが届きます。あなたは電子メールを使ってそれを行うことができます。複雑になってきています。また、ハックするのをより困難にするために塩や物を追加することもできます。

作成できる場合は、それを元に戻すことができます。常に。どのように、時間、いつかお金と意志の問題です。

ご質問の際は、あなたは常にユーザー名（すなわち、アカウント）をパスワードに結びつける必要があります。私はあなたが2つのサーバー上の2つのデータベースにこれを保存し、塩とハッシュで複数のサーバーを使用することができたと思いますが、正しいと受け入れられる方法は、単に私が言って比較するようなalgorythmを使用してエンコードすることです。

Answer 4

あなたのサイト上の別のユーザー名とパスワードを維持するためのクリーンな方法は、単純にすべてのパスワードを保持しないことです。

Googleなどのサードパーティサービスへのパスワードと認証を委任し、OpenIDを実装します。
http://openid.net/
は、次に、あなただけのユーザ名を格納することがありますし、あなたが違反、パスワードとユーザー名を発信するため、それは不可能になり、パスワードデータの知識がないだろうに、すべてのシステムに接続する必要はありません。ここで
はジェフアトウッドが話題にある：
http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html

EDIT：以下のコメントを受けて、Googleアカウントが侵害された場合、すべての子会社のアカウントが侵害されたと思われます。これがGoogleのような安全な認証方式が不可欠な理由です。ここでホイールを再発明する必要はありません。 2段階認証を使用してGoogleアカウントをさらに保護することができます
http://www.codinghorror.com/blog/2012/04/make-your-email-hacker-proof.html
すべてのサイトが別個の認証者として動作することを期待する理由はありません...セキュリティを犠牲にしてウェブの断片化を促進します。

Answer 5

私が読んだことから、LinkedInは、SHA1暗号化を使用して暗号化されていない暗号化されたパスワードを使用します。あなたのパスワードを「塩」化することが賢明であるようです。あなたが各ユーザーのためにランダムな塩で塩漬けしているなら、あなたはかなり良い形になっています。そうでない場合：

これは、ランダムビット列を生成し、ハッシュする前にパスワードに連結することを意味します。さらに、ユーザーがハッシュにパスワードを入力すると、各ユーザーのランダムビット列を格納してデータベースから取り出します。

パスワードは「saltted」（ユーザーに格納されている塩と連結されています）その文字列がハッシュされ、データベースのユーザーハッシュパスワードで確認されます これは、ユニークなハッシュをほぼ確実に保証し、パスワードのハッシュテーブルを論理的なパスワードにリバースエンジニアリングすることを非常に困難にします。各ユーザーに割り当てられたカスタムソルト。

なぜ誰かがリンクインが自分のハッシュを塩で染めていないのを知っていれば、私はあなたから聞きたいと思います。私が読んだことのすべてから、SHA1は簡単に解読できます。