アカウント名:
パスワード:
セキュリティコード [wikipedia.org]
米国のVISAの場合、「架空のカードによる取引」を防ぐため、顧客からコードを伝えられたショップ側は、信用照会と取引が正常に終わればセキュリティコード情報を廃棄することを義務づけられている。
「米国の」とあるが、この扱いは何処でも同じだろう。
このショップは契約違反の行為を行っていたわけで、被害が出てもクレジットカード会社はケツを持たないだろうし、以後カード会社と契約結べなくなるんじゃないの。
PCI DSSでも規定されてますね。
PCI DSSの概要 -PCI DSSの12要件を読み解く-http://www.intellilink.co.jp/article/pcidss/02.html#IN03 [intellilink.co.jp]
センシティブ認証データをオーソリゼーション後に保持しないこと、カード会員データは必要最低限の量、必要最低限の期間のみ保管し、かつ安全に保管すること
各種ISOのように、「取得するときだけ形を見せときゃいいか」みたいな意識なんでしょうかね。
セキュリティコード無しでクレカの決済を通すのは、出来ないことはないが通常よりも審査が厳しく、決済エラーになることがある。そこで、セキュリティコードを入力させるわけだが、世の中には「ユーザに入力させる手間を増やせば増やすほど客は離れていくので、できる限り簡単にするのが望ましい」等と言う事を言って回るシステム屋がいる。ワンクリックで決済出来るAmazonはあんなにはやってるじゃないカー、とか。
その2つを両立するには、カード番号と共にセキュリティコードを保存しておき、ユーザは意識していないが、裏でセキュリティコードも送信しているという事をやる。そのためには保存しておく必要があるというわけだ。
ここがこれをやっているかは知らんけども。
もうセキュリティコードなんて中途半端な仕組みをやめて、オンライン金融決済には3Dセキュアを義務化するぐらいしたほうがいい。
継続取引用の再与信の仕組みを小売店の販売で使っちゃってる、と言う規約違反の告白でしょうか。それとも都度換金系の事情を知らないのに自分の知ってることがすべてだと勘違いして煽っちゃった残念な人でしょうか。
通販サイトの話なのに何言ってるんだお前
ほんと、こういう契約違反を一度でも犯したところは契約破棄して二度と契約しないで欲しい
セキュリティコードなんて保存しておく必要性なんてないのになんで保存したがるかね
システム屋(の中の人)が何も考えずにそのように作っちゃうのだろうか。それとも、システムを発注する側がそのように要求するのだろうか。
用意されているインタフェースを使って決まった手順で組み込めばいいだけなのに、腕の悪いシステム屋はそういうのを面倒臭がるんだよね。プロトコルに正しく準じるスマートな処理なんて作れないの。
だから、なんでもかんでもローカルに保存したがる。(たぶん暗号化もしていない)
> なんでセキュリティコードを保存しておくかな
http://blog.tokumaru.org/2016/03/blog-post.html [tokumaru.org]を見ると、THE KISS ONLINE SHOP は、「フォーム改ざんが攻撃経路と思われる」「決済代行」は「使用」と記されてます。
「思われる」ですから、確定ではないですが、徳丸氏の推定が正しければ、セキュリティコードは保存は保存しておらず、侵入者によって入力フォームを改竄され、ユーザーの行った入力内容を、決済代行サービスだけではなく、侵入者にも送っていたということになります。
ですので、
> このショップは契約違反の行為を行っていたわけで、
というわけじゃないってことなりますね。
なるほど。よく見ると盗まれた情報は
2016年1月16日から2016年3月2日までに同サイトでクレジットカード決済を利用した顧客537件の氏名およびクレジットカード番号、有効期限、セキュリティコード
と
会員登録された顧客情報最大199,709件(ユーザーIDおよび暗号化されたパスワード、氏名、住所、電話番号、メールアドレス等の登録情報
の2種類あって、20万件の登録情報にはカード情報は含まれず、セキュリティコードが漏えいしたのはクラックされた期間中に決済された537件のみということみたいなので、決済時に情報を直接抜かれていたという推測が正しそうやね。 #2997924 [security.srad.jp]は脊髄反
> 中間者攻撃で決済情報を盗み取ることもできるわけで、対策にならないように思えるが。
決済サービスのURLをきちんと確認する人なら防げるって意味なんじゃないでしょうか。リスクは低減できるかもしれませんが、完全に防ぐのは無理でしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
なんでセキュリティコードを保存しておくかな (スコア:2, 興味深い)
セキュリティコード [wikipedia.org]
米国のVISAの場合、「架空のカードによる取引」を防ぐため、顧客からコードを伝えられたショップ側は、
信用照会と取引が正常に終わればセキュリティコード情報を廃棄することを義務づけられている。
「米国の」とあるが、この扱いは何処でも同じだろう。
このショップは契約違反の行為を行っていたわけで、被害が出てもクレジットカード会社はケツを持たないだろうし、
以後カード会社と契約結べなくなるんじゃないの。
Re:なんでセキュリティコードを保存しておくかな (スコア:2)
PCI DSSでも規定されてますね。
PCI DSSの概要 -PCI DSSの12要件を読み解く-
http://www.intellilink.co.jp/article/pcidss/02.html#IN03 [intellilink.co.jp]
センシティブ認証データをオーソリゼーション後に保持しないこと、
カード会員データは必要最低限の量、必要最低限の期間のみ保管し、かつ安全に保管すること
各種ISOのように、「取得するときだけ形を見せときゃいいか」みたいな意識なんでしょうかね。
--------------------
/* SHADOWFIRE */
Re:なんでセキュリティコードを保存しておくかな (スコア:1)
セキュリティコード無しでクレカの決済を通すのは、出来ないことはないが通常よりも審査が厳しく、決済エラーになることがある。
そこで、セキュリティコードを入力させるわけだが、世の中には「ユーザに入力させる手間を増やせば増やすほど客は離れていくので、できる限り簡単にするのが望ましい」等と言う事を言って回るシステム屋がいる。ワンクリックで決済出来るAmazonはあんなにはやってるじゃないカー、とか。
その2つを両立するには、カード番号と共にセキュリティコードを保存しておき、ユーザは意識していないが、裏でセキュリティコードも送信しているという事をやる。そのためには保存しておく必要があるというわけだ。
ここがこれをやっているかは知らんけども。
もうセキュリティコードなんて中途半端な仕組みをやめて、オンライン金融決済には3Dセキュアを義務化するぐらいしたほうがいい。
Re: (スコア:0)
継続取引用の再与信の仕組みを小売店の販売で使っちゃってる、と言う規約違反の告白でしょうか。
それとも都度換金系の事情を知らないのに自分の知ってることがすべてだと勘違いして煽っちゃった残念な人でしょうか。
Re: (スコア:0)
通販サイトの話なのに何言ってるんだお前
Re: (スコア:0)
ほんと、こういう契約違反を一度でも犯したところは契約破棄して二度と契約しないで欲しい
セキュリティコードなんて保存しておく必要性なんてないのになんで保存したがるかね
Re: (スコア:0)
システム屋(の中の人)が何も考えずにそのように作っちゃうのだろうか。
それとも、システムを発注する側がそのように要求するのだろうか。
Re: (スコア:0)
用意されているインタフェースを使って決まった手順で組み込めばいいだけなのに、腕の悪いシステム屋はそういうのを面倒臭がるんだよね。
プロトコルに正しく準じるスマートな処理なんて作れないの。
だから、なんでもかんでもローカルに保存したがる。
(たぶん暗号化もしていない)
保存してないかも (スコア:0)
> なんでセキュリティコードを保存しておくかな
http://blog.tokumaru.org/2016/03/blog-post.html [tokumaru.org]
を見ると、THE KISS ONLINE SHOP は、
「フォーム改ざんが攻撃経路と思われる」
「決済代行」は「使用」
と記されてます。
「思われる」ですから、確定ではないですが、徳丸氏の推定が正しければ、
セキュリティコードは保存は保存しておらず、侵入者によって入力フォームを
改竄され、ユーザーの行った入力内容を、決済代行サービスだけではなく、
侵入者にも送っていたということになります。
ですので、
> このショップは契約違反の行為を行っていたわけで、
というわけじゃないってことなりますね。
Re: (スコア:0)
なるほど。よく見ると盗まれた情報は
2016年1月16日から2016年3月2日までに同サイトでクレジットカード決済を利用した顧客537件の
氏名およびクレジットカード番号、有効期限、セキュリティコード
と
会員登録された顧客情報最大199,709件
(ユーザーIDおよび暗号化されたパスワード、氏名、住所、電話番号、メールアドレス等の登録情報
の2種類あって、20万件の登録情報にはカード情報は含まれず、
セキュリティコードが漏えいしたのはクラックされた期間中に決済された537件のみということみたいなので、
決済時に情報を直接抜かれていたという推測が正しそうやね。
#2997924 [security.srad.jp]は脊髄反
Re: (スコア:0)
> 中間者攻撃で決済情報を盗み取ることもできるわけで、対策にならないように思えるが。
決済サービスのURLをきちんと確認する人なら防げるって意味なんじゃないでしょうか。
リスクは低減できるかもしれませんが、完全に防ぐのは無理でしょうね。