web-dev-qa-db-ja.com

特定のクレジットカード番号がすぐに間違っているかどうかをウェブサイトはどのように知るのですか

ISPのオンラインポータルからインターネットサブスクリプションを更新していました。驚いたのは、クレジットカードの詳細を入力するときに、クレジットカードの種類(MasterCard、Visa、AAなど)を入力し、番号を入力するときに、間違って入力した番号が1つありました。送信ボタンを押すと、入力したカード番号が無効であるというエラーが自動的に表示されました。これはブラウザでローカルに行われ、サーバーでデータがプッシュおよびチェックされて返信が返されなかったと感じています。

私の質問は、各ベンダーが持っている数字のシーケンスはありますか?そうでなければ、ウェブサイトは(ローカルで)間違った番号をどのように知るのでしょうか?

45
tony9099

チェックサム

CC番号やその他のよく設計された重要な番号(銀行の口座番号など)には、番号の整合性を検証するためのチェックサムが含まれている傾向があります。セキュリティ機能ではありませんが(計算するのは簡単なので)、まともなチェックサムアルゴリズムを使用すると、(a)単一のタイプミスが行われた場合、または(b)隣接する2つの数字が入れ替わった場合に常に失敗することが保証されます。長い数字を入力する。

http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers は、このようなテストの例です。

発行者

CC番号が技術的に正しい場合でも、実際のCC番号ではない可能性があります。それを確認する方法は単純かつ複雑です。通常、適切なアクセス権があれば、カード番号の範囲ごとに発行機関を検索できます。次に、発行者に以下のことを確認します。彼らはこれが有効なカードだと思っています。まあ、2番目の部分は通常、CC支払いの一部として発生しますが、発行者の検証は、その前に拡張テストとして行われることがあります。ただし、クライアントブラウザではできません。

71
Peteris

米国では、Luhnアルゴリズムを使用します。

http://en.wikipedia.org/wiki/Luhn_algorithm

アルゴリズムが数値を検証する方法:

  1. チェックディジットである右端の桁から左に移動して、1秒おきの値を2倍にします。この2倍演算の積が9より大きい場合(たとえば、8×2 = 16)、積の桁数を合計します(たとえば、16:1 + 6 = 7、18:1 + 8 = 9)。
  2. すべての桁の合計を取ります。
  3. 10を法とする合計が0に等しい場合(合計がゼロで終わる場合)、その数値はLuhnの公式に従って有効です。それ以外の場合は無効です。

チェックディジットの計算方法:

チェックディジットは、ディジットの合計を計算してから、その値を10を法として9倍に計算することによって取得されます。アルゴリズム形式では、

  1. 桁の合計を計算します(2桁ごとに2倍した後)。
  2. 9を掛けます。
  3. 最後の桁はチェックディジットです。

例:

番号:4321-5678-7531-456xxはチェックディジットです)。

1. Number:              4   3   2   1   5   6   7   8   7   5   3   1   4   5   6   X
2. Double every second: 8       4      10      14      14       6       8      12
3. Sum digits >9:       8   3   4   1   1   6   5   8   5   5   6   1   8   5   3
4. Sum all digits:      8 + 3 + 4 + 1 + 1 + 6 + 5 + 8 + 5 + 5 + 6 + 1 + 8 + 5 + 3 = 69

5. Multiply sum by 9:   69 x 9 = 621
6. Take value mod 10:   621 mod 10 = 1  =>  x = 1

チェックディジットは1であり、有効な数字は4321-5678-7531-4561です。

アルゴリズムをもう一度実行して数を確認する場合、ステップ4のすべての数字の合計は69 + 1 = 70になります。次に、70 mod 10 = 0なので、アルゴリズムに従って有効な数値になります。

38
EarlCrapstone
  1. 多くのサイトでは、CC番号にクライアント側のチェックがあります。すべてのクレジットカード番号はほぼ同じ長さです。 (コメンターが指摘するように、いくつかの長さがあります。一般的に、長さは実装者によって認識されており、小さなセットがあります。)各ベンダーに関連する数値の文字列があります。
  2. セキュリティの観点からは、サーバー側のチェックも必要です。あなたがペンテスターなら、それはチェックするものでしょう。そうでない場合は、大きな問題が発生する可能性があるため、オフにしてください。

https://www.mint.com/blog/trends/credit-card-code-01202011/

7
baordog

完全を期すために:Luhnアルゴリズムには、1つの小さな欠陥があります。

TL; DR: "09または90でない場合、Luhnアルゴリズムは隣接する数字の転置を検出します"

D1とd2がクレジットカード番号の隣接する数字(d1!= d2)である場合、チェックサムへの寄与はf(d1) + d2またはf(d2) + d1、そして転置された場合、それらはf(d2) + d1またはf(d1) + d2のいずれかです。これらの2つの合計が同じであるか、それらの差が10の倍数である場合、チェックサムはそれらの転置を区別しません。

「クレジットカード」2007、お金の数学入門、Springer New York、NY、101-112ページ。

関数f(d)は、python for integers ddef f(d): return sum([int(x) for x in str(2 * d)])

上記のシナリオでゼロmod 10になる2桁はありません。証明は退屈ですが、私は上記のブロック引用を取っている以下のリソースで完全に見つけることができます。

4
user68527

チェックサム、カード範囲認識、長さチェック

ほとんどの(すべてではない)カードスキームは、他の回答で説明されているチェックサム(Luhn)テストを使用します。ただし、さらに、一部のアルゴリズムでは、カード番号の先頭(範囲)に基づく(かなり基本的な)カード範囲認識(CRR)も使用します。カードの長さを確認する人もいます。

たとえば、以下で説明されているさまざまなアルゴリズムの多くの類似点をご覧ください: https://stackoverflow.com/questions/72768/how-do-you-detect-credit-card-type-based-on-number

4
MikeRoger