アカウント名:
パスワード:
その先のカード会社のサーバで確認するんでしょそっちもぶっ通しなのかな?セキュリティが売り物のカード会社にしてはザルい気がするな
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな決済かけてないから失敗してもカード会社側は特に検知しないと思う新規登録でユーザ増えていってるかな?になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
業者(ここでいうPayPay)はカード会社にとっては1ユーザーだけど、PayPayを使うのは大多数。なので、ユーザーあたりのFailカウントでロックかけると、後者の大多数が影響受けるでしょ。
わかりやすく言えば、携帯回線から誰かがブルートフォースした際に、そのIPアドレスをBANすると、そのIPアドレスを共有してる他の携帯ユーザーもログインできなくなる。だから、普通は多数で共有してるものをブロックはしないはず。
今回はPayPayの実装が甘かったってことなんだけど、カード会社側でロックするシステムなら、PayPayの競合がブルートフォースかけてPayPayがカード使えなくする攻撃が可能になる。
その例でいうならカード番号ごとに試行失敗をカウントすりゃいいじゃん携帯回線でいえばIPアドレスではなくて電話番号で絞ればよいって話
仮に番号を変えながらやったとしても、トータルで失敗率が上がってきたら対策するとかいろいろ考えられるのでは?
いずれにせよ例に過ぎないので実際には対応が簡単ではないとしても、実際に破られることが纏めて発生しちゃうんなら信用を売り買いしてるカード会社にしちゃーへぼいんじゃないかなぁ
今回の件で言うとカード会社ごとの率とかどうなんかね
だから、それはPayPay側の実装の話であってカード会社側システムで防ぐもんじゃない決済ネットワークなんてカード番号、有効期限、セキュリティコード、TDSリザルト、氏名ぐらいしか使わん
なんで決済ネットワークに電話番号やら何やら送ると思ってんだよ
何で例えに過ぎない電話番号を送ると思ってるんですかね…
電話番号に限らず、カード会社側APIとして利用者あたりに有限と仮定できなくもない識別情報(電話番号、IPアドレス、ユーザID、店舗レジID等)を必須項目には出来ていないだろうって話でしょう。
オンラインで暗証番号固定してカード番号に総当りを仕掛けるのを回数で弾いて防ぐ場合、攻撃者が無数に確保するのが難しい識別情報に対して試行回数をカウントするしかない。でも、店舗形態ごとに提供できうる識別情報は異なるので統一の基準で識別情報を強制することは不可能。何パターンかから選択制で用意する(してる)にしても今回のようなノーチェックが選択肢にあるなら無いのと同じこと。
無数に確保するのは難しい情報でってお前はBOTネットワークも知らんの?未だに何万台のノードがいると思ってんの?
だからまぁCAPTCHAかなんかやDDoS対策も組み合わせる必要もあって、そのへんの統一規則考えるとAPIでは対処がまず無理なのよな。カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
PayPayの仕組みは知らんが (スコア:2)
その先のカード会社のサーバで確認するんでしょ
そっちもぶっ通しなのかな?
セキュリティが売り物のカード会社にしてはザルい気がするな
Re: (スコア:0)
auth(オーソリ 与信枠確保)で投げると金かかるんでcheck(カード有効性チェック)で決済ネットワーク流してんじゃないかな
決済かけてないから失敗してもカード会社側は特に検知しないと思う
新規登録でユーザ増えていってるかな?になるだけなんで
で、登録通ってしまえばPayPayのサーバから正しいauth投げられるだけなので分からん
Re: (スコア:0)
その「カード有効性チェック」がブルートフォースアタック可能な仕様なのはどうなのよって話でしょ。
Re: (スコア:0)
業者(ここでいうPayPay)はカード会社にとっては1ユーザーだけど、PayPayを使うのは大多数。
なので、ユーザーあたりのFailカウントでロックかけると、後者の大多数が影響受けるでしょ。
わかりやすく言えば、携帯回線から誰かがブルートフォースした際に、そのIPアドレスをBANすると、そのIPアドレスを共有してる他の携帯ユーザーもログインできなくなる。
だから、普通は多数で共有してるものをブロックはしないはず。
今回はPayPayの実装が甘かったってことなんだけど、カード会社側でロックするシステムなら、PayPayの競合がブルートフォースかけてPayPayがカード使えなくする攻撃が可能になる。
Re: (スコア:2)
その例でいうならカード番号ごとに試行失敗をカウントすりゃいいじゃん
携帯回線でいえばIPアドレスではなくて電話番号で絞ればよいって話
仮に番号を変えながらやったとしても、
トータルで失敗率が上がってきたら対策するとかいろいろ考えられるのでは?
いずれにせよ例に過ぎないので実際には対応が簡単ではないとしても、
実際に破られることが纏めて発生しちゃうんなら
信用を売り買いしてるカード会社にしちゃーへぼいんじゃないかなぁ
今回の件で言うとカード会社ごとの率とかどうなんかね
Re: (スコア:0)
だから、それはPayPay側の実装の話であってカード会社側システムで防ぐもんじゃない
決済ネットワークなんてカード番号、有効期限、セキュリティコード、TDSリザルト、氏名ぐらいしか使わん
なんで決済ネットワークに電話番号やら何やら送ると思ってんだよ
Re: (スコア:2)
何で例えに過ぎない電話番号を送ると思ってるんですかね…
Re: (スコア:0)
電話番号に限らず、カード会社側APIとして利用者あたりに有限と仮定できなくもない識別情報(電話番号、IPアドレス、ユーザID、店舗レジID等)を必須項目には出来ていないだろうって話でしょう。
オンラインで暗証番号固定してカード番号に総当りを仕掛けるのを回数で弾いて防ぐ場合、攻撃者が無数に確保するのが難しい識別情報に対して試行回数をカウントするしかない。
でも、店舗形態ごとに提供できうる識別情報は異なるので統一の基準で識別情報を強制することは不可能。
何パターンかから選択制で用意する(してる)にしても今回のようなノーチェックが選択肢にあるなら無いのと同じこと。
Re:PayPayの仕組みは知らんが (スコア:0)
無数に確保するのは難しい情報でってお前はBOTネットワークも知らんの?
未だに何万台のノードがいると思ってんの?
Re: (スコア:0)
だからまぁCAPTCHAかなんかやDDoS対策も組み合わせる必要もあって、そのへんの統一規則考えるとAPIでは対処がまず無理なのよな。
カード会社のサイトに飛ばしてそっちで対策するって規則にしとく位かねぇ?