第２７回特別コラム (2014.9.3更新)

内部不正が常態化した昨今の情勢を見ると「うちはB2Bだから…イントラだか
ら…」のような甘えた設計が許されなくなりつつあります。

システム側での対策事例を幾つか集めましたので提案や設計の際の参考になれ
ば幸いです。

図版版も用意しましたのでご参照の程。
http://www.slideshare.net/yoheiigata/6-tips-for-user-authentication

① パスワード文字列の強化
この数年のシステムでは「8桁以上、英大文字、英大文字、数字」の組み合わ
せを要求される場合が多いです。

一昔前は6桁以上が主流だったかと思いますが、IPAの資料(*1)によると6桁な
ら解読するのに5日、8桁なら50年かかるとのことで相当に差があります。シス
テムによってはそれに加えて「記号」も要求され、この場合は約1千万年かか
る気の長い話になります。
ref. コンピュータウイルス・不正アクセスの届出状況[2008年9月分および
第3四半期]について,
http://www.ipa.go.jp/security/txt/2008/10outline.html

2008年当時の資料ですからGPUによる汎用計算が普及した昨今のコンピューター
では6桁では相当に危うい印象を受けます。

システムによってはabcdef...やpasswordなどの脆弱な文言を列挙した辞書を
サーバー側に置いて、そういった文言をパスワードに設定できないようにする
制御が行われています。

パスワードのルールは全ての対策の前提となります。この2014年にお客様に定
期的にパスワードを変更して頂かなければならないような愚かなシステムを作
らぬよう常に気を付ける必要があります。

② CAPTCHA
説明不要かと思いますがあの煩わしい画像認証の類です。煩雑な入力を強いて
攻撃のスループットを低下させる効果があるため「アカウント新規作成時、ロ
グイン時」に適用される事例が多いです。

アクセシビリティを確実に低下させるため、最近ではログイン時にパスワード
の入力ミスがあったときのみCAPTCHAが出てくるシステムもあります。

自前で実装すると色覚異常を持つ方への配慮や視覚障害を持つ方への音声合成
など工数のかかる話になるため、GoogleのRECAPTCHAなどの出来合いのサービ
スを利用する場合が大半かと思います。
ref. RECAPTCHA, http://www.google.com/recaptcha

ロシアの antigate.com のような発展途上国の人を大量動員した人海戦術によ
る解読をAPI化した便利なサービスもあるので万能ではありません。
ref. antigate, http://antigate.com

③ 二段階認証
所謂ワンタイムパスワードです。使い捨てパスワードを生成する専用装置(ト
ークン)を本人に持たせることで、本人以外のログインを防止します。
本人とトークンが1対1で紐付くため、ハッキングに対する強固な対策になりま
す。

専用のトークンが必要になるため今までは大規模なシステムでなければ導入で
きませんでしたが、Google Authenticator(2010年～)、Authy(2012年～)とい
うスマートフォンや携帯SMSを使ったソフトウェアトークンシステムが開発され
てから、北米のオンラインサービスでは利用例が急増しています。
ref. Google Authenticator, https://code.google.com/p/google-authenticator
ref. Authy, https://www.authy.com

携帯電話の通話やSMSで生成したパスワードを送るシステムもあります。一昔
前は電話の自動応答やSMS送信のシステムは大がかりなものでしたが、今年KDD
Iが業務提携したTwilioなどのサービスを使うとインターネット経由でAPIを叩
くだけで実現できてしまうので、これらも利用例が増えています。
ref. Twilio, http://twilio.kddi-web.com

④ PINコード
二つ目の簡単なパスワードを入力させる仕組みです。イメージとしてはクレジ
ットカード裏面の3桁の数字列と同じで、二段階認証のワンタイムパスワード
とは異なり同じパスワードを使い続ける形になります。

一つ目のパスワードと違って数字のみ4桁など非常に簡単なパスワードが大半
です。ログインした後の入出金などのクリティカルな操作を実行する際に入力
を求められる実装が多いです。

当然パスワードとしては脆弱なのですが、後述の[メールやSMSによる通知・承
認]と組み合わせると「自分以外の人間が勝手にログインして不正送金しよう
としている」などの局面で、ユーザーやシステムが対策する時間を稼ぐことが
できます。


⑤ メールやSMSによる通知・承認
不正利用をユーザーに伝えるため、ログインや出金などのクリティカルな操作
を行った際にはユーザー自身にメールを送るシステムも出てきました。

システムによってはメールに書かれた認証コードやURLを叩いて認証しないと
出金できないものもあったりしますが、いかんせんメールアドレス自体が一度
ログインできると変更できる項目ですので、それほど強固な仕組みとは思えま
せん。

⑥ アカウントアクティビティ
今まではユーザーに見せていなかった詳細な操作ログや接続情報を表示するシ
ステムが増えています。

ものによってはメールアドレスなどの登録情報を変更した際に、変更する前後
の値を表示するシステムもあります。攻撃者が不正な操作を行う際に一時的に
設定値を変更するパターンを後追いで検出できるようになります。

コネクションの管理も一般化しており意図しない接続をユーザーが切断する機
能や、それまで殆どが徳島からのアクセスだったのに急に中国の雲南省からの
アクセスになったなど接続元のIPアドレスが大幅に異なる場合に強制的にアカ
ウントをロックする機能などが見られます。