我需要生成保留格式的信用卡代理（令牌）
对于电子商务应用程序，我需要使用信用卡并使用真实卡传递到支付网关，但我需要存储格式保留的代理并将其返回给交易发起者。具体来说，这意味着：
1) 代理项中的位数与真实卡号 (PAN) 相同。 2) 卡的发卡机构类型部分——代理中的前 1,2 或 4 位数字与原始 PAN 中的相同。 3) 代理人的最后 4 位数字保持不变（出于客户服务目的。） 4) 代理人通过 Luhn mod10 检查语法上有效的信用卡。
我可以轻松处理要求 1-3，但要求 4 让我完全难住了！最终的实现将是 t-sql 或 c#。
有什么想法吗？
For an eCommerce application I need to take a credit card and use the real card for passing through to a payment gateway but I need to store, and return to the transaction initiator, a surrogate that is format preserving. Specifically, this means:
1) The number of digits in the surrogate is the same as the real card number (PAN).
2) The issuer type part of the card -- the initial 1,2 or 4 digits remains the same in the surrogate as in the original PAN.
3) The final 4 digits of the surrogate remain the same (for customer service purposes.)
4) The surrogate passes the Luhn mod10 check for a syntactially valid credit card.
I can readily handle requirements 1-3 but #4 has me completely stumped! The final implementation will be either t-sql or c#.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
@neo 有正确的答案（给你+1），但我只是想指出，如果我正确地理解你在做什么，这似乎是一个“坏主意”。 发行人标识符号 (IIN) 是 PAN 的前六位数字。如果您想存储前六位和后四位数字，我认为您不会有问题（PCI 规则 声明您可以以明文形式存储它们），但是通过模拟中间六位（或更多）数字，并确保它们通过 luhn 检查您完全有可能复制真实的卡号。此外，当你试图向审计员证明你的不存储真实的卡号。
恕我直言，可能最好重新考虑一下。从你的问题中不清楚为什么你需要一个通过卢恩检查并且看起来像真实卡的号码，但事实并非如此。
编辑：
根据答案中的注释，您可以通过获取真实卡的前六位和后四位数字并将所有其他数字替换为 0 来生成代理。然后通过 luhn 检查运行它。如果无效，则将最后一个零更改为 1，然后重试。继续增加该数字，直到获得有效的数字。您最多需要执行 9 次。它很粗糙并且可以优化，但它会起作用。
@neo has the correct answer (+1 to you) but I just wanted to point out that if I understand what you're doing correctly, it seems like a 'bad idea'. The issuer identifier number (IIN) is the first six digits of the PAN. If you want to store the first six and last four digits, I dont think you'll have a problem (PCI rules state you can store those in plaintext), but by mocking up the middle six (or more) digits, and ensuring they pass the luhn check its entirely possible you'll be duplicating a real card number. Further you'll get into a right headache trying to prove to an auditor that your NOT storing real card numbers.
May be best rethinking imho. Its not clear from your question why you need a number that passes the luhn check and looks like a real card, but isnt really.
Edit:
From the comments in your answer you could generate your surrogate by taking the first six and last four digits of the real card and replacing all other digits with 0. Then run that through the luhn check. If its invalid then change the last zero to 1 and try again. Keep incrementing that digit until you get a valid number. You'd need to do this 9 times at most. Its crude and could be optimised, but it would work.
每个信用卡号码中都有一个测试数字。它是通过Luhn算法计算的。 此处有一个 C# 示例。
There is a testing digit in every credit card number. It is calculated by the Luhn algorithm. An C# example is here.
使用未通过 Luhn 算法测试的代理号码的问题是，当您在任意数量的主机应用程序之一中用代理号码替换真正的 PAN 时，这些应用程序本身具有一些逻辑，可能会接受/拒绝代理号码或根据代理中的属性触发行为。
例如，如果初始数字不代表适当的卡类型（4=visa、37=AMEX、6011=Discover 等），许多电子商务和计费系统也会使用 Luhn 算法进行快速语义验证。如果我给他们一个未通过此测试的代理人，那么它可能会被拒绝。最后，虽然出于 PCI DSS 的原因，他们不想存储原始 PAN，但出于客户服务的原因，他们通常确实需要最后 4 位数字。
我会听取你的意见；理想情况下，我更愿意创建不通过 MOD 10 测试的代理，因为这更容易防御，但我必须了解客户供应商的需求。
关于 Luhn 算法本身，我已经研究了该算法的细节以及 Graham Mitchell 生成 Luhn 传递“假”数字的算法。然而，他的算法是不受约束的——它不是从固定的第一个数字和最后 4 个数字开始，特别是因为最后一个数字本身就是校验和数字。
The problem with using a surrogate number that fails the Luhn algorithm test is that when you go to replace the real PAN with the surrogate in one of any number of host applications, those applications themselves have some logic in place that might accept/reject the surrogate or trigger behavior based upon attributes in the surrogate.
For instance, if the initial digit(s) doesn't represent an appropriate card type (4=visa,37=AMEX,6011=Discover,etc.) Many ecommerce and billing systems also do a quick semantic validation using the Luhn Algorithm. If I hand them a surrogate that fails this test then it might be rejected. Finally, while they don't want to store the original PAN, for PCI DSS reasons, they usually do want the last 4 digits for customer service reasons.
I will take your thoughts under advisements; ideally, I'd prefer to create surrogates that DO NOT pass the MOD 10 test since this is easier to defend but I have to be aware of client vendor needs.
With respect to the Luhn Algorithm itself, I have looked at the details of the algorithm and also Graham Mitchell's algorithm for generating Luhn passing "fake" numbers. However, his algorithm is unconstrained -- it doesn't start with the 1st digit and last 4 digits fixed, especially since the last digit is itself the checksum digit.