パスワード保管

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

ユーザーのパスワードを扱うことは本当に大きな問題であり、それを適切に扱うことはさらに大きな問題である。 

アプリケーションが攻撃され、ユーザーのパスワードがインターネット上に流出し、すべての人に見られることより悪いシナリオを想像するのは難しい。個人的には、私たちはそのことを考えるとぞっとします。では、どうすればパスワードを安全に、ベストプラクティスに従って保管できるのでしょうか？いくつかの方法を見てみよう。 

暗号化とハッシュの比較

表面的には、暗号化はパスワードを安全に保管するための適切なソリューションのように聞こえるかもしれないが、暗号化に全面的に依存するのは少々問題がある。 

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

つまり、パスワードを解読する能力は、かなり大きな責任でもあるのだ。誰かがサーバーを侵害し、パスワードの暗号文を手に入れた場合、そのパスワードを解読するのに必要な鍵の材料も手に入れられる可能性が高い。

一方、ハッシュはその一方向の性質上、パスワードにはるかに適している。一度ハッシュ化すると、暗号文を直接元のプレーンテキストに戻す機能はない。この性質により、ハッシュはパスワードの保護に非常に適している。 

すべてのハッシュが同じように作られるわけではない

パスワードをハッシュ化して保存することに決めたら、ただハッシュ関数を適用して終わり、という単純なものでもない。 

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

前述したように、ハッシュは一方向性関数であるため、元に戻すことはできない。技術的にはその通りなのだが、ハッシュは決定論的でもあるため、攻撃者が十分な時間とリソースを与えれば、ハッシュを元のプレーンテキストに逆変換できる可能性のあるブルートフォース戦術の影響を受けやすい。

このため、ハッシュ関数を2つのカテゴリーに分けた：

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

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

CPUやGPUが年々高速化するにつれて、消費者向けハードウェア上でハッシュに対する大規模なブルートフォース攻撃を実行することが容易になった。 

ワークファクター」は、ハッシュが業界のトレンドに沿った方法で保存されることを保証するために使用される。ハードウェアが高速化するにつれて、ハッシュの解読にかかる時間と労力を確保するために、アルゴリズムのワークファクターを増やします。例として、現代のハードウェアで100msとしよう。 

つまり、実際には2～3年ごとに仕事量を増やす必要がある。

‍