銀行カードのCVCコードのすべて0（ゼロ）
私の銀行カードは最近期限切れになりました。私は新しいものを手に入れましたが、これは「ラッキー」であることがわかりました。そのCVCコードは000でした。
数か月間、オンラインとオフラインの両方で問題なく広範囲に使用しました。Booking.comでカードの詳細を入力した日までです。フォームに入力し、[送信]をクリックしました。ページがCVCフィールドの値を破棄し、再度入力するよう要求するだけです。
サポートに連絡しました。 CVCコード「000」は十分に安全ではないと考えられているため（残念ながら正確な引用ではないため、会話はエストニア語で行われたため）、CVCコードが異なる新しい銀行カードを注文することを提案しました。 「000」から。
それは私を困惑させました。以前のテスターとして、私はバグを報告していると思い、実際には機能であると言われる状況にかなり慣れていますが、今回は常識に反するものでした。私の現在の仕事は情報セキュリティにも関連しており、彼らの主張が意味をなさない3つの理由が考えられます。
- CVCは単なる乱数ではなく、それを生成する 特定のアルゴリズム があります。これはつまり、すべての値が等しく可能性があり、一部の特定の数値を単にその値から除外できないことを意味します。
- 私はすでにこのカードをAmazon Web Servicesを含む他の多くのオンラインサービスで使用していますが、そのセキュリティは疑いの余地がありません。
- 「十分に安全でない」の意味がよくわかりません。 「111」または「999」は十分に安全ですか？そうでない場合、「123」または「234」はどうですか？繰り返しますが、それは私が自分で選ぶものではなく、銀行から与えられたものです。銀行が安全だと考えている場合は、そのように扱う必要があります。
「ご不便をおかけして申し訳ございませんが、ご不便をおかけして申し訳ございません。理由を弊社の経営陣に提出いたしました。000は無効とみなされ、これは、銀行がカードが偽造であることを示す方法でもあります "。
私はメールチェーンを私の銀行に転送し、彼らに助言を求めました。彼らは、新しいカードを無料で発行すると私に問題を解決したと私に言った。
しかし、私はまだ疑問に思います：
- 公式の規制/処方箋（Visa/MCまたは他の場所から）または「オールゼロ」のCVC/CVVコードに関するベストプラクティスはありますか？特に銀行が偽造の兆候として000を使用していると言われていることについては、それは私にはまったくナンセンスのように聞こえます。グーグルで試しましたが何も見つかりませんでした。
- 実用的な観点から、「000」を安全でないと拒否することはどれほど合理的ですか？上記の懸念事項を記載しましたが、何か不足している可能性がありますか？
更新：どの回答を受け入れるかについての厳しい選択...私は Alexander O'Maraからの回答 とても気に入りました-それ詳細で要領を得ています。 ハーパーの答え の最新版も非常に合理的であるようです。それでも私は最終的に Zoeyによる回答 を受け入れることにしました。これは、他のすべてのものに加えて、ホテルビジネスの内部にもいくつかの光を当てるので、最も関連性があるようです。
皆さんの回答とコメントに感謝します！私が今やろうとしていることは、再度Booking.comのサポートに連絡して、これを修正するように主張することです。結果についてお知らせします。
アップデート2：Booking.comのサポートに数か月間連絡を試みた後、私は正式に諦めました。私は、確認さえされていない無数のサポートチケット、さらには反応があったことは言うまでもなく、状況を説明し、メールの缶詰だけが届いた電話が2通以上ないので、あなたの問題を解決するのは難しい」。結論：Booking.comのサポートは機能しません。問題が非常に標準的なものでない限り、解決も上級管理者へのエスカレーションもありません。
バグはまだ存在しています。 newカードを追加するとCVC "000"が完全に受け入れられるため、これはソフトウェアのバグにすぎないと確信していますが、有効期限が切れた（または無効なカード）をupdateしようとしているときは機能しません。これが再現手順です：
- 即時支払いが必要な新しい予約を作成します。
- 無効なカード（期限切れまたはブロック済み）を入力してください。
- カードを処理できないという通知がシステムから送信されたら、[カードの詳細を更新]を選択し、CVCコード000の有効なカードの詳細を入力します。
期待される結果：カードのデータがさらに処理されるために受け入れられます。
実際の結果：入力されたCVCコードは破棄され、ダイアログウィンドウにCVCコードが入力されていないというメッセージが表示されます。
Alexander O'Maraは 正解 を提供しましたが、booking.comを使用していたホテルで働いたことがあるので、CVVが拒否された理由について追加情報を提供できると思います。
私が働いていたホテルは毎日約50件の予約を受け取り、予約の4分の1は偽のクレジットカード情報を使用しており、偽のクレジットカード情報を使用している人の約90％は表示されません。
これにより、部屋を割り当てる際に多くの推測が行われました。クレジットカードの詳細だけに基づいて人物が表示されるかどうかを推測したり、名前、場所、滞在日数を考慮したりすることもあります。また、前日に電話をかけて予約を確認し、これらの偽の予約によってビジネスへの影響が最小限になるようにします。
CVV 000のブロックは、booking.comの偽の予約の量を減らすための怠惰な試みです。他のCVVもブロックされます。
Booking.comがCVVをブロックし、他のWebサイトがブロックしない理由は、他のWebサイトは通常、すぐにクレジットカードへの請求を試み、booking.comは到着日にクレジットカードに請求するホテルにのみ情報を転送するためです。
そのようなCVVを拒否するために私が考えることができる唯一の弱い議論は、誰かがあなたの3桁のコードをブルートフォースにしようとした場合、それらはmight皮切りに 000最初に（しかし、彼らも拒否します001？）。
実用的な観点から、「000」を安全でないと拒否することはどれほど合理的ですか？
それは本当に合理的ではありません。提供されたCVC/CVVコードでカードを充電することも、充電することもできません。このコードは有効であるため、拒否する正当な理由はありません。実際に請求するまで、クレジットカードのコードが有効かどうかは確かではありません。
悲しいことに、設計が不十分な入力検証は一般的です。一部の開発者は、仕様をチェックせずに特定の値が無効であると仮定したり、入力検証を適切にユニットテストしない傾向があります。
いくつかの例は次のとおりです。
- IPアドレス 1.1.1.1
- 文字列の最初の文字のみがチェックしている場合、「10」<「9」のようなバージョンチェックのバグ
- 英字以外の名前（私の名前のアポストロフィなど）
また、カスタマーサービスの担当者が開発者に相談することなく、「バグではなく、機能である」という内容でバグレポートに返信することも珍しくありません。
これは、会社の主張のフレームチャレンジです。 000〜999の範囲の乱数は001〜998よりも安全であり、値を拒否すると脆弱になります。
これはソフトウェアのバグです。彼らはそれを認めることはできません。
ほんの一例：スタックのどこかで、型付けされていない変数を使用する言語を使用します（つまり、同じ変数が123.45、「夕食に遅れる」、0文字の文字列、「未定義」トークンなどを保持できる場合）。これを書くのは当たり前のことです：
if ($CVC) # is CVC field present?
型指定されていない言語では、プログラマが意図したとおりに空の文字列が0（偽）と評価されますしかし000もそうです！これを行うにはより良い方法があります。
この場合、問題は、使用している一般公開されているWeb UIではなく、両者が共有するバックエンドプラットフォームにあることがわかります。エージェントは発券システムでバグをオープンする必要があります。
なぜ彼らは彼らが言ったことを主張したのですか？ 通常の企業は、この種の構造的エラーが原因で無能に見えることを認めることに非常に消極的であるためです。しかし、同じ効果を持つため、「わからない」であなたを送り出すこともできません。ですから、彼らはあなたに今すぐ彼らに売れると感じる何かを言う必要があります。
明らかにそれは間違っています。 問題なく取引をしている他のすべての人々によって証明されています。しかし、自分で試してみてください。競合する予約プラットフォームを試して、それがどうなるかを見てください。
私は現在間違いなく悪いCVV番号を持つクレジットカードを持っています：123
これまで否定されたことは一度もありませんが、セキュリティの観点からは、泥棒が私の番号を持っているのに自分のカードを持っていない場合、泥棒が最初に入力する可能性が非常に高いと思うので、私は好きではありません。
Webサイトの観点から見ると、私見では、有効な番号を意図的に無効として扱うのは至難の業です。 （それが発生する可能性が1000分の1である場合でもなおさらです。）サイトがクレジットカードを確認するための非常に小さな承認を試みることは非常に簡単です。 「偽の番号を防ぐ」という主張に同意する。そうは言っても、 クイック検索 を使用すると、長年にわたってさまざまなWebサイトで同じ問題を抱える人がかなり多くいます。だから、あなたは一人ではありません。 :)
公平に言えば、booking.comが処理するために情報を渡す必要があるホテル予約システムは数万あります。 booking.comは、JavaScriptで（000）== FALSEを知っている開発者に資金を提供できると信じています...しかし、おそらくこのバグを抱えている何百ものホテルについて、まったく同じバグを診断するためにサポートする価値はあります予約システム？絶対違う。
私の推測では、これは実際には、チェーンのさらに下流で、booking.comの制御が及ばないシステムで発生するデータ処理エラーを軽減するためのかなり合理的な試みだと思います。
カード処理業者として、彼らは有効なカードを処理する義務があるため、おそらくここで業者の規則に違反しており、VISA（または誰でも）に問題を起こす可能性があります...しかし、ロジックはほぼわかります。
ここで、単純な「愚かなバグ」の理論に問題があります。あなたが話していた人がこのナンセンスを薄い空気から引き離していたことは間違いありません（一部のカスタマーサービスの人々はそうしないでしょう）。 000は完全に有効であり、あなたはインターネット上で最初にその数を指摘する人ではありません。
しかし、ここには人々が理解していないスケールがあります。
- CVVが0.1％であるため、
000を取得する自然な可能性 - Booking.comは、2017年の生の収益80億ドルを生み出したビジネスであり、ほとんどがカードトランザクションです。これは、1日あたり約5万の予約です。
- したがって、Booking.comは1日に50回
000に遭遇する必要があります。 Booking.comに負けた$ 25kのチューンに、そして実際には、渡されなかった実際の予約に関してmuch多い。
カード取引の0.1％を拒否すると、900万ドルの収益が失われます。私が働いている[veryはるかに小さい]ビジネスでは、フローアナリティクスを予約すると、すぐにチェーンにフラグが立てられます。これらの種類の会社（私は休日予約システムで接線方向に働いています）、カートエクスペリエンスが最も追跡されている部分です...分析に依存している会社がカード検証のような単純なものを見落とすと信じるのは非常に困難です問題。
したがって、これがそのスケールでは存在できないと想定する場合、範囲を制限するいくつかの提案を提供する必要があります...
これはローカルのバグです。
多くの多国籍企業は、地元の口座を通じてお金を出し、そこから税目的でそれを跳ね返しています。 Booking.comでは、ローカルオフィスがコードを編集してローカルの癖（通貨、グローバルではない支払いスキーム全体）を処理できるようにしているため、他の場所には存在しないバグが侵入する可能性があります。
対象国がクロアチアのため、可能性が高まります。そこではユーロではなくクナを使用します。会計上の違いやメカニズムの提供者は山ほどあるかもしれません。
これはまた、なぜこれがレーダーの下に置かれたのかを説明するために少し距離を置きます。クロアチア行きのお金の0.1％は、世界の収入よりもはるかに少ない地獄になるでしょう。
000は0.1％ほど一般的ではありませんJPhi1618がコメントで指摘しているように、もう1つのスコープ制限要因は、おそらく銀行が
000を頻繁に発行しないことです。彼らがすべきでない理由はなく、私が言ったように、000枚のカードを持つ他の人々のオンラインの証拠がありますが、それが一般的であるとは限りません。[〜＃〜] i [〜＃〜]にはこれを確認する方法がありません。おそらく、CVVを含むカード処理ログを持つ誰かが分析を実行できます。
それでも、このような問題が見つかった場合は報告してください。何が起こっているのかわからないため、カスタマーサービスチームをスキップしてください。 CEOまたはセキュリティチームに連絡してください。どちらも少し異なる理由でかなり真剣に取り組んでいます。失われた収益900万ドルは良い動機です。
一部のクレジットカードソフトウェアでは、マジック値000は、CVCが提供されたが、その後（PCIの制約により）削除されたことを意味します。それがおそらく予約が行っていることであり、それが彼らがそれを受け入れない理由を説明しています。