アカウント名:
パスワード:
その先のカード会社のサーバで確認するんでしょそっちもぶっ通しなのかな?セキュリティが売り物のカード会社にしてはザルい気がするな
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな決済かけてないから失敗してもカード会社側は特に検知しないと思う新規登録でユーザ増えていってるかな?になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
業者(ここでいうPayPay)はカード会社にとっては1ユーザーだけど、PayPayを使うのは大多数。なので、ユーザーあたりのFailカウントでロックかけると、後者の大多数が影響受けるでしょ。
わかりやすく言えば、携帯回線から誰かがブルートフォースした際に、そのIPアドレスをBANすると、そのIPアドレスを共有してる他の携帯ユーザーもログインできなくなる。だから、普通は多数で共有してるものをブロックはしないはず。
今回はPayPayの実装が甘かったってことなんだけど、カード会社側でロックするシステムなら、PayPayの競合がブルートフォースかけてPayPayがカード使えなくする攻撃が可能になる。
その例でいうならカード番号ごとに試行失敗をカウントすりゃいいじゃん携帯回線でいえばIPアドレスではなくて電話番号で絞ればよいって話
仮に番号を変えながらやったとしても、トータルで失敗率が上がってきたら対策するとかいろいろ考えられるのでは?
いずれにせよ例に過ぎないので実際には対応が簡単ではないとしても、実際に破られることが纏めて発生しちゃうんなら信用を売り買いしてるカード会社にしちゃーへぼいんじゃないかなぁ
今回の件で言うとカード会社ごとの率とかどうなんかね
だから、それはPayPay側の実装の話であってカード会社側システムで防ぐもんじゃない決済ネットワークなんてカード番号、有効期限、セキュリティコード、TDSリザルト、氏名ぐらいしか使わん
なんで決済ネットワークに電話番号やら何やら送ると思ってんだよ
何で例えに過ぎない電話番号を送ると思ってるんですかね…
paypayのユーザーアカウントって電話番号そのものじゃなかったっけ?
たぶんカード会社には電話番号なんて送ってないと思うぞあとPayPayっつーかSBPS側で同じカード番号に対する試行回数制限とかやろうと思えばまぁ出来るだろうけど、それでSBPS判断で止めていいかっていうと、事前にカード会社と調整しとかんと不味いんではないかなぁちゃんとしたカード会社ならモニタリングで引っかかったカードは一時停止とかするし
っていうか単純にカード登録するときに3Dセキュアで少額与信しとけば済む話なんだがな
電話番号に限らず、カード会社側APIとして利用者あたりに有限と仮定できなくもない識別情報(電話番号、IPアドレス、ユーザID、店舗レジID等)を必須項目には出来ていないだろうって話でしょう。
オンラインで暗証番号固定してカード番号に総当りを仕掛けるのを回数で弾いて防ぐ場合、攻撃者が無数に確保するのが難しい識別情報に対して試行回数をカウントするしかない。でも、店舗形態ごとに提供できうる識別情報は異なるので統一の基準で識別情報を強制することは不可能。何パターンかから選択制で用意する(してる)にしても今回のようなノーチェックが選択肢にあるなら無いのと同じこと。
無数に確保するのは難しい情報でってお前はBOTネットワークも知らんの?未だに何万台のノードがいると思ってんの?
まず「電話番号」っていうのは誰かが例に出した携帯ネットワークでの識別の話を引いてるだけで私としては何にも意図はないんですよねカード会社が電話番号を何かに使ってるとか思ってないです
んでまぁカード番号も暗証等もうまくばらしながらクエリしてくるのをカード会社が検出するのが大変だにしてもですよ、大変だからやってないんだよね、Paypay経由でヤラレタならPaypayが泥被るからいいんだよ、とかそんな話にゃならんのじゃないのかなと
不正利用者を許さないというのはカード会社の建前として非常に大切なところでしょいろんな手法を使って検出してるとも聞きますし、入り口だけそんなぬるいもんなのかなと販売業者が多少へぼったからと言って不正利用を許しちゃうっていうのはカード会社として問題ないとは思えないなぁ
今回の件でも調べてみると結局A社のカードは大丈夫だった一方、B社は抜かれたとかになると辛いだろうなぁ
カード会社によると思うけど対応してるところはしてるのでは?
でもって流出させたのは明確にPaypayとか代行サービス側でカード会社としては知らねーよ、が基本スタンス。さらに言うとカード不正利用の保証は顧客に対して適切にされると思うのでむしろブッ殺すぞ! くらいをPaypayに思ってはいると思う。つまり上記のようなカード不正利用の担保をどのくらい減らすが((マグネットからICチップ対応もその類)が一つのモチベーション。
今回は自動生成もできるから困ったもんだけど、そんなバカをこんな大手がするとは、、、ってのが感想かなー。
君の文章が下手すぎて、実装例と例え話が混在している上に論旨がブレまくってるからでしょ。
細かい話になると、いつもいろんな手法とかでごまかして逃げるのね。無知なら無知なりにもう少し謙虚にするか、せめて少しでも調べてから喋ればいいのにね。
何じゃそりゃwACにいつもとか言われてもわからんわ読み取る気のない奴相手にしゃべる気が萎えただけよ順番にちゃんと読めばわかる話
「対応してるところはしてる」ってのは有りそうなはなしで、Paypayに置かれましては今回の問題で突破されたカードの種類とか公表してほしいもんだ
多分しがらみとか契約でダメだろうけど
だからまぁCAPTCHAかなんかやDDoS対策も組み合わせる必要もあって、そのへんの統一規則考えるとAPIでは対処がまず無理なのよな。カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ?
IPアドレスを共有してるユーザーっているんだ。
192.168.0.1 かな。
WiFiを使う場合などは言うまでもなくマンション等でも普通にプライベートIPが割り振られるし、SIMを使うモバイル網でもキャリアグレードNAT(100.64.0.0/10)がかかっているのは珍しくないですよ。スマートフォンとかで 100.xx.xxx.xxx とか普通に割り振られてませんか?
ま、だからといって、総当りに対する対策がとられてないのはお粗末ですな・・・。PayPay側でなら電話番号でもIMEIでも使えそうなものはいっぱいありそうですが・・。
カード利用でメール等で通知が飛んでくるカード会社って少ないんですよね・・・。
文盲だな、分からないなら口出さなきゃいいのに
PayPayサーバからオーソリ投げる決済ネットワークはPayPayユーザで共有して一つしかないだろだから、PayPay止めたい奴が適当なカード番号で連打すればサービス停止攻撃出来ちゃうでしょって話な誰がカード番号共有なんて話をしてるんだ、お前だけだぞ
決済ネットワーク単位でまるごと止めるんじゃなくてカード番号単位で止めればいいのでは?って話だと思ってたんだけど
本来のカードホルダーの決済すらとまんだろ馬鹿らしい
止まらずに不正利用されるよりはずっと良い。
それならPayPayからの照会ってのとカード番号両方合わせて絞ればいい話じゃない思考停止にもほどがあるんじゃ無いか?そんなにカード会社の無謬を主張する理由がわからんわ
よく知らんけど。タレコミ記事からはpaypayの仕様の問題とpaypayが悪用されているらしい話、コメントからは実例の有無は定かではないものの、paypayへの攻撃でカード番号等を得て他社システムで使えるというパターンを話してる人がいますね。
ま、とりあえず多社間でつないでるシステムの改修よりはpaypay内でできる改修をやったほうがいいんじゃないでしょうか。
リバースブルートフォース攻撃が容易なので無駄。攻撃者が大量に用意できないトークン単位で試行回数に制限を掛ける必要がある。
クレジットカードの信用(クレジット)が揺らぐんでカード会社側からサービス拒否してもいいんじゃないかくらいにカード会社側システムもやばい話だと思うよ。それのみで成立してて資本が大きいからカード会社側からのサービス拒否は難しいだろうけど……だからってこんな問題の発生を許した上に対処の遅れをカード会社側が許容したとなると、ちょっとね。
>それならPayPayからの照会ってのとカード番号両方合わせて絞ればいい話じゃないただ、それだと #354867 [srad.jp] みたいなのは防げないんですよね。これを防ぐには、結局カード会社側で、決済ネットワークによらず同一のカード番号に対する失敗回数で制限をかけないとならないでしょうね。
顧客で何もとりあえずチェックを通せるカード番号なんて決済やってりゃわかるよ?大層なもんでもなく有効性検証は決済ネットワーク流さなきゃ分からないので先頭6桁はブランドと発行元で決まってるので残りの桁適当に埋めても流しに行くよ
もしくはバニラVISAでもJCBプリモでもKyashでもカード番号なんて手に入るよ?ねぇ、無知なのになんで偉そうに書いてんの?
すまんな、先に #3534867 とかを読んでたから『PayPay の決済ネットワークだけを通して攻撃する』前提だと思ってなかったわ
ええっと「洗替システム」使ってんの?それって使っていいのかしらと言うのが一点と、実はwせdrftgyふいおな仕様なので、何回もやらなくてもいいような気がしてきた……(((( ;゚Д゚)))ガクガクブルブル
めんどくせいからここにぶら下げておくけど大抵第三者がいう対策は考えられている。その上で実施されていない。何故か?そう言った問題を防ぎたいなら上で言われてるようにAuth使えって話。Checkは「カード有効性しかしない」のだからいいのカード会社の仕様が間違ってんじゃなくって使う処理を間違えているだけじゃないのかな?
こうすればいい、ああすればいいじゃないよ実際どういう実装してたのかは分からんがAuthで少額決済してたら防げたと思うよ
https://tech.nikkeibp.co.jp/it/atcl/idg/14/481709/120600279/ [nikkeibp.co.jp] って、まさにその Check の仕様の問題を突かれているわけではないの?
これも Check の使い方を間違っている (Auth を使うべきところで Check を使っている) ということ?
記事に書いてあるのに読めないのはちょっとカード会社側で最終的に不正検知に引っかかって落とされるリスクは上がってるけど割り出すだけじゃら複数のサイトでオーソリ投げれば試行回数は事実上いくらでもあるっていう記事に対してオーソリだチェックだって何を言ってるんだ
オーソリだチェックだってのは (#3535282) がそう説明してるから言ったのであって、こっちが問題にしてるのは『試行回数は事実上いくらでもある』ことに対してカード会社側で対策する気はないの? ってことなんだけど。
他のツリーで『カード番号でロックをかけたら正規の利用も出来なくなるからダメ!』って話があるけど、不正利用されるくらいなら正規の利用が一時的に制限される方がマシという考え方も有りえるでしょ。
これまた他のツリーにあるとおり、カード会社としては不正利用絶対阻止! という考えではなくて、確認でき次第キャンセル・返金して、保険でカバーできれば問題ないと考えているのでしょうけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
PayPayの仕組みは知らんが (スコア:2)
その先のカード会社のサーバで確認するんでしょ
そっちもぶっ通しなのかな?
セキュリティが売り物のカード会社にしてはザルい気がするな
Re:PayPayの仕組みは知らんが (スコア:0)
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな
決済かけてないから失敗してもカード会社側は特に検知しないと思う
新規登録でユーザ増えていってるかな?になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
Re: (スコア:0)
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
Re: (スコア:0)
業者(ここでいうPayPay)はカード会社にとっては1ユーザーだけど、PayPayを使うのは大多数。
なので、ユーザーあたりのFailカウントでロックかけると、後者の大多数が影響受けるでしょ。
わかりやすく言えば、携帯回線から誰かがブルートフォースした際に、そのIPアドレスをBANすると、そのIPアドレスを共有してる他の携帯ユーザーもログインできなくなる。
だから、普通は多数で共有してるものをブロックはしないはず。
今回はPayPayの実装が甘かったってことなんだけど、カード会社側でロックするシステムなら、PayPayの競合がブルートフォースかけてPayPayがカード使えなくする攻撃が可能になる。
Re:PayPayの仕組みは知らんが (スコア:2)
その例でいうならカード番号ごとに試行失敗をカウントすりゃいいじゃん
携帯回線でいえばIPアドレスではなくて電話番号で絞ればよいって話
仮に番号を変えながらやったとしても、
トータルで失敗率が上がってきたら対策するとかいろいろ考えられるのでは?
いずれにせよ例に過ぎないので実際には対応が簡単ではないとしても、
実際に破られることが纏めて発生しちゃうんなら
信用を売り買いしてるカード会社にしちゃーへぼいんじゃないかなぁ
今回の件で言うとカード会社ごとの率とかどうなんかね
Re: (スコア:0)
だから、それはPayPay側の実装の話であってカード会社側システムで防ぐもんじゃない
決済ネットワークなんてカード番号、有効期限、セキュリティコード、TDSリザルト、氏名ぐらいしか使わん
なんで決済ネットワークに電話番号やら何やら送ると思ってんだよ
Re:PayPayの仕組みは知らんが (スコア:2)
何で例えに過ぎない電話番号を送ると思ってるんですかね…
Re: (スコア:0)
paypayのユーザーアカウントって電話番号そのものじゃなかったっけ?
Re: (スコア:0)
たぶんカード会社には電話番号なんて送ってないと思うぞ
あとPayPayっつーかSBPS側で同じカード番号に対する試行回数制限とかやろうと思えばまぁ出来るだろうけど、
それでSBPS判断で止めていいかっていうと、事前にカード会社と調整しとかんと不味いんではないかなぁ
ちゃんとしたカード会社ならモニタリングで引っかかったカードは一時停止とかするし
っていうか単純にカード登録するときに3Dセキュアで少額与信しとけば済む話なんだがな
Re: (スコア:0)
電話番号に限らず、カード会社側APIとして利用者あたりに有限と仮定できなくもない識別情報(電話番号、IPアドレス、ユーザID、店舗レジID等)を必須項目には出来ていないだろうって話でしょう。
オンラインで暗証番号固定してカード番号に総当りを仕掛けるのを回数で弾いて防ぐ場合、攻撃者が無数に確保するのが難しい識別情報に対して試行回数をカウントするしかない。
でも、店舗形態ごとに提供できうる識別情報は異なるので統一の基準で識別情報を強制することは不可能。
何パターンかから選択制で用意する(してる)にしても今回のようなノーチェックが選択肢にあるなら無いのと同じこと。
Re: (スコア:0)
無数に確保するのは難しい情報でってお前はBOTネットワークも知らんの?
未だに何万台のノードがいると思ってんの?
Re:PayPayの仕組みは知らんが (スコア:2)
まず「電話番号」っていうのは誰かが例に出した携帯ネットワークでの識別の話を引いてるだけで
私としては何にも意図はないんですよね
カード会社が電話番号を何かに使ってるとか思ってないです
んでまぁカード番号も暗証等もうまくばらしながらクエリしてくるのをカード会社が検出するのが大変だにしてもですよ、
大変だからやってないんだよね、Paypay経由でヤラレタならPaypayが泥被るからいいんだよ、
とかそんな話にゃならんのじゃないのかなと
不正利用者を許さないというのはカード会社の建前として非常に大切なところでしょ
いろんな手法を使って検出してるとも聞きますし、入り口だけそんなぬるいもんなのかなと
販売業者が多少へぼったからと言って不正利用を許しちゃうっていうのはカード会社として問題ないとは思えないなぁ
今回の件でも調べてみると結局A社のカードは大丈夫だった一方、
B社は抜かれたとかになると辛いだろうなぁ
Re: (スコア:0)
カード会社によると思うけど対応してるところはしてるのでは?
でもって流出させたのは明確にPaypayとか代行サービス側でカード会社としては知らねーよ、が基本スタンス。
さらに言うとカード不正利用の保証は顧客に対して適切にされると思うのでむしろブッ殺すぞ! くらいをPaypayに思ってはいると思う。
つまり上記のようなカード不正利用の担保をどのくらい減らすが((マグネットからICチップ対応もその類)が一つのモチベーション。
今回は自動生成もできるから困ったもんだけど、そんなバカをこんな大手がするとは、、、ってのが感想かなー。
Re: (スコア:0)
君の文章が下手すぎて、実装例と例え話が混在している上に論旨がブレまくってるからでしょ。
Re: (スコア:0)
細かい話になると、いつもいろんな手法とかでごまかして逃げるのね。
無知なら無知なりにもう少し謙虚にするか、せめて少しでも調べてから喋ればいいのにね。
Re:PayPayの仕組みは知らんが (スコア:2)
何じゃそりゃw
ACにいつもとか言われてもわからんわ
読み取る気のない奴相手にしゃべる気が萎えただけよ
順番にちゃんと読めばわかる話
Re:PayPayの仕組みは知らんが (スコア:2)
「対応してるところはしてる」ってのは有りそうなはなしで、
Paypayに置かれましては今回の問題で突破されたカードの種類とか公表してほしいもんだ
多分しがらみとか契約でダメだろうけど
Re: (スコア:0)
だからまぁCAPTCHAかなんかやDDoS対策も組み合わせる必要もあって、そのへんの統一規則考えるとAPIでは対処がまず無理なのよな。
カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ?
Re: (スコア:0)
IPアドレスを共有してるユーザーっているんだ。
192.168.0.1 かな。
Re: (スコア:0)
IPアドレスを共有してるユーザーっているんだ。
192.168.0.1 かな。
WiFiを使う場合などは言うまでもなくマンション等でも普通にプライベートIPが割り振られるし、
SIMを使うモバイル網でもキャリアグレードNAT(100.64.0.0/10)がかかっているのは珍しくないですよ。
スマートフォンとかで 100.xx.xxx.xxx とか普通に割り振られてませんか?
ま、だからといって、総当りに対する対策がとられてないのはお粗末ですな・・・。
PayPay側でなら電話番号でもIMEIでも使えそうなものはいっぱいありそうですが・・。
カード利用でメール等で通知が飛んでくるカード会社って少ないんですよね・・・。
Re: (スコア:0)
文盲だな、分からないなら口出さなきゃいいのに
PayPayサーバからオーソリ投げる決済ネットワークはPayPayユーザで共有して一つしかないだろ
だから、PayPay止めたい奴が適当なカード番号で連打すればサービス停止攻撃出来ちゃうでしょって話な
誰がカード番号共有なんて話をしてるんだ、お前だけだぞ
Re: (スコア:0)
決済ネットワーク単位でまるごと止めるんじゃなくてカード番号単位で止めればいいのでは?
って話だと思ってたんだけど
Re: (スコア:0)
本来のカードホルダーの決済すらとまんだろ
馬鹿らしい
Re: (スコア:0)
止まらずに不正利用されるよりはずっと良い。
Re: (スコア:0)
それならPayPayからの照会ってのとカード番号両方合わせて絞ればいい話じゃない
思考停止にもほどがあるんじゃ無いか?
そんなにカード会社の無謬を主張する理由がわからんわ
Re: (スコア:0)
よく知らんけど。
タレコミ記事からはpaypayの仕様の問題とpaypayが悪用されているらしい話、
コメントからは実例の有無は定かではないものの、paypayへの攻撃でカード番号等を得て他社システムで使えるというパターンを話してる人がいますね。
ま、とりあえず多社間でつないでるシステムの改修よりはpaypay内でできる改修をやったほうがいいんじゃないでしょうか。
Re: (スコア:0)
リバースブルートフォース攻撃が容易なので無駄。
攻撃者が大量に用意できないトークン単位で試行回数に制限を掛ける必要がある。
Re: (スコア:0)
クレジットカードの信用(クレジット)が揺らぐんでカード会社側からサービス拒否してもいいんじゃないかくらいにカード会社側システムもやばい話だと思うよ。
それのみで成立してて資本が大きいからカード会社側からのサービス拒否は難しいだろうけど……
だからってこんな問題の発生を許した上に対処の遅れをカード会社側が許容したとなると、ちょっとね。
Re: (スコア:0)
>それならPayPayからの照会ってのとカード番号両方合わせて絞ればいい話じゃない
ただ、それだと #354867 [srad.jp] みたいなのは防げないんですよね。
これを防ぐには、結局カード会社側で、決済ネットワークによらず
同一のカード番号に対する失敗回数で制限をかけないとならないでしょうね。
Re: (スコア:0)
顧客で何もとりあえずチェックを通せるカード番号なんて決済やってりゃわかるよ?
大層なもんでもなく有効性検証は決済ネットワーク流さなきゃ分からないので
先頭6桁はブランドと発行元で決まってるので残りの桁適当に埋めても流しに行くよ
もしくはバニラVISAでもJCBプリモでもKyashでもカード番号なんて手に入るよ?
ねぇ、無知なのになんで偉そうに書いてんの?
Re: (スコア:0)
すまんな、先に #3534867 とかを読んでたから
『PayPay の決済ネットワークだけを通して攻撃する』前提だと
思ってなかったわ
Re: (スコア:0)
ええっと「洗替システム」使ってんの?
それって使っていいのかしらと言うのが一点と、実は
wせdrftgyふいおな仕様なので、何回もやらなくてもいいような気がしてきた……(((( ;゚Д゚)))ガクガクブルブルRe: (スコア:0)
めんどくせいからここにぶら下げておくけど大抵第三者がいう対策は考えられている。
その上で実施されていない。
何故か?そう言った問題を防ぎたいなら上で言われてるようにAuth使えって話。
Checkは「カード有効性しかしない」のだからいいの
カード会社の仕様が間違ってんじゃなくって使う処理を間違えているだけじゃないのかな?
こうすればいい、ああすればいいじゃないよ
実際どういう実装してたのかは分からんがAuthで少額決済してたら防げたと思うよ
Re: (スコア:0)
https://tech.nikkeibp.co.jp/it/atcl/idg/14/481709/120600279/ [nikkeibp.co.jp] って、まさにその Check の仕様の問題を突かれているわけではないの?
これも Check の使い方を間違っている (Auth を使うべきところで Check を使っている) ということ?
Re: (スコア:0)
記事に書いてあるのに読めないのはちょっと
カード会社側で最終的に不正検知に引っかかって落とされるリスクは上がってるけど
割り出すだけじゃら複数のサイトでオーソリ投げれば試行回数は事実上いくらでもあるっていう記事に対して
オーソリだチェックだって何を言ってるんだ
Re: (スコア:0)
オーソリだチェックだってのは (#3535282) がそう説明してるから言ったのであって、
こっちが問題にしてるのは『試行回数は事実上いくらでもある』ことに対して
カード会社側で対策する気はないの? ってことなんだけど。
他のツリーで『カード番号でロックをかけたら正規の利用も出来なくなるからダメ!』
って話があるけど、不正利用されるくらいなら正規の利用が一時的に制限される方が
マシという考え方も有りえるでしょ。
これまた他のツリーにあるとおり、カード会社としては不正利用絶対阻止! という
考えではなくて、確認でき次第キャンセル・返金して、保険でカバーできれば
問題ないと考えているのでしょうけど。