2014年のセキュリティ案件を踏まえて、 今後どのように振る舞っていけばよいか提案する。
まずプロバイダメールを使うのをやめよう。 Gmailを使い、Webサービスの登録メールアドレスをすべてGmailに変更する。
そしてパスワードを使いまわさないこと。 パスワード管理ソフトを使い、なるべく複雑なパスワードを自動生成させよう。 パスワード長は長く、英数記号すべて混ざったパスワードが使えたら一番良い。 パスワードを頭で記憶しようなどとは思ってはいけない。 もちろんブラウザのパスワード記憶は無効にして、登録されたパスワードは削除しよう。
さらにサービスが2段階認証に対応しているなら必ず有効にしよう。 Google Authenticatorに対応しているサイトだったら、アプリひとつですべて管理できるので手間も増えない。
ここまで設定できればそのアカウントはだいぶ堅牢になる。 逆に、この設定ができないサービスは、セキュリティの配慮が足りない信頼できないサービスとして一歩引いた目で見たほうがいい。 例えば最大パスワード長が短かったり、記号が使えなかったり、2段階認証が設定できなかったり。 そういうサービスには重要な個人情報を登録しないなどの判断ができる。
まずサービスのフルSSL化は今やもう必須だと思ったほうが良い。 WiFiはどこにでも飛んでいるので、常に中間者攻撃を受けているという前提で考えなくてはならない。 プロバイダも信用してはいけない。政府のような強い権力から干渉を受ける可能性も十分にある。 日本はもはや個人の自由が守られる国ではないと認識したほうが良い。 ユーザの自由を全力で守らなければ守りきれないだろう。
もうわかりきった常識だとは思うが、パスワード保存にはもちろんSALTを付けてハッシュ化しなければならない。 何回もハッシュ化を繰り返すストレッチング処理もしたほうが良い。 個人的には、送信前にもハッシュ化して、サーバが生パスワードを受け取らないようにしたほうが良いと考えている。 これは、サーバ管理者の不正行為や、不正なログ出力コードの埋め込みなどで、生パスワードが漏洩する可能性を防ぐためだ。 ユーザはサイト毎にランダム生成されたパスワードを使うべきだと書いたが、 ユーザがそうしてくれることをエンジニアは期待してはいけない。 ユーザはすべてのサイトで十分長くも複雑でもないパスワードを使いまわしていると想定するべきだ。 自社から漏れたパスワードが他で使われてしまったら非常に不名誉なことだろう。 たとえ管理者であっても、ユーザが入力した生のパスワード文字列が見えてしまう状況というのは、良い状態ではない。李下に冠を正さず、TCPにログを仕込まず。できるだけ排除したほうが良いと考える。
さらに2段階認証が使えるようにしよう。 TOTPアルゴリズムに従って実装すれば、 Google Authenticatorなどのアプリケーションで2段階認証のトークンが作れるようになる。 rubyだとrotp gemが全部やってくれそうだ。 他のアルゴリズムで実装してはいけない。オレオレアルゴリズムなんてもってのほかだ。 Google Authenticatorで使えることが重要なのだ。
HeartBleedやShellShockのような脆弱性発覚は事前に防ぐことは無理だろう。 バグのないソフトウェアなんて無いだろうし、 どんな小さなライブラリだとしても間違っても自作しようなどと思ってはいけない。 オープンソースを使わないという選択肢はないだろう。 一度アップデートが滞ると、古いバージョンからの移行が加速的に難しくなる。 常に最新にアップデートされるようにしておこう。 何かが問題が発覚した際は、システムの原理をきちんと理解し、冷静な対応が必要だ。 そのためには常にアンテナを高く張っておかなくてはならない。