PayPayやメルペイは関係ないでいいんだっけ?ドコモ口座の不正送金問題を踏まえた考察
9月8日ごろから話題になっている、「ドコモ口座を悪用した不正送金問題」について、当ブログでも深堀りをしようと思い、まとめることにしました。
以前、7pay事件の際にも、記事を書きましたが、ちょっと似たような空気を感じています。
理由については、記事の最後で書きますが、まずは本題から行きましょう。
目次
まずは不正送金の流れを確認
まず、今回の不正送金の流れを図でご説明します。
攻撃者はどうやって暗証番号を入手するのか
攻撃者ははじめに、何らかの方法で口座番号、名義、暗証番号などを入手します。
暗証番号の入手に関しては、別のサービス経由で漏洩している場合もありますが、今回の攻撃では、リバースブルートフォースという手法で取得された可能性が指摘されています。
リバースブルートフォースは、ブルートフォースの逆で、パスワードを固定し、口座番号を総当たりで特定する手法です。
暗証番号は連続で失敗すると、アカウントロックがかかりますが、その逆はロック対象のアカウントがそれぞれ異なるので、アカウント単位でのロックができません。
リバースブルートフォースの対策としては、単にID・パスワードの認証だけではなく、後述するSMS認証を挟むことや、秘密の質問やCAPTCHAなど別の認証を挟むことが挙げられます。
あとは、一定時間のログイン拒否や同一パスワードを使うユーザの強制ロックなどがありますが、ユーザの利便性を大きく損なうのであまり対策としてはお勧めできません。
では、本来リバースブルートフォース対策となりうる、SMS認証について掘り下げます。
なぜ自身の銀行口座が他人のアカウントに紐づくのか
ドコモ口座を例に挙げると、銀行口座の連携には、dアカウントを作成した後、ドコモ口座を作成し、銀行口座と結びつけることで口座利用が可能になります。
これ自体の仕組みは、ドコモ口座ないしdアカウントに限らず、PayPayやメルペイなどの決算手段においても、あまり変わりはなさそうです。
では、ドコモ口座の何がまずかったのかというと、dアカウントの作成ハードルが非常に低く、攻撃者が悪用後すぐに破棄することで足がつきにくいという点です。
dアカウントは、他の電子決済サービスに使われるアカウントとは異なり、Eメールアドレスのみで作成可能で、作成が非常に容易です。
この点に関しては、NTTドコモが対策に踏み切っており、現在dアカウント作成時には、SMSを利用した2段階認証が必須です。
すでに、公式ページでのアカウント作成手順も変更されていて、これまでがどうだったかを示す素材がなかったのですが、以下のブログに手順が残っていたので、気になる方はご確認ください。
攻撃者目線で考えるSMS認証の重要性
文章だと分かりづらいと思い、こちらも筆者が想定する攻撃シナリオとして図を作成したので、ご参考にしてください。
もし、SMS認証があれば、dアカウント作成の段階で、電話番号を所持している個人に目星が付くので、少なくともEメールアドレスよりも攻撃者にとってはリスクが上がります。
さて、ここで気になってくるのが、他の決済サービスではアカウント作成時に2段階認証を導入しているのかという点です。
2段階認証の有無で、先述の通り、攻撃者の利用ハードルが下がります。
SMS認証に対応している決済サービス
以下の、マイナポイント人気決済サービスを参考に、決済手段に対し、銀行口座からのチャージをおこなう前に、2段階認証が導入されているかどうか、状況を確認してみましたので、ご活用ください。
決済サービス | 2要素認証の導入 | 備考 |
---|---|---|
d払い(dアカウント) | ×→○ | 今回の件を機に導入 https://mainichi.jp/articles/20200909/k00/00m/040/282000c |
PayPay | ○ | 登録時にSMS認証必須 https://paypay.ne.jp/guide/start/ |
メルペイ(メルカリアカウント) | ○ | メルカリ登録時にSMS認証が必要 https://jp-news.mercari.com/2018/11/26/signup/ |
auPAY(auID) | ○ | auPAY利用開始時にSMS認証が必要。auIDはSMS認証なし https://wallet.auone.jp/contents/sp/guide/other.html https://id.auone.jp/id/sp/guide/regist/another/index.html |
楽天ペイ | ○ | 楽天ペイ利用開始時にSMS認証が必要。楽天会員登録にはSMS認証なし https://pay.rakuten.co.jp/ |
LINE Pay(LINEアカウント) | ○ | LINEアカウント作成時にSMS認証必須。Facebook認証は2020年3月に撤廃 https://guide.line.me/ja/signup-and-migration/line-signup.html https://pay.line.me/portal/jp/about/sign-up https://guide.line.me/ja/update/0002.html |
ファミペイ | ○ | 登録時にSMS認証必須 https://www.family.co.jp/famipay/app.html |
J-Coin Pay | ○ | 登録時にSMS認証必須 https://j-coin.jp/user/guide/ |
ゆうちょpay | ○ | 登録時に電話番号認証必須 https://www.jp-bank.japanpost.jp/kojin/sokin/yuchopay/kj_sk_yp_goriyo.html |
一覧で見ていただくと分かるように、確かにdアカウントは特別抜け穴になってしまっていたようでした。
なお、コード決済ではなくICカード決済の場合は以下の通り、そもそも銀行口座チャージは提供していないものがほとんどで、唯一提供しているWAONも相当ハードルが高かったです。
- WAON
- 銀行口座チャージはイオン銀行限定かつ、イオンのATMもしくはICカードリーダライタで手元のイオンカードを読み取る必要がある
- https://www.waon.net/charge/aeon_bank_account/
- Suica
- 2019年9月に銀行口座からの入金サービスは終了
- https://www.jreast.co.jp/mobilesuica/new_s/bankchargestop20190408.html
- nanaco
- 銀行口座からのチャージ機能はなし
- https://www.nanaco-net.jp/how-to/charge/
- PASMO
- 銀行口座からのチャージ機能はなし
- https://www.pasmo.co.jp/charge/
先日スマートフォンのレビュー記事でご紹介した、ICカード決済の煩わしさは、セキュリティとのトレードオフだったんだなと、しみじみ感じます。
銀行口座登録が本人確認という不思議
さて、このように基本的には各サービスにSMS認証が採用されていることが確認できました。
ただ、もうひとつ気になる点があります。
銀行口座の情報を知っている人=利用者本人
というロジックが通っていいのかという点です。
どういうことかというと、今回のドコモ口座では、「銀行口座は銀行側で本人確認しているため、本人確認材料になりうる」という前提のもと、銀行口座の登録による本人確認を認めているということです。
こうなってしまうと、たとえ、他人の口座番号や暗証番号であっても、本人確認の手段になってしまいます。
金融機関によっては、口座番号と暗証番号以外に二段階認証などを含めることで、銀行口座登録時に本人確認を行うのですが、地方銀行などを含め、ほとんどが、行われていないという実態なようでした。
詳しくは以下に掲載のリストが参考になりそうです。
筆者自身も決済手段のうち、いくつのサービスが、銀行口座登録による本人確認を認めているか、調べてみました。
紛らわしくて恐縮ですが、「可」としているサービスが銀行口座登録による本人確認を認めているので、ご注意ください。
なお、各社の情報に基づいて、筆者が解釈した情報なので、実際に利用されている方で、事実と異なる事象を確認された場合、ご連絡いただければと思います。
決済サービス | 銀行口座登録による本人確認 | 備考 |
---|---|---|
d払い(ドコモ口座) | 可 | 2020/9/10 現在新規紐づけ停止中 https://docomokouza.jp/detail/about.html?dcmancr=b1c41d0acc052e62.1599706803461.8325.1599706812932_68897292.1598457716_39 |
PayPay | 可 | https://paypay.ne.jp/guide/auth/ |
メルペイ | 可 | https://www.mercari.com/jp/help_center/article/918/ |
auPAY(auID) | 不可 | じぶん銀行は本人確認書類必須 その他の銀行はローソンのATMで本人確認 https://www.jibunbank.co.jp/account/?code=KD6CMC140506 https://wallet.auone.jp/contents/pc/guide/lawsonbank_charge.html |
楽天ペイ | 不可 | 本人認証サービス(3Dセキュア)が必要。 そもそも、楽天カード、楽天銀行、ラクマ経由のチャージのみ可能 https://pay.rakuten.co.jp/ |
LINE Pay(LINEアカウント) | 可 | http://pay-blog.line.me/archives/75806865.html |
ファミペイ | 可 | チャージはレジorクレジットカードor銀行口座 銀行口座は各金融機関の本人確認に依存しているので実質本人確認可能 https://famidigi.jp/famipay/about-registration/index.html#credit |
J-Coin Pay | 不可 | 本人確認書類が必須 https://j-coin.jp/user/identification/ |
ゆうちょpay | 可 | ただしゆうちょ銀行に限る https://www.jp-bank.japanpost.jp/kojin/sokin/yuchopay/kj_sk_yp_goriyo.html |
この表を見る限り、どのサービスにおいても本人確認を金融機関に依存してしまっているように見えます。
こうなった場合、連携する金融機関次第では、決済サービスも脆弱なサービスとなってしまうわけです。
もちろん、金融機関ごとのセキュリティ向上も必要ですが、サービス事業者も利便性向上ばかりではなく、金融機関を正しく評価した上で連携を実装することも重要になってきますね。
そして、利用者自身も、利便性だけでなく、セキュリティ面を考慮したうえでのサービス利用することが、結果、自分を守ることになるのかなと思います。
被害リスクを低減するために
今回の件に関しては、冒頭から申し上げている通り、ドコモ口座を責めるというのは少し筋が違うと思っています。
その点に関しては、サービス事業者、金融機関、ユーザのリテラシー向上や相互理解が大切かなと思っています。
私自身、ユーザとしての立場で気を付ける点を書いてみたので、参考にしていただければ幸いです。
- 被害リスクを低減するために
- 口座連携のハードルが高い銀行を利用するよう心掛ける
- zaimやマネーフォワードを使っている人ならそのあたりの勘所がわかるかも。
- 連携がめんどくさいほど、セキュリティが強固だという思考に変える。
- ワンタイムパスワードや乱数表の併用が必要な銀行はセキュリティが高いと考えられる。
- 決済サービスを使うこと自体のリスクとは切り離して考えるべき
- 今回もドコモ口座やdアカウントが悪用されたものであり、自身の利用する決済サービスが被害に遭ったわけではない。
- 時代に合わせて、サービスを利用することが、ユーザリテラシーの向上にもつながると思う。
- 口座連携のハードルが高い銀行を利用するよう心掛ける
まとめ
冒頭で述べた通り、個人的にはこういった問題が起きたとき「7Payやばい、2要素認証なしとか草生えるww」とか「ドコモ口座ザルすぎ、わろたww」みたいな事業者を叩く、謎な流れになるのがいやです。
「サービス提供者=悪」で片づけるのではなく、今回顕在化したリスクが、本当に被害に遭ったサービスだけの問題なのか、というところまで考えることが、大人の対応なのかなと思います。
個人の話ですが、小学校の時に、いじめが問題になって、その時の先生の対応を思い出します。
「いじめっ子のA君の何が悪かったかみんなで紙に書いて提出しましょう」
これがその時の先生の対応です。
結果として、いじめっ子をさらにいじめることになっている子の対応に、子どもながらに「やばいな、このおばはん」と思いましたw
もちろん、当人にも非はありますが、そこを叩くことは解決策でも何でもない。
言いたいのはそういうことなんです。
今回の件を通して、少しでもサービス提供者の気持ちになって考えてあげられると、いいのかな、なんて思います。
改訂履歴
2020/09/11
- ドコモ口座からの出金について、「セブン銀行ATMからの出金はドコモキャリア回線契約者のみが可能」とのご指摘をいただき、その旨、公式サイトより事実確認ができたため、修正しました。
- 参考URL https://docomokouza.jp/detail/transfer.html