9

私は学習の目的でユーザーログインシステムを作りたいと思っています。私はいくつかの質問があります。ユーザーログインシステムを実装する正しい方法

私はいくつかの調査を行い、ユーザーのログインシステムを実装する適切な方法は、ユーザー名/ IDと暗号化された/ハッシュされたバージョンのパスワードをデータベースに記憶することです。ユーザーのログイン時に、クライアント側のコードはMD5またはSHA-1などのパスワードを暗号化し、この暗号化されたパスワードをサーバー側に送信し、データベース内のパスワードと比較します。一致した場合、ユーザーは正常にログインします。

この実装方法により、データベース管理者またはプログラマーがデータベースのパスワードの実際のテキストを見るのを防ぐことができます。また、インターネット上の転送中にハッカーが本物のパスワードを傍受するのを防ぐことができます。しかし、私は理解していないことがあります。

  1. 私の最初の質問は、ハッカーがまたはのDBA(データベースハッキングによる)パスワードのハッシュ/暗号化されたバージョンを知っていれば、プログラマは単にデータベース内のテキストを見て、パスワードのハッシュバージョンを取得するもの、ということです、彼らは簡単にサーバー側にこのハッシュバージョンのパスワードを送信し、次に比較を行い、正常にログインするプログラムを作ることができます。パスワードを暗号化することはそれほど役に立ちません。私はここで何か誤解していると思う。

  2. 2番目の質問は、これは(私が上記の方法で)現在の業界でユーザーログイン機能を実装するための最も一般的で適切な方法ですか?私はすべてを手動で行う必要がありますか、あるいはデータベースによっては同じことをするための組み込み能力がありますか?ウェブサイトやウェブアプリのユーザーログインを行う最も一般的な方法/方法はありますか?もしそうなら、私にいくつかの詳細を教えてください。

  3. 以前の私の会社では、couchDBを使用してパスワードなどのユーザーのログイン情報を保存していました。彼らは暗号化のことについてあまり気にしなかった。彼らは、couchDBが自動的にパスワードを暗号化し、それを文書に格納すると言いました。これが安全な方法であるかどうかはわかりません。そうであれば、多くの作業を節約できるため、プログラマーにとっては非常に便利です。

  4. この方法(ポイント3)は通常の使用に十分安全ですか? mySQLのような他のデータベースシステムにも同じことができるこのような能力がありますか?もしそうなら、それは、mySQL組み込みメソッドを使用すると十分に安全であることを意味しますか?

私はユーザーのログイン機能を実装する非常に安全な方法を探していません。私はむしろ、人気があり、実装が簡単で、適切で、大部分のWebアプリケーションに十分なセキュリティが確保されている方法を探しています。助けてください。提供された詳細は本当に感謝します。

答えて

4

いくつかの明確化:

  1. は、MD5を使用しないでください。それは壊れたとみなされます。 SHAを使用してくださいが、私はSHA1よりも少し良いものをお勧めしたいと思います。 - https://en.wikipedia.org/wiki/MD5
  2. パスワードの塩漬けについては何も言及していません。これはRainbowテーブルを保護するために不可欠です。 - https://en.wikipedia.org/wiki/Rainbow_tables
  3. パスワードのソルト/ハッシュという考えは、実際にあなた自身のアプリケーションを保護することではありません。ほとんどのユーザーは、多数のサイトで使用するいくつかのパスワードを持っているからです。ハッシング/ソルトは、データベースへのアクセス権を持つ誰でも、これらのパスワードが何であるかを覚えてから、銀行アプリケーションなどにログインするのを防ぎます。誰かがデータベースに直接アクセスできるようになると、アプリケーションのセキュリティはすでに完全に危険にさらされています。 - http://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/
  4. データベースの組み込みセキュリティを使用してログインを処理しないでください。それはハッキーだし、彼らが持っているべきであるよりも多くのアプリケーションへのアクセスを与える方法です。テーブルを使用します。
  5. SSLについては何も言及していません。たとえパスワードがプレーンテキストのワイヤを介して送信されていれば、うまく設計された認証システムでさえ無用です。チャレンジ/レスポンスのような他のアプローチがありますが、残念ながら、パスワードの登録や変更に際してパスワードをプレーンテキストでサーバーに送信する必要があります。これを防ぐには、SSLが最善の方法です。
8

ユーザーがログインすると、クライアント側のコードでMD5またはSHA-1などのパスワードが暗号化され、この暗号化されたパスワードがサーバー側に送信され、データベース内のパスワードと比較されます。一致した場合、ユーザーは正常にログインします。

いや、いや、クライアントはハッシュ解除済みパスワードを介して送信する必要があります。クライアント側でパスワードをハッシュすると、そのハッシュは事実上パスワードになります。これは、暗号化ハッシュのセキュリティを無効にします。ハッシュ処理はサーバー側で実行する必要があります。

暗号化されたTLS(SSL)接続などのセキュリティで保護されたチャネル経由でプレーンテキストパスワードを送信する必要があります。


パスワードはアカウントごとに異なっている余分なデータの一部でを塩漬けしなければなりません。塩害は、平文とハッシュの間の直接的な相関を排除することによって、虹の表攻撃を阻止します。塩は秘密にする必要はなく、極端に大きくする必要もありません。ランダムな4バイトの塩でも、レインボーテーブル攻撃の複雑さは40億分の1に増加します。今


業界のゴールドスタンダードは、Bcryptです。塩析に加えて、bcryptは、減速要因で設計することでさらにセキュリティを強化します。

レインボーテーブル攻撃から保護するために塩を組み込むことに加えて、bcryptのは、適応関数である。それも増加して力まかせ探索攻撃に耐性のままので、時間をかけて、反復回数は、それが遅く作るために増加させることができます計算パワー....暗号理論的には、これは標準のBlowfishキースケジュールよりも強力ではありませんが、鍵の再生成の回数は設定可能です。したがって、このプロセスは任意に遅くすることができ、ハッシュまたはソルトに対するブルートフォース攻撃を抑止するのに役立ちます。

+0

システムがパブリック塩でパスワードクライアント側をハッシュし、プライベートソルト(つまり、サーバーに格納された文字列、またはサーバー側でランダムに生成された塩)でパスワードサーバー側を再ハッシュするとどうなりますか)?この方法では、サーバーは実際のプレーンテキストのパスワードを知ることができません。ハッカーがフェッチするときはいつでも、プレーンテキストバージョンのパスワードはサーバーに送信されません。私は知っている、中間の男はまだパスワードのハッシュをフェッチすることができますし、ブルートを強制的にJavaの塩でそれを強制しようとするが、それでも、彼の人生はかなり困難になるでしょうか? –

+0

クライアントがハッシュされたパスワードをサーバーに送信する場合、*ハッシュされたパスワード*は事実上実際のパスワードです。ハッカーがハッシュされたパスワードを傍受した場合、ハッシュされていないパスワードを知らずにサーバーに送信することができ、サーバーはそれを受け入れます。 –

+0

はい、これはサーバーに送信されているプレーンテキストのパスワードにも当てはまります。ハッカーが傍受した場合、ハッカーは簡単で単純にアカウントにログインすることができます。しかしプレーンテキストのパスワードがハッシュされている場合、ハッカーがそれを傍受した場合、彼はその特定のウェブサイトにしかログインできず、クライアントが同じパスワードを持つ可能性のある他のウェブサイトにはログインできません。 –

関連する問題