パスワードストレージ

アプリケーションがユーザーを認証する場合、パスワードも処理する可能性があります。

ユーザーパスワードの取り扱いは非常に大きな問題であり、適切に処理することはさらに重要です。

アプリケーションが攻撃され、ユーザーパスワードがインターネット経由で漏洩し、すべての人に見られるようになるほどひどいシナリオは想像できません。個人的には、その考えに身震いします。では、パスワードを安全に、ベストプラクティスに従って保存するにはどうすればよいのでしょうか。いくつかの方法を見てみましょう。

暗号化とハッシュ

表面的には、暗号化はパスワードを安全に保管するための適切なソリューションのように思えるかもしれませんが、完全に暗号化に依存することには多少問題が生じる可能性があります。

暗号化は本質的に双方向の機能であり、もちろんパスワードを暗号化できるのと同様に、次のことも可能です。 復号化されました。完全に論理的だよね？そうでなければ、ユーザーのパスワードがデータベースに保存されているものと一致するかどうかを検証するにはどうすればよいでしょうか。

そのため、パスワードを解読する機能もかなり大きな問題になります。誰かがサーバーに侵入してパスワードの暗号文を入手した場合、そのパスワードの復号化に必要なキーマテリアルも入手できる可能性が高くなります。

一方、ハッシュは一方向であるため、パスワードにはるかに適しています。いったん何かをハッシュしたら、その暗号文を元のプレーンテキストに直接戻す機能はありません。この特性により、ハッシュはパスワードの保護に極めて適しています。

すべてのハッシュが同じように作成されているわけではありません

パスワードをハッシュして保存することを決めたら、ハッシュ関数を適用してそれを1日呼び出すほど簡単ではありません。

ハッシュにはさまざまな形やサイズがありますが、過去 10 年間のコンピューティング技術の進歩を考えると、そのほとんどはパスワードの保存には適していません。

前述のように、ハッシュは一方向の関数であるため元に戻すことはできません。これは厳密には事実ですが、ハッシュは確定的でもあります。つまり、攻撃者が十分な時間とリソースがあれば、攻撃者がハッシュを元のプレーンテキストに戻すことを可能にするブルートフォース攻撃の影響も受けやすくなります。

このため、ハッシュ関数は次の 2 つのカテゴリに分類されています。

• 暗号ハッシュ
• パスワードハッシュ

パスワードハッシュの主な特徴は、ハッシュの計算にかかる労力を定義する「作業要素」（単一の整数または複数のパラメーター）があることです。

CPUとGPUの速度が年々速くなるにつれて、コンシューマーハードウェア上のハッシュに対して大規模なブルートフォース攻撃を行うことが容易になりました。つまり、ハッシュは時間とともにますます安全性が低下する可能性があります。

「ワークファクター」は、ハッシュが業界のトレンドに沿った方法で保存されるようにするために使用されます。ハードウェアの速度が上がるにつれて、アルゴリズムの作業係数を増やして、ハッシュの復号化により多くの時間と労力がかかるようにします。例として、現代のハードウェアで 100 ミリ秒だとしましょう。

つまり、実際の作業要素は2〜3年ごとに増やす必要があるかもしれません。

‍