塩加減はいい加減？
先日、SSHAの仕様について問い合わせを頂きました。そのとき気がついたことをお知らせします。
SSHA(Salted SHA)は弊社Sun Java System Directory Serverをはじめ、他のディレクトリ・サーバでも使用されているパスワードを保存するためのアルゴリズムです。パスワード保存のアルゴリズムは多くありますが、多くのサーバでSSHAがディフォルト設定になっています。
"Salt" （塩）はサーバ側で生成する乱数です。サーバは、ユーザから送られて来たパスワードを保存する際に、パスワードにこの乱数を付加した上でハッシュ値を計算します。こうすることで同じパスワードをつけたユーザがいても、サーバ側では異なる値が保存されるため、セキュリティ・レベルが向上します。パスワードに塩で「味付け」するという感じでしょうか。
様々なサーバやツールのSSHAの実装を調べたのですが、気になることがありました。サーバやツール毎に"Salt"の長さが異なることです。弊社のDirectory ServerやOpenDSなどは８バイト派ですが、古くからある他のサーバやツールでは４バイトしかとっていないものがありました。これによりセキュリティ上の問題や互換性の問題が発生するというわけではありません。ユーザから送られてきたバスワードを確認する処理で固定の長さの"Salt"を想定していると困りますが、弊社のサーバを含め他のサーバも私が見た限りは問題ないようです。
と言うことは０バイトでも良いということになります。０バイトの"Salt"を付加するとは、付加しないことと同じです。そのため、０バイトの"Salt"が付加されたハッシュ値を使ったパスワード確認のアルゴリズムはSHAと全く同じということになります。試しにちょっとイタズラしてみましょう。まずSHAを使ってユーザのパスワードを保存します。保存した内容は以下のようになります。
userPassword: {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
パスワード保存のアルゴリズムを示す{SHA}の部分に"S"を追加して｛SSHA}にして見ます。その右側にあるハッシュ値自体には変更は加えません。
userPassword: {SSHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
これでもちゃんと認証に成功しました。
以上です。何の役にも立たない情報ですみませんでした。
