アカウント名:
パスワード:
嘘だとは言わないが、13件（4件）という少なさには説明が必要な気がするんだが。
ペイペイ被害が数億円に 経産省など、本人確認指針策定へ [tokyo-np.co.jp]
スマートフォンを使った決済サービス「ペイペイ」をめぐるクレジットカードの不正利用問題で、被害額が数億円にのぼる見込みであることが二十八日わかった。経済産業省関係者が明らかにした。ほかのＱＲコード決済サービスでも同様の被害があるといい、経産省と業界団体は三月末までに、決済サービス事業者に最低限の本人確認を求める指針を定める。
４件で数億の被害＝１枚１億の限度額だけどダイナースならたぶん可能だよ。
これはセキュリティコードを総当たり攻撃した件数でしょ。単純に他所から漏れたカード番号で不正利用された分が別にあるって話でしょうよ。（そいつらはPayPayの責任じゃないので、たぶん保障も普通にカード会社持ちだと思われ。）
いえ。多要素認証がなされていない場合の不正利用は加盟店の責になります。だから遅まきながら3DSecure入れるって言ってるので。
>嘘だとは言わないが、13件（4件）という少なさには説明が必要な気がするんだが
クレジットカード不正利用者は、セキュリティコードまで揃った番号リストを何万件も持ってるので、わざわざ努力してセキュリティコードをチャレンジする必要性がないんですよ。たぶん。
彼らに常に不足しているものは、セキュリティコードまで揃ったクレジットカード番号を使って安全で多額に換金できる手段なので、paypayは、その換金手段としてだけ、見込まれたんだろうと。
換金手段として有効な上にカード番号・セキュリティコード特定にも利用可能とかやばいなんてもんじゃないよね……両方セットで全部PayPay上で攻撃した事例はなかったというだけで、前者は被害額まで算定されていて、後者かもしれない本人か不明な4件のトライもあったと。駄目と駄目で超駄目ではなかったというだけで駄目なのは一切変わらない。
セキュリティコードの割り出しには普通は自動的に数百以上のサイトを使って割り出すんで回数制限って実はあまり意味ないんだけどね。換金手段としての優秀さの方が問題でしょう。
同じ番号に対しての連続試行が少ないのはいいとして、同じセキュリティコードを複数のカード番号に対して連続試行した形跡がないかどうかはは確認したんだろうか？
同じセキュリティコードである必要性すら無いわけですが……。
ロボットで動く端末1000台用意すれば、クレカ番号1種類×コード1種類×有効期限ｎ回だけで確実に割り出せちゃうしなぁ。
そんなもんクレカ自体の仕組みでしょ。paypayに限った話ではない。
13件中4件は不正利用だった件数じゃなくて、登録に至ったものの利用がなかった件数だよ(ニュースももっとわかりやすく書くべきだと思うが)。つまりセキュリティコードの総当たりとか騒いでいたこと自体が全然的外れだったってこと
別にそこは論点じゃないでしょ。「セキュリティコードの総当たりとか騒いでいたこと自体が全然的外れだった」と結論付けたいなら、データの取り方に問題がなかったか疑うところでは？
> 別にそこは論点じゃないでしょ。
そこが論点でしょ。
「セキュリティコード総当たりを許す設計は頭がいかれている」という叩き方をしていたけど、結果として、セキュリティコード総当たりで突破して不正利用したのは 1件もなかった。20回以上試行した13件中、本人だったのが9件、利用無しが4件。
結果として推論されたのは、既に出回っているカード番号とセキュリティコードのペアを使って、1回の試行で登録して不正利用、だった。つまり、最初から「クレカの現物無しに、カード番号とセキュリティコードのペアだけで、多額の決済できる設計は頭がいかれている」と叩くべきだった。
それはひとつの意見として理解できるが、このツリー元ではその推論の前提となっている数値（の前提となる調査方法）に疑問を呈している訳だが。
こんだけセキュリティ的にガバガバな上に、炎上しても暫くは都合の良いことばかり言ってた会社だからね。総当たりの件数調査も鵜呑みには出来ない。発覚を遅らせるためにID変えながら総当たりしたケースだってあるだろうし。
セキュリティコードが通った次のステップでキャンセルすると・・・「クレジットカード登録時にセキュリティコードを20回以上入力し登録に至った件数」と認識されないんじゃないか？って予想がある。
＃ちなみにPayPayの不正使用は数億円以上 [tokyo-np.co.jp]らしい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
単純な統計の問題として (スコア:0)
嘘だとは言わないが、13件（4件）という少なさには説明が必要な気がするんだが。
Re:単純な統計の問題として (スコア:2)
ペイペイ被害が数億円に 経産省など、本人確認指針策定へ [tokyo-np.co.jp]
４件で数億の被害＝１枚１億の限度額だけどダイナースならたぶん可能だよ。
Re: (スコア:0)
これはセキュリティコードを総当たり攻撃した件数でしょ。
単純に他所から漏れたカード番号で不正利用された分が別にあるって話でしょうよ。
（そいつらはPayPayの責任じゃないので、たぶん保障も普通にカード会社持ちだと思われ。）
Re: (スコア:0)
いえ。
多要素認証がなされていない場合の不正利用は加盟店の責になります。
だから遅まきながら3DSecure入れるって言ってるので。
Re:単純な統計の問題として (スコア:2)
>嘘だとは言わないが、13件（4件）という少なさには説明が必要な気がするんだが
クレジットカード不正利用者は、セキュリティコードまで揃った番号リストを何万件も持ってるので、わざわざ努力してセキュリティコードをチャレンジする必要性がないんですよ。たぶん。
彼らに常に不足しているものは、セキュリティコードまで揃ったクレジットカード番号を使って安全で多額に換金できる手段なので、paypayは、その換金手段としてだけ、見込まれたんだろうと。
Re: (スコア:0)
換金手段として有効な上にカード番号・セキュリティコード特定にも利用可能とかやばいなんてもんじゃないよね……
両方セットで全部PayPay上で攻撃した事例はなかったというだけで、前者は被害額まで算定されていて、後者かもしれない本人か不明な4件のトライもあったと。
駄目と駄目で超駄目ではなかったというだけで駄目なのは一切変わらない。
Re:単純な統計の問題として (スコア:1)
セキュリティコードの割り出しには普通は自動的に数百以上のサイトを使って割り出すんで回数制限って実はあまり意味ないんだけどね。
換金手段としての優秀さの方が問題でしょう。
Re: (スコア:0)
同じ番号に対しての連続試行が少ないのはいいとして、
同じセキュリティコードを複数のカード番号に対して連続試行した形跡がないかどうかはは確認したんだろうか？
Re: (スコア:0)
同じセキュリティコードである必要性すら無いわけですが……。
Re: (スコア:0)
ロボットで動く端末1000台用意すれば、
クレカ番号1種類×コード1種類×有効期限ｎ回
だけで確実に割り出せちゃうしなぁ。
Re: (スコア:0)
そんなもんクレカ自体の仕組みでしょ。paypayに限った話ではない。
Re: (スコア:0)
13件中4件は不正利用だった件数じゃなくて、登録に至ったものの利用がなかった件数だよ(ニュースももっとわかりやすく書くべきだと思うが)。つまりセキュリティコードの総当たりとか騒いでいたこと自体が全然的外れだったってこと
Re: (スコア:0)
別にそこは論点じゃないでしょ。
「セキュリティコードの総当たりとか騒いでいたこと自体が全然的外れだった」と結論付けたいなら、データの取り方に問題がなかったか疑うところでは？
Re:単純な統計の問題として (スコア:2, 興味深い)
> 別にそこは論点じゃないでしょ。
そこが論点でしょ。
「セキュリティコード総当たりを許す設計は頭がいかれている」という叩き方をしていたけど、
結果として、セキュリティコード総当たりで突破して不正利用したのは 1件もなかった。
20回以上試行した13件中、本人だったのが9件、利用無しが4件。
結果として推論されたのは、既に出回っているカード番号とセキュリティコードのペアを使って、
1回の試行で登録して不正利用、だった。
つまり、最初から
「クレカの現物無しに、カード番号とセキュリティコードのペアだけで、多額の決済できる設計は頭がいかれている」
と叩くべきだった。
Re: (スコア:0)
それはひとつの意見として理解できるが、このツリー元ではその推論の前提となっている数値（の前提となる調査方法）に疑問を呈している訳だが。
Re: (スコア:0)
こんだけセキュリティ的にガバガバな上に、炎上しても暫くは都合の良いことばかり言ってた会社だからね。
総当たりの件数調査も鵜呑みには出来ない。発覚を遅らせるためにID変えながら総当たりしたケースだってあるだろうし。
Re: (スコア:0)
セキュリティコードが通った次のステップでキャンセルすると・・・
「クレジットカード登録時にセキュリティコードを20回以上入力し登録に至った件数」と認識されないんじゃないか？って予想がある。
＃ちなみにPayPayの不正使用は数億円以上 [tokyo-np.co.jp]らしい