web-dev-qa-db-ja.com

フロントエンドまたはバックエンドでのパスワードハッシュ？

AngularJSにJava Spring BootとJSフロントエンドを備えたサーバーがあります。

先生は私にパスワードにHTTPSを使用するように言った、なぜなら私はそれらを十分に安全にハッシュすることができず、誰もそれらをハッキングできないからである。

HTTPSを使用すると、うまくいけば、余分にハッシュする必要はありません。私のソース： https経由でユーザー名とパスワードを送信します。これで問題ありませんか？

だから今私の質問に：私はもちろんDBにpwを保存します。 どこでハッシュ化すればよいですか？フロントエンドまたはバックエンド？

  • フロントエンドでハッシュする場合、バックエンドで他にsthを実行する必要はありません。しかし、HTTPS証明書の有効期限が切れている場合、私はinsecureです。
  • バックエンドでそれを行う場合、フロントエンドで他にsthを行う必要はありません。しかし、HTTPS証明書の有効期限が切れている場合、私はinsecureです。

パスワードハッシュ用に作成されたScryptを使用します。

tlspasswordshttpjava
11
rala

@ John は、ネットワークを介したパスワードの受け渡しをすでに十分に記述しています（HTTPSを使用）。

あなたの質問に答えるには：

どこでハッシュ化すればよいですか？フロントエンドまたはバックエンド？

バックエンド。それらをフロントエンドでハッシュするだけの場合、ハッシュ攻撃のパスに対して脆弱です。

データベースでパスワードをハッシュ化する理由は、データベースをすでに侵害した攻撃者がそれらのパスワードを使用するのを防ぐためです。

バックエンドでパスワードをハッシュする場合、攻撃者はまずWebサイトで使用するためにそれらをクラックする必要があります。しかし、フロントエンドでハッシュする場合、攻撃者はこれを行う必要はなく、データベースに格納されているハッシュを渡すだけで済みます。

19
tim

トランスポートセキュリティとデータベースセキュリティの2つを混乱させています。 TLSを使用するHTTPSは、クライアントからサーバーへのデータの転送のみを保護します。これは、盗聴者がクライアントとサーバーが互いに送信し合っていることを知らないことを意味します（簡略化）。パスワードの保存は、まったく別のトピックです。攻撃者がデータベースにアクセスできたとしても、プレーンテキストのパスワードにはアクセスできないようにする必要があります。

パスワードの保存方法に関係なく、常にTLSを使用する必要があります。それ以外の場合、盗聴者は、クライアントが認証のためにサーバーに送信するものを記録できます。そうすれば、クライアント側とサーバー側のどちらでパスワードハッシュを実行しても問題はありません。攻撃者は、単にネットワーク上を通過するものを記録し、通信を再生してアクセスを取得し、クライアントになりすますことができます。

（暗号化ではなくパスワードHASHINGを実行することに注意してください。ハッシュは一方向であり、暗号化はそうではありません）

ハッシュはバックエンドで行う必要があります。バックエンドはユーザーの制御下にあるため、必要に応じてハッシュが実行されていることを強制できます。さらに、クライアント側のハッシュを使用できます。たとえば、プロセスがそうであるように、クライアント側のハッシュだけを使用しないでください。ユーザーがブロックまたは操作できるJavaScriptで実行されます。それは合理的な脅威のようには見えないかもしれませんが、ユーザーが提供したデータを信頼するべきではありません。したがって、クライアントがハッシュを適切に実行していると想定しないでください。これは、間違いなくバックエンドで実行する必要があることを意味します。

10
John

HTTPSは、トランスポート層にのみセキュリティを提供します。ストレージに必要なセキュリティメカニズムとは関係ありません。

パスワードは暗号化しないでください。それらをハッシュして、後で復号化できないようにする必要があります（攻撃者も同様）。

また、クライアント側でハッシュステップを実行すると、ハッシュにアクセスした攻撃者がすべてのアカウントにログインする方法を使用できるため、ハッシュステップは常にバックエンドで実行されます。

3
Benoit Esnard

HTTPS（HTTP over TLS/SSL）は、転送中のデータ/移動中のデータに対してセキュリティを提供しますが、保存中のデータ（データベース、ハードドライブ上のファイル）は暗号化しません-> AES、3DES、BlowFishなどで暗号化されます。

データベースで暗号化を提供できますが、データベース全体ではなく、リソースを使い果たしてしまいます（暗号化ファイルは非暗号化ファイルよりも大きくなります）。特定のフィールド、つまり顧客PII->クレジットカード情報を暗号化するだけです。

ユーザーパスワードの暗号化はベストプラクティスではなく、ハッシュとソルトを行うだけです。

HTTPS証明書の有効期限が切れたら、攻撃者がパスワードをプレーンテキストで盗聴し、コードにセキュリティの層を提供するだけでかまいません。

ユーザーがパスワードを提供する場合、データベース上のユーザーのパスワードのHASHED + SALT値と一致するストアドプロシージャ（SQL）がコードに含まれている必要があります。 HASH + SALT値が一致しない場合、明らかにそれは間違ったパスワードです。

注：ハッシュは整合性を提供します。

SALT機能は、攻撃者がSALT値を知らないため、レインボーテーブル攻撃を実行する攻撃者のリスクを軽減します。

キー：HASH + SALT

https://en.wikipedia.org/wiki/Salt_（cryptography）

1
vulnerableuser