ペッパー (暗号)
From Wikipedia, the free encyclopedia
暗号理論において、ペッパー（英: pepper）とは、パスワードなどを暗号学的ハッシュ関数によるハッシュ化する際に、付加されるデータのことである。この値はソルトとは異なり、パスワードハッシュと一緒に保存されるのではなく、ハードウェア・セキュリティ・モジュール（HSM）のような別の媒体に分離して保管される[1]。
なお、アメリカ国立標準技術研究所（NIST）はこの値を「ペッパー」ではなく秘密鍵と呼称している。ペッパーは、ソルトや暗号鍵と概念的に似ている。ランダム化された値であり、パスワードハッシュに付加される点でソルトに似ており、秘密に保たれるべきである点で暗号鍵に似ている。
ペッパーはソルトや暗号鍵と同様の役割を果たすが、ソルトが秘密ではなく（単に一意であるだけで）、ハッシュ化された出力と一緒に保存できるのに対し、ペッパーは秘密であり、出力と一緒に保存してはならない。ハッシュとソルトは通常データベースに保存されるが、ペッパーはデータベース侵害の際に攻撃者に取得されるのを防ぐため、個別に保存する必要がある。[2]ペッパーは、ブルートフォース攻撃によって発見されるのを防ぐのに十分な長さであるべきである（NISTは少なくとも112ビットを推奨している）。
種類
サイトまたはサービス固有のソルト（ユーザーごとのソルトに加えて）というアイデアには長い歴史があり、スティーブン・M・ベロビンは1995年のBugtraqの投稿で「ローカルパラメータ」を提案した[3]。1996年にはウディ・マンバーもそのようなスキームの利点を述べ、「シークレットソルト」と名付けている。[4]「ペッパー」という用語は、ソルトになぞらえて使われてきたが、様々な意味で使われている。例えば、チャレンジレスポンス認証の議論では、ペッパーはソルトのような量として使用されてきたが、パスワードの保存には使用されていない[5]、ペッパーを推測する必要があるデータ送信技術として[6]、さらにはジョークの一部としても使用されている[7]。
「ペッパー」という用語は、レインボーテーブル攻撃からパスワードを保護する議論の中で、パスワードとは別に保存される秘密のまたはローカルなパラメータとして提案された[8]。この用法はすぐに普及したわけではない。例えば、フレッド・ウェンゼルはDjangoのパスワードハッシュに、bcryptとHMACの組み合わせに基づいたストレージと、個別に保存された暗号学的nonceのサポートを追加したが、この用語は使用しなかった[9]。その後、使用がより一般的になった[10][11][12]。
ペッパーには複数の異なる種類が存在する。
使用例
ペッパーを使ってパスワードを保存する手順の概要を、例をもとに示す。
| ユーザー名 | パスワード |
| user1 | password123 |
| user2 | password123 |
この表には、ユーザー名とパスワードの2つの組み合わせが含まれている。パスワードは保存されず、8バイト（64ビット）の44534C70C6883DE2ペッパーは、ハッシュの出力値とは別の安全な場所に保存される。
| ユーザー名 | ハッシュ文字列 | ハッシュ出力値 = SHA256 (パスワード + ペッパー) |
| user1 | password123+44534C70C6883DE2 | D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D |
| user2 | password123+44534C70C6883DE2 | D63E21DF3A2A6853C2DC675EDDD4259F3B78490A4988B49FF3DB7B2891B3B48D |
ソルトとは異なり、ペッパーは同じパスワードを使用するユーザーに保護を提供しないが、攻撃者がペッパー値を利用できない限り、辞書攻撃から保護する。同じペッパーが異なるアプリケーション間で共有されないため、攻撃者は侵害された1つのデータベースのハッシュを別のデータベースで再利用することはできない。パスワードを保存するための完全なスキームには、通常、ソルトとペッパーの両方の使用が含まれる。
共有秘密ペッパー
共有秘密ペッパーの場合、1つのパスワードの侵害（パスワードの使い回しやその他の攻撃による）とユーザーのソルトが判明した場合、ペッパーを発見する攻撃につながり、ペッパーを無効にしてしまう可能性がある。これらの情報が知られている場合、ペッパーの値をブルートフォースで総当たりすることで、ペッパーを特定できてしまう。そのため、NISTはペッパーの値が少なくとも112ビットであることを推奨している。これにより網羅的探索による発見は現実的ではなくなる。
ペッパーは、展開されるすべてのアプリケーションに対して新たに生成する必要があり、そうでない場合、1つのアプリケーションの侵害が別のアプリケーションのセキュリティ低下につながる。ペッパーの知識がなければ、データベース内の他のパスワードは、ハッシュ値から抽出するのがはるかに困難になり、攻撃者はパスワードだけでなくペッパーも推測する必要がある。
ペッパーは、ソルトとハッシュのデータベースにセキュリティを追加する。なぜなら、攻撃者がペッパーを入手できない限り、元のパスワードがどんなに脆弱であっても、単一のハッシュを解読することは不可能だからである。たとえ（ソルト、ハッシュ）のペアのリストがあったとしても、攻撃者はハッシュを生成するパスワードを見つけるために、秘密のペッパーも推測する必要がある。秘密ソルトに関するNISTの仕様では、パスワードベース鍵導出関数（PBKDF）と、HMACのハッシュ関数としてSHA-3を用いた承認された疑似乱数関数を使用することを推奨している。NISTの推奨事項は、PBKDFを少なくとも1000回反復し、さらに非秘密ソルトの代わりに秘密ソルトを使用して少なくとも1000回反復することである。
ユーザーごとの固有のペッパー
各ユーザーに固有のペッパーの場合、トレードオフは、より多くの情報を安全に保存するコストをかけて、追加のセキュリティを得ることである。1つのパスワードハッシュを侵害し、その秘密のペッパーを明らかにしても、他のパスワードハッシュとその秘密のペッパーには影響がないため、各ペッパーは個別に発見される必要があり、パスワードハッシュを攻撃するのにかかる時間が大幅に増加する。
