Webサービスのログインを良くするヒント

はじめに

昨今のニュースで、リスト型攻撃（パスワードリスト型攻撃/アカウントリスト型攻撃）をはじめとした不正ログインが話題になっています。サービス提供者としては、どうやって不正ログインに立ち向かえば良いのか考えてしまいます。

ログインまわりの脆弱性についてのヒント

実際にどれくらい被害があるのか。どれくらいインパクトがあると認識すれば良いのか。セキュリティ調査を行っている機関が出しているレポートが参考になります。一例を挙げます。

IPA 情報セキュリティ10大脅威 https://www.ipa.go.jp/security/vuln/10threats2019.html

「不正ログイン」は８位に。このランキングは、件数や被害などではなく、影響度であり、投票で選ばれているようです。

OWASP Top Ten 最も重大なウェブアプリケーションリスクトップ10(2017年) https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#Translation_Efforts_2

こちらのレポートでは、「認証の不備」という項目があります。

リスト型攻撃も、抽象化すると、「本人ではない人物がログインできてしまう脆弱性」と捉えることができます。

サービス提供者として、どう対策するか

一般的な対策方法は、前述のようなレポートの最新版を常にチェックするのが良いと思います。それに、１つの対策で満足せず、複数を有効に組み合わせることも必要です。

ここでは、上記以外の対策方法も考えてみたいと思います。

アクセス遮断

総当たり攻撃や、辞書型攻撃の対策をするためには、ログイン失敗を記録してアクセスを遮断するような対策が有効です。

自前で構築することも可能ですが、手っ取り早くWAFを導入しても良いと思います。

WAF(WebApplicationFirewall)製品には、リスト型攻撃や総当たり攻撃など、不正アクセスっぽい特徴を検知してブロックする機能を持つものもあります。

ユーザにログイン通知メールを送る

これは簡単そうに見えます。ユーザがログインしたら、ただメールを送る。対処療法的ですが、不正ログインがあればユーザがすぐに気づけます。

普段と違う場所でのログインや、ひさしぶりなログインを検知して、あやしい場合はユーザにメールを送信します。

「普段と違う」かどうかの判定には、IPアドレスやHTTPヘッダ、ブラウザから取れる変数といった特徴（フィンガープリント）が使えます。

いずれにせよ注意しないといけないのは、メール送信は大抵の場合、コストがかかるということです。昨今、メール送信はタダではありません。

それから、頻度が高すぎるメールはたちまちブロックされてしまうでしょう。メール送信の一般的なベストプラクティスに沿う必要があります。

さらに、ユーザに対して危機を煽るようなメール要件は、控えるべきだと思います。日常的に危機を煽るメールを送っているサービスは、フィッシングに利用されかねません。ユーザからは、正規のアラートメールなのか、フィッシングなどの偽メールなのかの区別が付きにくいですし、しかも危機を煽られているシチュエーションでは尚更です。

メール送信のベストプラクティスは、ちょっと古いですがAWSのホワイトペーパが参考になります。
Amazon Simple Email Service（Amazon SES）のベストプラクティス
https://aws.amazon.com/jp/whitepapers/amazon-ses-best-practices/

ログイン履歴やセッション情報を可視化する

ユーザやCS担当者が、ログイン履歴やセッション情報を見れるようなUIを作ることを検討してみます。

調査のために、少なくともシステムログとしてログイン履歴を保存しているサービスは多いと思います。

しかし、システムログでは、調査にも時間がかかるし、アクセスすることがコストです。そこから一歩進めて、メインデータベースにセッションの状態やログイン履歴のテーブルを持つようにします。
データベース設計に織り込んでおけば、ユーザーがセッションやログイン履歴を見れるUIを作れますし、カスタマーサポートでも確認しやすくなります。

パスワードを廃止する

パスワードが不要なサービスを見かけることも増えてきました。

私は、パスワード廃止を支持しています。パスワード不要なサービスは応援したくなります。途中からパスワードを廃止するのは難しいので、オプションで選べるようにしても良いと思います。パスワードのかわりにどうやってユーザ認証をするのかといえば、バリエーションがあります。

メールやSMSを使う

メールやSMSにナンバーやURLを送る方法です。2段階認証の「2段階目」としても良く使われています。 Yahoo! JAPAN のメール認証は有名です。

パスワード無しが標準に　ヤフー・LINE先行
https://www.nikkei.com/article/DGXMZO44127860U9A420C1000000/

URLを送信するのは簡単ですが、しかし、メールをよく読まずにリンクを開くことをユーザに習慣づけてしまう懸念があります。大抵のユーザは、正規のメールか偽メールかの区別を常につけられるほど注意深くはないでしょう。

電子署名を使う

そもそも、これが可能なユースケースは少ないですが。
ユーザーがなんらかの秘密鍵をもっていて、公開鍵方式で認証するようなケースです。
実際に使われている場所といえば、SSHです。また、SSHを経由したGitもそうです。
また、ブロックチェーンでも使います。Ethereumアプリ(DApps)でこれが使われているのをよく見ます。 Web標準の Web Authentication API (WebAuthn)もこの一種といえます。

Web Authentication API
https://developer.mozilla.org/ja/docs/Web/API/Web_Authentication_API

OAuthなどで、外部の認証プロバイダを使う

一見良さそうですが、Webサービス開発をしていると、みんながTwitterやFacebookをやっているという錯覚に陥りがちなので注意が必要です。案外そうでもありません。

マシンリーダブルの観点でテストする

パスワード管理ツールを使っているユーザも多いと思います。Google Chrome をはじめとする最新版ブラウザでは、ブラウザ自体に、パスワード管理機能やパスワードサジェスト機能も組み込まれています。こういったツールから扱いやすいようにログインページやサインアップページを作っておくことも必要です。

パスワードサジェストが発動するかどうか。ツールが正しくフォームを認識してくれるかどうかといった観点でログインページを見直すことが必要です。人間の能力に頼らないログインページにしておくことで、アカウント乗っ取りなどの被害を減らせるのではないかと思います。

ログイン後も油断ならない

不正ログインということで、入り口となるログイン機能について書いてみましたが、実はログインにまつわる対策だけでは不十分です。

ログイン後に、なんらかの方法でセッションを乗っ取るような攻撃手法も存在します。セッションハイジャックと呼ばれます。例えば、盗聴（暗号化されていない経路での通信）、Cookieの不備、XSSなどが攻撃の起点に利用されます。

というわけで、ログインまわりの対策だけで油断せずに多層的に対策していく必要があります。

以上