パスワードハッシュ

そのまま保存してはいけない

会員登録を作るとき、いちばんやってはいけないのがこれです。

db.prepare("INSERT INTO users (name, password) VALUES (?, ?)").run(name, password);

プレースホルダは正しく使っています。ですがパスワードがそのまま保存されています。

データベースが漏れたとき、全員のパスワードがそのまま読まれます。しかも多くの人は同じパスワードを他のサービスでも使っているので、被害は fleama の中では終わりません。

元に戻せない形にする

ハッシュ化は、値を元に戻せない形に変える処理です。

const crypto = require("crypto");
const hashed = crypto.scryptSync(password, salt, 32).toString("hex");

同じ入力からは必ず同じ結果が出ます。逆に、結果から元のパスワードを求めることはできません。

保存するのはこの結果だけです。ログインのときは、送られてきたパスワードを同じ手順でハッシュ化して、保存してあるものと一致するかを見ます。元に戻す必要はありません。

salt を混ぜる

salt は、ハッシュ化のときに一緒に混ぜる文字列です。

これが無いと、同じパスワードを使っている人は同じ結果になります。漏れたときに「この 2 人は同じパスワードだ」と分かってしまいますし、よくあるパスワードの結果を並べた表と照合されると元が割れます。

利用者ごとに違う salt を混ぜれば、同じパスワードでも結果が変わります。salt 自体は秘密ではないので、ハッシュと一緒に保存して構いません。

比べ方にも作法がある

if (hashed === stored) { ... }

動きますが、より安全な比べ方があります。

crypto.timingSafeEqual(Buffer.from(hashed), Buffer.from(stored));

=== は違いが見つかった時点で比較をやめるので、一致した文字数によって処理時間がわずかに変わります。その差を測って 1 文字ずつ当てていく攻撃があります。timingSafeEqual は最後まで比べるので、時間から情報が漏れません。

返すときも気をつける

登録の応答に、ハッシュを含めてはいけません。

res.status(201).json({ id: user.id, name: user.name });

第3章から繰り返してきた「返すものは選ぶ」が、いちばん効く場面です。

手を動かす

演習では、会員登録の処理を書きます。保存する形と、返す形の両方に気を配ってください。

1. パスワードをハッシュ化して password_hash 列に保存する(平文は保存しない)
2. stored は保存された {id, name, password_hash} を返す
3. response は {id, name} だけにして、ハッシュも平文も含めない