アカウント名:
パスワード:
その先のカード会社のサーバで確認するんでしょそっちもぶっ通しなのかな?セキュリティが売り物のカード会社にしてはザルい気がするな
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな決済かけてないから失敗してもカード会社側は特に検知しないと思う新規登録でユーザ増えていってるかな？になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
業者（ここでいうPayPay）はカード会社にとっては１ユーザーだけど、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では対処がまず無理なのよな。カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
PayPayの仕組みは知らんが (スコア:2)
その先のカード会社のサーバで確認するんでしょ
そっちもぶっ通しなのかな?
セキュリティが売り物のカード会社にしてはザルい気がするな
Re: (スコア:0)
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな
決済かけてないから失敗してもカード会社側は特に検知しないと思う
新規登録でユーザ増えていってるかな？になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
Re: (スコア:0)
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
Re: (スコア:0)
業者（ここでいうPayPay）はカード会社にとっては１ユーザーだけど、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では対処がまず無理なのよな。
カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ？