新規登録やリセット機能を用いたスクリーニングが行われたと思われる事案がよく出てきますが、だんだん拾うのめんどくさくなったのでお暇な方は編集リクエストをください

概要

パスワードリスト攻撃を受けた経緯がニュースになっていました。

対岸の火事ではない、ディノス・セシールを襲った新型リスト攻撃

有料会員限定記事なので見れない人は ~~Googleのキャッシュとかでなんとか~~ この記事をどうぞ。

巧妙化するECサイトへの不正アクセス。セシールの被害は「二重登録防止機能」の悪用が原因

まとめると

リスト攻撃を受けた
施行されたメアドは登録済みのものだけだった
内部からの漏洩？はしてないっぽい
登録時に多重登録防止の仕組みがあった
新規登録試行いっぱいあった
攻撃対象のメアド抽出に使われたなこれは

というお話です。

このお話に関連する、ユーザー周りの設計時に気をつけてることを書き残しておきます。

攻撃者にも親切なエラー

業務でユーザー周りの設計をしていると

メアド + パスワードで登録/ログイン
登録時にはメールを送って確認する

っていうごくごく一般的な要件が出てきます。
当然、この要件では

登録済みメアドで新規登録しようとしたらエラー
未登録のメアドでログインしようとしたらエラー

とする必要がありますが、今回の案件ではこのエラーを試行中のユーザーに見せて良いかが重要になります。

「このメアドで登録したっけ？」「このサービス使ってたっけ？」みたいなユーザーには、ログイン時に「このメアドは登録されていません」みたいなエラーを返してもらう方が親切でしょう。
しかし、第３者のメアドのリストを保持している攻撃者に対しては「このメアドで登録済みのユーザーがいるか」が簡単にわかるので、「リストのスクリーニング」に利用できます。

このリスクへの対策として「メアドもしくはパスワードが正しくありません。」とかのエラーを返して「どうしてもログインできないときは」みたいなリカバリーフローに流す方法を提案することが多いですし、一般的かと思います。
記事では「セシールオンラインショップ」が攻撃を受けたとあったのでその辺りでログインエラーを調べようと思ってググったらなんかたくさんあってメアドじゃなくてお客様番号とかでログインさせるとこもあったので途中でやめましたが、お仲間であるディノスのオンラインショップではこんな感じでした。

上記ディノスの登録フロー...というかECの登録フローは最初の画面で氏名/性別/電話番号/住所...と言った情報を入力させまくる系のが多いので試す気になりませんでしたが、今回の案件から大事なのはログインのエラーと同様に登録時に「登録済みのメアドかどうか」も試行中のユーザーに教えてあげたらいかんっていう話です。
登録フローで「登録済みエラー」を表示することにより、攻撃者にメアドのチェック機能を提供しているのと一緒なのですが、なかなかここをぼやかしてエラーにするのは難しいところでしょう。

メール送った送った詐欺による対策

では、登録のところでどのように「リストのスクリーニング」リスクを回避できるかというところですが、個人的には

最初にメアド確認処理を行う
登録済みのメールにはメールを送らないで登録フローを進められないようにする or 登録済みだからログインしてという内容を送る

という落とし所を提案することが多いです。

例えばmixiの登録フローはそうなってる風です。

上記のディノスのサイトの確認のせいで広告がディノス家具になってること、某有名サングラス😎の件があるので説得力がががってのはおいといて、登録済みのメアドで登録を試みても同じ画面になります。
このような画面では、攻撃者が「リストのスクリーニング」に利用することは困難でしょう。(世の中には処理の複雑さの違いによるレスポンスタイムの差により登録済みかどうかを判定できるという強者もいるらしい話を聞いたことがありますがここでは考慮しません)
また、ログイン、登録と同様にパスワードリセットなどのリカバリーフロー時にも同様の仕様にしておくのが無難だと思います。「未登録なメアドには何も送らない、もしくは未登録(だから登録して使ってねとかの)通知を行う」などの仕様が必要になるでしょう。

例えばGoogle先生はどうしてるか

なるほどなるほど。。。

Googleはメアド入力とその後のパスワード入力のステップを分けていることもあり、利便性重視でやってる感じでしょうかね。

あの有名な徳丸本でもこのあたりの最近の流れに言及がありました。

まぁ、Google先生は色々鍛えてると思うのでここは参考にしない方がいいと思います。

昔はメアドから氏名引いて表示しちゃうサービスもあった

Quoraのログイン画面はメールアドレスからユーザーのお名前を教えてくれる！

2011年の記事で、今見たらこんなでした。

名前は引かなくなったらしいけど登録済みかどうかはわかりますね。

おまけ : メアドでログインさせるのやめたらいい？

これは最初の記事でどこかの社長が「メアドでログインやめるべき」みたいなことを言ったと書いていました。
世の中に出回っているメアドのリストがそのまま使えないってことは良い点かもしれません。
しかし、実際のところはユーザーがついてこれるかってところは難しいですね。それなりに「ログインできない」「IDわからん」な問い合わせは増えるでしょう。

あと、ログイン同様に登録も監視しっかりな！みたいなことも書いてましたが、「スクリーニング対策」として本投稿でかいたようなことを先に言ってもらいたかったなと思いながらこの投稿を書きました。
以上です。

(追記) サンドラッグでも似たような話があった模様

サンドラッグの仮登録通知騒動とその後の展開について

これも登録のところでスクリーニングが行われたということでしょうかね。
上記のように攻撃者から見て登録済みかの判断がつかないようにしておくことでこのような試行は減らせるというかやってこない気はしますが、それでも他の人のメアドどんどんブッこんでいったらメール送られちゃいますね。

大量メール送信対策としては、環境判定＆特定期間中のメール送信数制限みたいな昔からあった気がする対策を取るべきかと思います。

(追記)コーナンpay

(追記)ブックオフオンライン

これはリセット機能に大量試行なのでスクリーニングっぽいですね。

(追記)KLab ID

KLab ID への不正アクセスによる迷惑メールの送信に関するお詫びとご報告 | お客さまへのお知らせ | ニュース | KLab株式会社

日本時間の2021年7月21日から22日にかけて、当サービスの新規会員登録用メールを送信するURLに対して不審な大量アクセスを検出いたしました。
当サービスでは、新規会員登録時に利用者がメールアドレスを登録する必要があり、そのメールアドレスに対して確認メールを自動で送信する仕様となっております。上記大量アクセスにより、KLabID会員ではない不特定多数の方々のメールアドレスに対し、確認メール（迷惑メール）が大量に送信されました。

KLab ID への不正ログインに関するお知らせ | お客さまへのお知らせ | ニュース | KLab株式会社

この不正なログインは、2021年7月23日付でお知らせいたしました不審な大量のアクセスにより、当サービスに登録済みと判明したメールアドレスに対し、当社外から入手したパスワードを組み合わせて不正にログインしたもの（パスワードリスト型攻撃）である可能性が高いと考えられます。

ゲーム開発のKLab、50万件の迷惑メール送信被害の後に明らかになった真の被害とは | 日経クロステック（xTECH）

一連の被害は外部のサービスで流出したメールアドレスとパスワードのリストを使った「パスワードリスト型攻撃」によるものである可能性が高いとした。最初の迷惑メール送信被害は、攻撃者がリストにあるメールアドレスがKLab IDに登録されているかどうかを調べたときに発生したと説明。

　登録済みだと確認された5762件のメールアドレスに対して、7月22日午後0時36分から不正ログインの試行が発生し、発表時点までに2439件の不正ログインが確認された。試行された件数に対して不正ログインが成功した件数の割合が4割を超えている。ほかの事例と比べて成功率が高い印象を受ける。

手元のリストを総当たりで試して行って50万件以上も新規登録用のメールが送られた = 未登録だとして除外。その結果、5762件が残った
そのリストにパスワードリスト攻撃を実施して2439件の成功

いきなりログイン試行だったら50万件以上行わないといけなかったものが、新規登録のところでふるいにかけられたので6千件弱まで絞られたというわけです。この数なら緩やかに試行したとしても大した時間もかからないので、ログインだけ強化するだけでは対策として困難だったわけですね。