エラーの内容はcrypted_passwordがない。みたいな感じだった。
要はActs_as_authenticatedはpasswordをMD5でハッシュ化したものをcrypted_passwordというカラムに入れているらしかった。
すばらしい。パスワードはサイト管理者ですらも知ることができない状態にあることがセキュリティ上好ましい。筆者がシバシバ勉強させてもらっているWeb屋のネタ帳さんもそういってた。というか、コレで筆者はこの常識に気づかされた。
ちょっと話が脱線するが、ネタ帳さんは"abcd123"をハッシュ化すると"79cfeb94595de33b3326c06ab1c7dbda"という文字列になる、という例を出しがら「この32桁の文字から元の値を割り出す方法は無い」とおっしゃっている。が、これは間違いである。
ネタ帳さんがおっしゃっているとおり、ハッシュは復号化できない不可逆な値を生成する。じゃあどうやったら割り出せるのかだけど、要はハッシュ化する前の元の値を知ればよいわけで。そう。ググってみるのだ！実際に「79cfeb94595de33b3326c06ab1c7dbda」をググルとネタ帳さんのページがヒットして「abcd123」だと言うことがわかる。
他にもブログとかSNSとかだと個人ページのURLにユーザーIDをハッシュ化したものを使っているものも多いため、ググルとけっこうな確率で元ネタがわかったりする。
※こんなもん完全な揚げ足とりなのはわかっているのでそこはノーつっこみで。
知っている人からすれば「暗号化に使うハッシュはsaltとセットなのは暗黙知だろ！」とおっしゃられるかもしれない。けど、世の中けっこうそうでもなくて、同様の仕組みをとっているシステムでもsaltを使ってないケースのほうが筆者の経験上多いし、上述のようなURLの例もある。
※saltについては"ハッシュ salt"でググるべし。
また、このご時勢でも未だに貧弱なパスワードを使っている人は多い。というか大半だと思われる。ユーザーIDと同じ、とかはまだマシなほうで、特にビビるのが数字オンリーなパスワードを使っている人。しかも4桁とかだとキャッシュカードと同じである可能性も高い。まあ、数字4桁くらいの話になると、これはもうそれを許容するシステムが悪いって気がするけど。
とにかく、、セキュリティはユーザビリティを確実に損なうものなのでさじ加減が難しいけど、パスワードってくらいだから意識はするべきだしsaltはかけときましょうってことで。なお、Acts_as_authenticatedはちゃんとsaltを使っている。
というわけで、Acts_as_authenticatedのDB構成とかを確認して、結局、usersテーブルはmigrateを使って作ることにした。
generateしたときに00n_create_users.rb(nは数字)ができているので、そこからemailの行だけ消してmigrationする。
※IDはメールアドレスを使うという仕様にする予定なので
これで、OK牧場！
コメントする