生成可以稍后验证的随机代码
我需要生成验证码并将其发送给客户，以便客户稍后可以提供该代码并由我进行验证。我希望能够在不将验证码存储在数据库中的情况下执行此操作，即代码应该是独立的。
如何生成代码并防止客户猜测有效代码是什么？显然，我不能完全排除幸运的猜测，但我希望此类事件的概率相当小，同时保持代码长度较小。代码可以包含数字和字母。
例如，一个非常基本的验证码将是这样的：随机生成数字1122。现在，计算验证码 11226（1122 并附加其校验和 6=1+1+2+2）。因此，如果客户发回 11226 我就能够验证它，但当然这太容易篡改了。有没有一种方法可以生成这样的代码？
编辑：问题是发送验证码的系统和验证验证码的系统是分开的，这两个系统之间没有信息共享。验证系统甚至无法知道随机生成的数字（示例中的 1122）。我再举个例子：在我的国家，有一个叫做“橙色星期三”的事情。如果您有通过短信接收的代码，您可以以一张的价格获得两张电影票（如果您是 Orange 客户，您可以发送短信并通过短信接收代码）。但是，此代码不与任何内容（电话号码或类似号码）绑定：我可以将该代码提供给其他人，它仍然有效。我需要这样的验证码。
I need to generate a verification code and send it to a customer, so that the customer can then provide the code later and I validate it. I want to be able to do this without storing the verification codes in a database, i.e., the codes should be self-containted.
How can I generate the code and prevent the customer from just guessing what a valid code is? Obviously, I can't completely rule out a lucky guess, but I want the probability of such an event to be reasonably small, while keeping the code length small. A code may contain digits and letters.
For example, a very basic verification code would be like this: randomly generate the number 1122. Now, compute the verification code 11226 ( 1122 and append its checksum 6=1+1+2+2). So, if the customer sends back 11226 back I would be able to validate it, but of course this is too easy to tamper with. Is there a method to generate such codes?
EDIT: The problem is that the system which sends the verification code and the system where the verification code is validated are separated, no information is shared between these two systems. There is no way that even the randomly generated number (1122 in the example) is known to the validation system. Let me give you another example: in my country, there is a thing called "Orange Wednesday". You can get 2 movie tickets for the price of one if you have a code received by SMS (you send a SMS and receive a code by SMS if you are Orange customer). However, this code is not tied to anything (phone number or similar): I can give the code to someone else and it is still valid. I would need this kind of verification code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您正在寻找的内容可以使用消息身份验证代码 (MAC) 来实现：
需要进行的关键观察是：
(message, MAC)元组的给定修改可能产生什么影响。在您的场景中，您可以使用任意消息，因为您唯一的要求是验证从客户收到的输入最初是由您生成的。
实现此目的
012345679xxxxxxx开头的代码，或者简单地将日期编码为“dd.mm.yyyy hh:mm:ss”作为您的“任意消息”。What you are looking for can be implemented using Message Authentication Codes (MAC):
The key observations to make are:
(message, MAC)tuple may have.In your scenario, you can use any arbitrary message since your only requirement is to verify that the input you receive from a customer was originally generated by you.
You can do this by
012345679xxxxxxx, or simply take the date encoded as "dd.mm.yyyy hh:mm:ss" for your 'arbitrary message'.您建议使用校验位。问题在于系统可以很容易地被“弄清楚”并且产生新的工作代码。拥有数据库可以让您跟踪已发送的代码，并确保返回给您的代码实际上已发送。还可以从上述维基百科文章的链接部分查看Luhn 算法。
What you are suggesting is the use of a check digit. The problem is that the system can be "figured out" and new working codes produced fairly easily. Having a database would allow you to keep track of which codes have been sent out and to make sure that the codes coming back to you have actually been sent out. Check out also Luhn's algorithm, from the links section of the above Wikipedia article.
例如，您可以使用公钥加密技术对客户的姓名进行数字签名。在您的服务器上，您将存储一个私人签名密钥，客户会将其发送给您进行注册。到达那里后，您可以签署并将其发送回给客户。验证代码可以归结为根据您的公钥检查签名。当然，这对于阻止诸如欺骗其他客户信息之类的行为没有任何作用，但至少它可以证明对于任何给定的客户名称，无论您是否授权他们，并且您不需要存储所有客户的庞大数据库（虽然我不明白为什么你不想存储数据库，因为你可能至少需要所有这些数据用于法律/财务记录保存目的。）
You could digitally sign the customer's name (for example) using public key cryptography. On your server, you'd store a private signing key, which the customer would send to you for registration. Once there, you could sign it and send it back to customer. Validating the code would boil down to checking a signature against your public key. Of course this would do nothing to deter stuff like spoofing another customer's information but at least it would certify that for any given customer name, whether you did authorize them -- and you wouldn't need to store a huge database of all your customers (though why you don't want to store a database is beyond me, since you'd probably need all that data for legal/financial record keeping purposes at least.)