みっきー申す

ITに関する興味関心のまとめ、サイバーセキュリティニュースのまとめ、Twitterで配信中の情報まとめなどを公開します。

PayPayやメルペイは関係ないでいいんだっけ?ドコモ口座の不正送金問題を踏まえた考察

9月8日ごろから話題になっている、「ドコモ口座を悪用した不正送金問題」について、当ブログでも深堀りをしようと思い、まとめることにしました。

www.nikkei.com

以前、7pay事件の際にも、記事を書きましたが、ちょっと似たような空気を感じています。

micro-keyword.hatenablog.com

理由については、記事の最後で書きますが、まずは本題から行きましょう。


目次


まずは不正送金の流れを確認

まず、今回の不正送金の流れを図でご説明します。

f:id:micro_keyword:20200911145004j:plain


攻撃者はどうやって暗証番号を入手するのか

攻撃者ははじめに、何らかの方法で口座番号、名義、暗証番号などを入手します。

暗証番号の入手に関しては、別のサービス経由で漏洩している場合もありますが、今回の攻撃では、リバースブルートフォースという手法で取得された可能性が指摘されています。

リバースブルートフォースは、ブルートフォースの逆で、パスワードを固定し、口座番号を総当たりで特定する手法です。

f:id:micro_keyword:20200910234619j:plain

暗証番号は連続で失敗すると、アカウントロックがかかりますが、その逆はロック対象のアカウントがそれぞれ異なるので、アカウント単位でのロックができません。

リバースブルートフォースの対策としては、単にID・パスワードの認証だけではなく、後述するSMS認証を挟むことや、秘密の質問やCAPTCHAなど別の認証を挟むことが挙げられます。

あとは、一定時間のログイン拒否や同一パスワードを使うユーザの強制ロックなどがありますが、ユーザの利便性を大きく損なうのであまり対策としてはお勧めできません。

では、本来リバースブルートフォース対策となりうる、SMS認証について掘り下げます。


なぜ自身の銀行口座が他人のアカウントに紐づくのか

ドコモ口座を例に挙げると、銀行口座の連携には、dアカウントを作成した後、ドコモ口座を作成し、銀行口座と結びつけることで口座利用が可能になります。

f:id:micro_keyword:20200910234633j:plain

これ自体の仕組みは、ドコモ口座ないしdアカウントに限らず、PayPayやメルペイなどの決算手段においても、あまり変わりはなさそうです。

では、ドコモ口座の何がまずかったのかというと、dアカウントの作成ハードルが非常に低く、攻撃者が悪用後すぐに破棄することで足がつきにくいという点です。

dアカウントは、他の電子決済サービスに使われるアカウントとは異なり、Eメールアドレスのみで作成可能で、作成が非常に容易です。

この点に関しては、NTTドコモが対策に踏み切っており、現在dアカウント作成時には、SMSを利用した2段階認証が必須です。

mainichi.jp

すでに、公式ページでのアカウント作成手順も変更されていて、これまでがどうだったかを示す素材がなかったのですが、以下のブログに手順が残っていたので、気になる方はご確認ください。

estpolis.com


攻撃者目線で考えるSMS認証の重要性

文章だと分かりづらいと思い、こちらも筆者が想定する攻撃シナリオとして図を作成したので、ご参考にしてください。

f:id:micro_keyword:20200911145534j:plain

もし、SMS認証があれば、dアカウント作成の段階で、電話番号を所持している個人に目星が付くので、少なくともEメールアドレスよりも攻撃者にとってはリスクが上がります。

さて、ここで気になってくるのが、他の決済サービスではアカウント作成時に2段階認証を導入しているのかという点です。

2段階認証の有無で、先述の通り、攻撃者の利用ハードルが下がります。


SMS認証に対応している決済サービス

以下の、マイナポイント人気決済サービスを参考に、決済手段に対し、銀行口座からのチャージをおこなう前に、2段階認証が導入されているかどうか、状況を確認してみましたので、ご活用ください。

news.mynavi.jp

決済サービス 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も相当ハードルが高かったです。

先日スマートフォンのレビュー記事でご紹介した、ICカード決済の煩わしさは、セキュリティとのトレードオフだったんだなと、しみじみ感じます。

micro-keyword.hatenablog.com


銀行口座登録が本人確認という不思議

さて、このように基本的には各サービスにSMS認証が採用されていることが確認できました。

ただ、もうひとつ気になる点があります。

銀行口座の情報を知っている人=利用者本人

というロジックが通っていいのかという点です。

どういうことかというと、今回のドコモ口座では、「銀行口座は銀行側で本人確認しているため、本人確認材料になりうる」という前提のもと、銀行口座の登録による本人確認を認めているということです。

こうなってしまうと、たとえ、他人の口座番号や暗証番号であっても、本人確認の手段になってしまいます。

金融機関によっては、口座番号と暗証番号以外に二段階認証などを含めることで、銀行口座登録時に本人確認を行うのですが、地方銀行などを含め、ほとんどが、行われていないという実態なようでした。

詳しくは以下に掲載のリストが参考になりそうです。

piyolog.hatenadiary.jp

筆者自身も決済手段のうち、いくつのサービスが、銀行口座登録による本人確認を認めているか、調べてみました。

紛らわしくて恐縮ですが、「可」としているサービスが銀行口座登録による本人確認を認めているので、ご注意ください。

なお、各社の情報に基づいて、筆者が解釈した情報なので、実際に利用されている方で、事実と異なる事象を確認された場合、ご連絡いただければと思います。

決済サービス 銀行口座登録による本人確認 備考
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