流出したクレジットカード番号がPayPay経由で使われる懸念 145
ストーリー by hylom
さすがに10回失敗してロック無しはちょっと 部門より
さすがに10回失敗してロック無しはちょっと 部門より
「20%還元キャンペーン」が話題になったキャッシュレス決済サービスPayPayだが、第三者が不正に入手した他人のクレジットカード番号をPayPayに紐付けて不正利用するという被害が出ているという(情報科学屋さんを目指す人のメモ、ITmedia)。
PayPayアプリでのクレジットカードの登録時にはカード番号および有効期限、セキュリティコードの登録が必要となるが、セキュリティコードを間違えてもロックなどの対応が行われないため、総当たり的な攻撃で不正に登録ができてしまう可能性があるとの指摘がある。あるAnonymous Coward曰く、
セキュリティコードを何度間違えてもロックがかからないということは、カード番号も自動生成で総当たりできるということ。例えばvisaならば前6桁は発行元により固定で、生成するカード番号は残り9桁となる(残り1桁はチェックディジット。ロック機構が無ければこれも無意味)。つまり9×60(有効期限5年×12)×999の約53万回、チェックディジットを含めても530万回の試行で他人のカードが登録できてしまう。
PCや今のスマホでも一日あれば突破できてしまうが、これからどうなるのだろうか。
流石のソフトバンク (スコア:5, 参考になる)
不正利用がポイントなのに
「漏洩の事実はない、家族とかを疑え」って声明だけで
やっと
「現時点でリトライ上限がないのは事実ですが、本日以降速やかに対処する予定です」
な状態
自社起因の非はほんと認めないね
Yahooニュースにもこのトラブルについては全く載ってないし
Re:流石のソフトバンク (スコア:2)
Re: (スコア:0)
Yahooニュースにもこのトラブルについては全く載ってないし
「PayPay 不正」の検索結果 - Yahoo!ニュース
https://news.yahoo.co.jp/search/?p=PayPay+%E4%B8%8D%E6%AD%A3 [yahoo.co.jp]
Re:流石のソフトバンク (スコア:1)
ニュースからITなどのトピックに飛んでもそれらの件は1つも表示されないという不思議
https://news.yahoo.co.jp/hl?c=c_sci [yahoo.co.jp]
https://news.yahoo.co.jp/list/?c=computer [yahoo.co.jp]
問題が起きている人は検索でわかるけれど、ニュース側から見つけようとすると、見つからないですよね
Re: (スコア:0)
PayPayがお祭り騒ぎだったから盛り上がってるだけで
大手サイトなら普通程度の問題発生率である可能性もありますしね
PayPayの仕組みは知らんが (スコア:2)
その先のカード会社のサーバで確認するんでしょ
そっちもぶっ通しなのかな?
セキュリティが売り物のカード会社にしてはザルい気がするな
Re:PayPayの仕組みは知らんが (スコア:3)
自分も思った。API使える開発者が悪意持ってたら同じことじゃん、って。
Re:PayPayの仕組みは知らんが (スコア:2)
自分も思った。API使える開発者が悪意持ってたら同じことじゃん、って。
クレカの決済システムなんて、運営に最終的にはバレることに目を瞑れば、こんな面倒な手口をしなくても悪意ある開発者は「客が認識してる金額の10倍を引き落とす」みたいなこともできちゃうよ?
裏を返せばAPIを使える人を絞ることでしか、安全性は担保できないよね。
# 3Dセキュア必須にするとかはできるけど
Re: (スコア:0)
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな
決済かけてないから失敗してもカード会社側は特に検知しないと思う
新規登録でユーザ増えていってるかな?になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
Re: (スコア:0)
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
Re: (スコア:0)
業者(ここでいうPayPay)はカード会社にとっては1ユーザーだけど、PayPayを使うのは大多数。
なので、ユーザーあたりのFailカウントでロックかけると、後者の大多数が影響受けるでしょ。
わかりやすく言えば、携帯回線から誰かがブルートフォースした際に、そのIPアドレスをBANすると、そのIPアドレスを共有してる他の携帯ユーザーもログインできなくなる。
だから、普通は多数で共有してるものをブロックはしないはず。
今回はPayPayの実装が甘かったってことなんだけど、カード会社側でロックするシステムなら、PayPayの競合がブルートフォースかけてPayPayがカード使えなくする攻撃が可能になる。
Re:PayPayの仕組みは知らんが (スコア:2)
その例でいうならカード番号ごとに試行失敗をカウントすりゃいいじゃん
携帯回線でいえばIPアドレスではなくて電話番号で絞ればよいって話
仮に番号を変えながらやったとしても、
トータルで失敗率が上がってきたら対策するとかいろいろ考えられるのでは?
いずれにせよ例に過ぎないので実際には対応が簡単ではないとしても、
実際に破られることが纏めて発生しちゃうんなら
信用を売り買いしてるカード会社にしちゃーへぼいんじゃないかなぁ
今回の件で言うとカード会社ごとの率とかどうなんかね
Re:PayPayの仕組みは知らんが (スコア:2)
何で例えに過ぎない電話番号を送ると思ってるんですかね…
Re:PayPayの仕組みは知らんが (スコア:2)
まず「電話番号」っていうのは誰かが例に出した携帯ネットワークでの識別の話を引いてるだけで
私としては何にも意図はないんですよね
カード会社が電話番号を何かに使ってるとか思ってないです
んでまぁカード番号も暗証等もうまくばらしながらクエリしてくるのをカード会社が検出するのが大変だにしてもですよ、
大変だからやってないんだよね、Paypay経由でヤラレタならPaypayが泥被るからいいんだよ、
とかそんな話にゃならんのじゃないのかなと
不正利用者を許さないというのはカード会社の建前として非常に大切なところでしょ
いろんな手法を使って検出してるとも聞きますし、入り口だけそんなぬるいもんなのかなと
販売業者が多少へぼったからと言って不正利用を許しちゃうっていうのはカード会社として問題ないとは思えないなぁ
今回の件でも調べてみると結局A社のカードは大丈夫だった一方、
B社は抜かれたとかになると辛いだろうなぁ
Re:PayPayの仕組みは知らんが (スコア:2)
何じゃそりゃw
ACにいつもとか言われてもわからんわ
読み取る気のない奴相手にしゃべる気が萎えただけよ
順番にちゃんと読めばわかる話
Re:PayPayの仕組みは知らんが (スコア:2)
「対応してるところはしてる」ってのは有りそうなはなしで、
Paypayに置かれましては今回の問題で突破されたカードの種類とか公表してほしいもんだ
多分しがらみとか契約でダメだろうけど
Re:PayPayの仕組みは知らんが (スコア:2)
一番大事な信用に傷がつくと思いますがねぇ
悪用されているか確認するためにPayPayに登録する (スコア:2)
うわーあくどいマッチポンプの香り(棒
セキュリティコードの扱いがザルすぎるのがなんとも
Re:悪用されているか確認するためにPayPayに登録する (スコア:1)
すでに別のIDに紐づくカードでも、登録できちゃうという話…
つまり、カードを持っていたらPayPayつかってようがつかっていまいが
PayPayアプリを通じて不正利用されるリスクが発生するので…いのれ!
Re:悪用されているか確認するためにPayPayに登録する (スコア:2)
PayPay での登録で、ロックされるようになっていたとしても... (スコア:2)
星の数ほどカード情報を入力するサイトはあるのだから、あるサイトでロックしても、別のサイトで試行する、というのを繰り返せば、セキュリティコードの桁数はたかが知れているから推定できる。
と考えると、PayPay 側がロックしない事が問題なのではなくて、カード会社側が、同一カード番号に対する NG 回数とかでロックしない事が問題な気がしてくる。
Re:PayPay での登録で、ロックされるようになっていたとしても... (スコア:1)
そういう不正利用を防ぐために3Dセキュアとかあるわけなんだから
3Dセキュアに対応してないサイトでは、3Dセキュア有効にしたカードは使えないようにしてほしいけど…
Re: (スコア:0)
その辺はECサイトによりけり
チャージバックを自社で受け持つなら3D対応しているが未登録カードでも決済可
チャージバックを保険会社なんかで受け持って貰う場合には3DS登録済みじゃないと決済できないとか
考え方次第
Re:PayPay での登録で、ロックされるようになっていたとしても... (スコア:1)
その場合、ユーザーが「気づくことが出来れば」普通に取り消されるんだけど
気づけなかった場合普通に通っちゃいますよね
それを防止しようとしたら、ユーザ側で3Dセキュアとかを有効にしているわけなんだから
有効じゃないところでは買い物しないよってフラグを建てさせてほしいっていう事
そうすれば、3Dセキュアが突破されたら不正利用はされるけど
カード情報が判明しただけでは不正利用されることはなくなるのではないかと
わけて考えよう (スコア:2, すばらしい洞察)
「PayPayより酷いサイトなんて珍しくない」ってのと「PayPayに非はない」は別問題ですよ
Re: (スコア:0)
今回は、「クレジットカードの推測、不正利用ができるプラットフォームを提供してしまった」っていう不祥事になるね
Re:わけて考えよう (スコア:1)
必死っすなぁ
制限と利便性はトレードオフなのでcheckで制限かかからんのは正常動作
Authで制限かかるはずなのでそっちも正常動作
だから、対面で暗証番号3回間違うと使えなくなるでしょ?あれはAuthでやってるから。
今時TDSなしなんてチャージバック責任は代理店なので今回はPayPayがひっかぶるかと思いますよ
で、カード会社からもその辺は指摘された上で契約しているはずなので悪いのはPayPayですよ。
多分、もう終わった話 (スコア:1)
クレカ番号自体はPayPayのせいで流出した毛ではなくて、もっと前に流出してたものだろう。
で、なぜPayPayが標的にされたかというと、例の100億キャンペーンでなんか異常な金の使い方をする人が突然大量に沸いたので、それに紛れて使ったらカード会社のチェックが追い付かなくなるだろう、ということで便乗されて使われていた可能性が高い。
100億円キャンペーンが終了してしまったので、犯人集団はもうとんずらこいた後でしょうな。コンビニとか家電量販店でiTunesカードとかAmazonギフトカードでも買ってたんじゃないですかね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re: (スコア:0)
クレカ番号はある程度使われてるであろう番号を簡単に生成できるソフトが既にある
つまりクレカ番号を生成してあとは書いてある通り
Re: (スコア:0)
カード番号が流出していたとしても
PayPayのおかげでセキュリティコードと有効期限を特定することができたのでは?
当たり前の話だが、その情報はPayPay以外でも使うことができますよね
Re: (スコア:0)
また毛の話してる(AA略)
Re: (スコア:0)
一応真面目な話をすると、PayPayでiTunesカードやAmazonギフトカードは買えません。
ロックがあっても… (スコア:1)
やばいよねー。
https://tech.nikkeibp.co.jp/it/atcl/idg/14/481709/120600279/ [nikkeibp.co.jp]
計算が雑 (スコア:1)
PCや今のスマホでも一日あれば突破できてしまうが
暗号解読のようなものならオフラインで高速に試行を繰り返せるけど、カード番号の総当たりはサーバからのレスポンスを待つ必要がある。
チェックディジット間違いを繰り返してもロックしないくらいだから同一IPから短時間に繰り返しアクセスもロックしないと仮定して24時間で53万回トライすると秒間約6回の間隔。不可能とはいえないけどちょっと厳しそう。
ただしこれは53万通りのうち有効な番号の組み合わせがひとつしかない場合。
現実にはそんなことありえなくて、カード発行元によっては万単位の「あたり」が存在すると思われるので、数百回か悪くても数千回のチャレンジで十分成功が見込めそう。
うじゃうじゃ
Re: (スコア:0)
カード決済ネットワークに流すのに端末から投げるわけない
普通にPayPayサーバから投げられるから分からん
で、セキュリティコードも暗号の一種
カード番号とカード会社のパラメータを使って算出しているだけ
Re:計算が雑 (スコア:1)
セキュリティコードの算出が目的ならそういう理屈も成り立ちますが、セキュリティコードやチェックディジットに矛盾はなくても空き(未使用)の番号や未払いなどで停止された番号、すでにPayPayに登録済みの番号はサーバに投げてみないことには確認のしようがないですよ。
うじゃうじゃ
Re:計算が雑 (スコア:1)
53万通りのうち有効な番号の組み合わせがひとつしかないでしょ
ぜんぜん違います。
この場合「一つのカード番号」に対応するセキュリティコードや有効期限を探すわけではなく、「まだPayPayに登録されていなくて、未使用番号やカード会社の方で停止措置などをしていない番号」でありさえすればいいので、有効な番号の組み合わせは数千とか数万のオーダーで存在しますよ。
うじゃうじゃ
Re:計算が雑 (スコア:1)
勘違いしていたのに気づきました。
確かにカード番号も込みの総当たりだったら530万でもぜんぜん少ないですね。
うじゃうじゃ
計算方法 (スコア:1)
総当たり攻撃の必要回数って、カード発行元に割り当てられた、9桁の数字(10億)のうち、実際に有効なカードの枚数がわからないと計算できないのではないでしょうか?
はじめの "9" というのが、その値だとすると、発行枚数が多いところでは、1億枚程度有効なカードがあるということでしょうか?
Re:計算方法 (スコア:1)
ただ、"約53万回" というのに辻褄を合わせようとすれば、"10^9" ではなく、やはりただの "9" なのでしょう。
それに、10^9 枚のカードから 1枚だけを探し出す必要もないでしょうから?
あれ? カード番号、有効期限、セキュリティコードの他に、氏名は照合しないのでしょうか?
PayPayはともかくチェックサムを理解してない人はどれだけいるのだろう (スコア:0)
残り1桁はチェックディジット。ロック機構が無ければこれも無意味
チェックディジットを含めても530万回の試行
hylom、チェックディジットの意味わかってる?
Re:PayPayはともかくチェックサムを理解してない人はどれだけいるのだろう (スコア:1)
間違えてる人も結構いると思うよ
この計算方法を書こうとした人が攻められてるのをみたことがある。不正に加担するのかって
カード番号の不正をチェックするものでなく、単純な入力ミスや読み取りミスなど
チェックするもので、計算方法など怪しいサイトでなくても手に入る。
Re:PayPayはともかくチェックサムを理解してない人はどれだけいるのだろう (スコア:1)
と言うかWikipediaにすら載っている
https://ja.wikipedia.org/wiki/Luhn%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA... [wikipedia.org]
Re: (スコア:0)
チェックディジットは正しいものを計算で求められるけど、
計算式がわからなくても10倍の回数試行すれば1カード番号につき0-9の10回試行すれば当たっちゃうわけでね。
あってるよ。
Re:PayPayはともかくチェックサムを理解してない人はどれだけいるのだろう (スコア:2)
ロック機構が無ければ試行回数を無限にできるから
以後 (#3534968) じゃないのでしょうか
試行回数が無限なら何も考えなくてよく単にブルートフォース対象桁を増やすだけでいいから、
チェックデジットが何桁とか考える必要さえない。ただ機械ががんばるだけ。
もちろん試行回数が多くはなるけど
ということを考慮して
「チェックデジットのことをその性質を無視して10倍の試行回数として扱ったとして『も』この程度の試行回数にしかならない」、の「も」
が「チェックディジットを含めても」の『も』なのだと思います
このため、勘違いしていることが自明だとは私も感じません
逆にどういう勘違いをしていればこのように書くとお思いでしょうか
Re:PayPayはともかくチェックサムを理解してない人はどれだけいるのだろう (スコア:2)
うーんそれはチェックデジットを知らないのは誰なんだ、ってことだ思うんですよね
チェックデジットがどこでどういう式か、を知っていれば実質9桁
まったく知らなければ10桁相当なわけですよね。
仮に「攻撃者が」チェックデジットを知らなければ一桁防御力が上がるんだが、
ロック機構が無ければ一桁上がっても意味がない
ってことを言いたいんだと思いましたね
「仮に攻撃者がチェックデジットを知らなかったとしてもこんなに攻撃は容易である(知らないはずはないので本当に危険だ)」
と言う文であって、書いた人が知らないことは示してない、
示すとは限らないんじゃないかなぁ
私としてはどちらにも取れれば無知とみなすという判断にはならないですね
API (スコア:0)
どっかの決済サービスのAPI使ってそうなんだけどどこだろ
糞構築ならこんなザル決済サイトもできてしまうんだなー
こんな構築できない仕組みになってるんだと思ってた
Re:API (スコア:2)
実は普通に作ると数回でロックアウトされちゃうので
「ユーザビリティが低い」とかで問題になって
現場の担当者は嫌だ無理だというのに何とかしろとねじ込まれ、
トークンを多数使うとかで無理やり制限なくしてた
とかだと傍から見てる分には面白いな
名前いらないのね (スコア:0)
カード会社側への照会の話。
カード会社側は名前無しにチェックしてるんですね。
Re:名前いらないのね (スコア:1)