1月17日(火)1、2コマ目
今日の予習
パスワードを平文でDBに保存すると、DBからデータが漏洩した場合、パスワード漏洩につながる。
もし、DBからデータが漏洩しても、パスワード漏洩にならないようにするために、パスワードは平文ではなく、ハッシュ化して保存するのが一般的。
パスワードをハッシュ化するためのPasswordUtilクラスをあげておきます。
PasswordUtil.java
今日の予習
- パスワードをハッシュ化
- 入力チェック
今日のホワイトボード
セキュアなWebアプリケーションを構築するために守るべきルールを紹介します。ユーザー認証
ユーザー認証にはパスワードが使われますが、パスワード以外にもユーザー認証に利用できるモノがあります。
![]() |
| 図 ユーザー認証に使えるモノ |
いずれも本人しか・・なモノです。
パスワードの取り扱い
今まではDBにパスワードを平文で保存してきましたが、セキュリティ上問題ありです。
今後はパスワードをハッシュ化して保存します。
![]() |
| 図 今までの問題点 |
ハッシュ化
暗号化と似てますが、
- 暗号化は暗号文を復号可能
- ハッシュ化はハッシュ値をもとに戻せない
の違いがあります。(不可逆性)
![]() |
| 図 ハッシュ化 |
ハッシュ化されたパスワードで認証
DBにはハッシュ化されたパスワードを格納します。これは元のパスワードに戻すことができません。
ハッシュ化は同じ文字列を同じハッシュ関数でハッシュ化すると常に同じハッシュ値が取得できます。よって、入力されたパスワードをハッシュ化し、DBのハッシュ値と比較して認証します。
![]() |
| 図 ハッシュ化されたパスワードで認証 |
ソルト
ハッシュ化の際、文字列長が長いほどハッシュ値の推測が困難になります。そこで、パスワードにソルトと呼ばれる文字列を追加して文字列長を長くします。
また、パスワードが同じでもソルトが異なれば、ハッシュ値も代わり、パスワードの推測も困難になります。
![]() |
| 図 ソルトを使ってハッシュ化 |
パスワード+ソルトでハッシュ化での認証
各ユーザーはパスワードをハッシュ化する際、別々のソルトを使います。
そのため、DBには各ユーザーが利用したソルトも保存します。
認証の際は、入力されたパスワード+DBから取得したソルトでハッシュ値を求め、DBのパスワードのハッシュ値と比較します。
![]() |
| 図 ソルトを使ってパスワードをハッシュ化 |
入力チェック
方法はいろいろと用意されています。
ベタにやる際に使えるモノを紹介しました。
![]() |
| 図 入力チェックで使えるモノ |
次回は
簡単なWebアプリケーションを作りながら、セキュアなWebアプリケーション構築時に最低限気を付けなければならない内容を紹介します。






