SQLアンチパターン読書会 「リーダブルパスワード」に参加しました

2014/5/28(水) SQLアンチパターン読書会 「リーダブルパスワード」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/11738

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターン (2013/01/26) Bill Karwin 商品詳細を見る

場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は11人かな。全員おなじみの方ばっかです。
この日は19章「リーダブルパスワード」がターゲットでした。

---

■ 発表
今回は @naopi さんが発表担当でした。

［Sqlap]リーダブルパスワード from Naoya Ishii

シンプルかつ上手くまとめられていますね～

---

■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。


以下、復習用の個人メモをダラダラと。
---

■ 19.5 解決策：ソルトを付けてパスワードハッシュを格納する

• ソルトの目的は、攻撃の効率を落とすため。
• ソルトはユーザ毎に異なる文字列にするのが一般的である。
• 実際は、同じパスワードを使っているユーザのソルトが異なればOK。（全員が異なる必要はない）
• メールアドレスをソルトにすることがある。
• ただし、ユーザがメールアドレスを変更した時にハッシュも更新する必要がある。（よくハマる）

■ 徳丸本

• 徳丸本を持参した @t_wada さん曰く、「とにかく読むべし」

体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践 (2011/03/03) 徳丸 浩 商品詳細を見る

■ 暗号の強度

• MySQLのSHA2関数による暗号も、今となっては緩い。
• Bcryptはいろんな言語で使えるが、それも弱いと言われている。
• FPGAが出てから、クラッキング専門のハードが作れるようになった。
• ネットワークカードがクラッキングを行うとかも可能になっている。

■ SSO（Single Sign-On）で逃げる

• SSOサーバが一度認証したら、他のアプリケーションにもログインできるようにする。
• 自分のサイトで認証しないのようにすれば、責任分解がしやすい。
• パスワードを自分のサイトで持たないようにすれば、漏れようがない。

■ ソーシャルログイン

• TwitterやFacebookなどのIDやパスワードを使って、他の会員制サイトの個人認証もする仕組み。
• ソーシャルログインを使う理由は大きく２つある。
  • １．IDとパスワード登録を強いるサイトはユーザが避けがちなので、それを解消するため。
  • ２．ユーザ情報を自分で持ちたくないため。（持っていなければ漏れようがないというセキュリティの観点）
• 人によってはソーシャルとユーザ情報の紐付けを嫌う人がいるので注意。

■ パスワードの管理指針

• IPAの推奨策＝「 全てのインターネットサービスで異なるパスワードを！ 」
  • 自分が利用するIDとパスワードを、リスト化して保持する。そのリストは暗号化しておく。
  • https://www.ipa.go.jp/security/txt/2013/08outline.html
• 最近はワンタイムパスワードが一般的に使われる。
• パスワードをどう格納するか考えるより、如何に格納しないで済むかを考える方が健全である。
• ユーザは複数のサイトで同じパスワードを用いることが多い。
• あるサイトがパスワードを平文管理をしていた場合、そこから漏洩すると他のサイトへも被害が出る。
• 大事なのは、自分のシステムをパスワードリスト攻撃のスタート地点にされないようにすること。
• ユーザがパスワードを散らすことは期待できないので、啓蒙するしかない。
• 万が一パスワードが自サイトから漏れても、攻撃に使われないようにするのが技術者倫理である。
• パスワードを管理するテーブルだけ別スキーマとする手段もある。

■ 複数端末間でのアカウント情報管理

• 最近のモダンなブラウザは、クラウド上でアカウント情報を管理する仕組みがある。
• Syncと呼ばれる仕組みで、ブックマーク、履歴、パスワードなどのアカウント情報を複数端末で同期する。

■ DBの暗号化

• DBのどこを暗号化しますか？
  • １．ハードディスク全体を暗号化する
  • ２．カラムを暗号化する。（IBMのDB2とか）
• 最近はカラムを暗号化してもインデックスが効くようにできたりする。

■ 19.5.4 SQLからパスワードを隠す

• この章の最初の方は、SQLでハッシュ関数を呼び出して暗号化しているが、それはセキュリティ的にダメ。
• SQLに平文でパスワードが書かれることになるので、ネットワークパケットやログから漏れる恐れがある。

■ パスワードのストレッチング

• ストレッチングとは、ハッシュ化された文字列に対して更にハッシュ化の処理を行う処理を複数回繰り返す処理のこと。
• 複数回のハッシュ計算をさせることで、攻撃者はストレッチングの回数分だけレインボーテーブルを用意しないといけなくなる。
• ただ、所詮は繰り返した回数分しか安全性は増さないので有効性は疑問。（指数的じゃなくて線形なので）
• 手間の割にはイマイチ。それよりソルトを使う方がずっと大事である。

■ メールによるパスワード通知

• メールでパスワード通知は安全じゃないので、何かしらのリスク軽減策を用いる。
  • １時間とか、有効時間を区切ってリスクを減らす。
  • N回耐性（入力をＮ回間違えたらアカウントをロック）を導入する。
  • ランダムアタックを防ぐため、入力から次の入力までの時間間隔を徐々に伸ばす仕組みを導入する。

■ 設定ファイルからの漏洩防止策

• Webアプリの場合、Web/APサーバの設定ファイルにDBサーバへのログイン情報を記載することが一般的である。
• その場合、悪意のある内部のエンジニアはいつでもDBサーバへのログイン情報を入手できる状態となる。
• 対策として、DBへのログイン情報を環境変数などに逃がすのも一案。
• その場合、ログイン情報は環境変数から取得するようにアプリを作っておく。
• 設定ファイルには暗号化したログイン情報を書いておき、復号化して利用するという手もある。

■ パスワードの履歴管理

• 一定期間（３ヶ月とか）が経過するとパスワードの更新が必要となるシステムがある。
• そのようなシステムでは、パスワード更新の際に、過去数回分のパスワードと同じにならないことを要求してくることが多い。
• その際、完全一致だけでなく過去のパスワードと似ている場合もダメ、とするシステムがある。
• ・・・「似ている」ってどうやって実装してるの？
• パスワードをハッシュ化したら、比較できないはず。
• つまり、過去のパスワードを平文で保持していないと類似判定できないはず・・・
• もしお客さんからそのような要件を要求されたら、平文で保持するリスクをきちんと説明することが技術者として大事。

■ 個人情報が漏洩してもリスクを軽減する策

• ゴミデータを大量に仕込んでおけば、もし流出しても使えないデータが大半となり利用価値は減る。

■ OSSでのパスワード管理

• OSSだとソースコードや設定ファイルが丸見えなので、パスワードや暗号手法がオープンになってしまう。
• その場合は、インストール時に動的にパスワードを生成するようにするのも一策。

■ セキュリティ攻撃のリスク軽減策

• DBMSへの接続ポート番号をデフォルトから変えておく。
• rootで繋がせない。
• きちんとロールを分け、最低限の権限しか与えないようにする。
• 例： Select, Insert, Update, Deleteの権限のみ付与し、Create Table やDrop Table の権限は与えない、等。
• MySQLの最近のバージョンでは、パスワードはデフォルトで設定させるようになっている。（昔はパスワード無しがデフォ）
• デフォルトを厳格側に倒すべき。そっちのほうが幸せになる。

■ Oracle Database

• Oracle Databaseは、「SCOTT/TIGER」というスキーマのデモ環境を構築するスクリプトがあり、とても有名。
• 「SCOTT」とはOracleの前身であるSDLに在籍していたBruce Scottを指し、「Tiger」は彼の愛猫の名前に由来するらしい。
• そのまま本番系とかに使わないように・・・

■ VB6

• VB6は自前でハッシュの仕組みがない。
• パスワードをリバースしてたり1文字ずらしてたりとか、オレオレ暗号が使われる・・・

---

★感想：

今回もいろいろ新しことや知らないことがいっぱい出てきて新鮮でした。
「ソルト」とか「ストレッチング」という用語も知らなかったなぁ。
あと、「自分のシステムをパスワードリスト攻撃のスタート地点にされないようにする」という @t_wada さんの言葉、ズシッと来ますね・・・
個人情報の管理はスゲー気を使うところで、いろいろやりかたもあるので、きちんとメリデメとリスクを理解することが大事だなぁと思いました。

・・・残念なのは、読書会終了後にみんなとお蕎麦を食べにいけなかったこと。
会社にとんぼ帰りして深夜までお仕事だったのでした・・・

次回は２０章「SQLインジェクション」ということで、これまた身近なネタで楽しみです。
皆様、ありがとーございました。

---

■おまけ：過去の「SQLアンチパターン読書会」ブログ

1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-65.html

2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-70.html

3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-73.html

3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-77.html

4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-84.html

5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-90.html

6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-94.html

7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-97.html

8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-105.html

9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-109.html

10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-115.html

11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-118.html

12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-121.html

13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-128.html

14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-130.html

15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-133.html

16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-134.html

17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-136.html

18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-138.html