システム開発におけるパスワード管理の注意点

システム開発において、ユーザが設定したパスワードをシステム内のデータベースに保存するケースがあると思います。
このようなケースにおいて、安全にパスワードを管理するための注意点を解説したいと思います。

パスワードをそのまま保存するのはNG

まず、ユーザが設定したパスワードをそのままの状態(平文)で保存することは避けるべきです。
なぜなら、サイバー攻撃などでデータが漏洩した場合、保存されたパスワードを覗き見られ、盗まれたパスワードを使って不正アクセスされる可能性があるからです。

そもそもデータが漏洩することは考えたくないケースではありますが、サイバー攻撃によりデータが流出したというニュースをよく目にする状況を鑑みても、万が一漏洩したケースに備えておくことはとても重要です。

ではどのように対策するのかというと、データを覗き見られとしても、そのままでは使えない状態に加工すれば良いということになります。

思いつく手段としては「暗号化」があると思いますが、パスワードを保存するケースでは不十分で、推奨されている手段は「ハッシュ化」になります。

暗号化とハッシュ化には大きな違い・特徴があります。

この「不可逆である」という点がポイントになります。
システム開発でパスワードを保存するケースで考えると、仮にデータ漏洩しても保存されたパスワードは平文に戻せないため不正アクセスに繋がらない、という考え方になります。

ハッシュ化には、「ハッシュ値は、元となる平文が同じであれば毎回同じ値になる」という特性があります。

このためログイン認証処理では、「データベースに保存しているハッシュ値」と、「ユーザが入力したパスワードをハッシュ化した値」が一致することを確認すれば、正しいパスワードが入力されたことが確認できます。

前の章でハッシュは「不可逆である」だから「盗まれても問題ない」と書きましたが、実際にはレインボー攻撃などの攻撃手段でハッシュ値から平文を推測する手段もあるため、完璧ではありません。

であればハッシュ化する意味はない！と思うかもしれませんが、ハッシュ値から平文を導き出すのにも時間がかかるため、データを盗まれてから実害が出るまでの時間を稼ぐという意味では重要になります。

時間が稼げれば、データ漏洩を検知した後に各ユーザに連絡し、パスワードを変更するまでの猶予が得られることに繋がります。

また、ハッシュ化する際にユーザごとに異なる固定文字を付け加えるなどの追加の対策により、平文を導き出すまでの時間を増やす方向の対策が有効とされています。

ハッシュ化自体も複数のアルゴリズムが存在し、前述の理由からより強固なハッシュアルゴリズムを使用することが推奨されています。

具体的には、(2024年時点では）Argon2idというアルゴリズムが推奨されていますが、詳細については次の記事でまとめたいと思います。

パソコンの性能も常に進化していくため、今時点で推奨されているアルゴリズムも数年後には非推奨となったりします。
このような背景があるため、新しくシステム構築を行う / 更新を行うといったタイミングで、その時点で推奨されているアルゴリズムを確認するのが良いでしょう。

今回の記事では、パスワードをハッシュ化して保存する理由に重点を置いて解説しました。
次の記事ではハッシュ化する際の具体的な手法について解説したいと思います。

本記事はOWASPの「Password Storage Cheat Sheet」を参考に記載しています。
セキュリティ対策は日々内容が変わっていくため、本記事執筆から時間がたっている場合はOWASPにて最新の情報を確認することをお勧めします。
※本記事は2024/7/25時点の情報です