気軽に楽しくプログラムと遊ぶ

自分が興味があってためになるかもって思う情報を提供しています。

暗号化に用いるSaltの課題を解決するSecret Salt

パスワード暗号化でSecret Saltなるものがあることを知ったので、Qiitaの記事を読んで、 頭に叩き込むために書き出してみた。

引用(というかほぼそのまま。。)させてもらったwebページは以下
パスワードハッシュ化で用いるソルト(Salt)とペッパー(Pepper)/シークレットソルト(Secret Salt)の役割と効果 - Qiita

一般的な暗号化

パスワードの一般的な暗号化手法としてハッシュ化があります。 ただ、単なるハッシュ化だけではブルートフォース攻撃(総当たり攻撃)などで 簡単にパスワードを特定されてしまいます。

そこで、saltをパスワードと結合してからハッシュ化することで特定されにくくするというハッシュ化が 一般的に行われています。

saltとは

saltは、ランダムに生成された文字列です。

役割と効果

役割

・同じパスワードでも算出されるハッシュ値が異なるようにすること

・ハッシュ化関数への入力文字列を長くすること

効果

・平文を前提に事前計算された攻撃準備の結果を無効化する

⇒(攻撃例)よく使われるパスワードの辞書等を用いてハッシュ値との対応表を作成する等

・攻撃するための事前計算で作成する逆引き表の作成コストを増大させる

⇒(攻撃例)レインボーテーブル等

必要条件

特定されにくくするためには以下が重要

  • 十分な長さの文字列
  • パスワード毎に異なるsalt文字列であること

saltの課題

懸念される状況

  • パスワードのハッシュ値が保存されるDBにSaltも保存される場合あり
  • パスワードのハッシュ値が保存されるDBの値からSaltが推測できる情報が手に入る状態になっている

上記のような状況の場合、SQLインジェクションなどでDB情報が洩れるとオンライン攻撃を行うための 十分な情報が手に入る可能性があります。

ストレッチング(ハッシュ化を複数回繰り返す)などを行っていれば、ある程度は攻撃を難しくはできるが DBの情報が洩れてしまっていてはオフライン攻撃(辞書型攻撃など)はできてしまう。

secret salt(Papper)

saltの課題をクリアするための追加の秘密情報が「secret salt(Papper)」

secret saltの特徴

  • salt同様にランダムに生成された文字列
  • パスワード+salt+ secret saltとしてからハッシュ化して用いる
  • 保存先はパスワードハッシュと別の場所に必ず保存する

効果

・DB等の情報が漏洩した状態で、オフライン攻撃を困難にすること

必要条件

特定されにくくするためには以下が重要

ハッシュ値・ソルトよりもセキュリティレベルが高い場所に分離して格納する必要がある

保存先

AWSであれば、「Secrets Manager」などが候補

ハッシュ化方法

uuidgenなどでは、最低限UUIDv4を用いることが望ましい。
ただUUIDはユニークな文字列を生成する仕組みのため、文字種が少ない。

同じ長さでも記号を含むランダム文字列を利用して文字列を生成する関数を使うのが望ましい。

【参考】AWS Secrets Managerのランダムなパスワードを生成する機能 https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetRandomPassword.html