PHP 客户端 PIN 安全
我目前正在开发一个系统，该系统具有这样的功能：客户可以通过提供 PIN“号码”来查看其购买/续订/等详细信息。
由于我们的目标客户类型不同，因此使用 PIN 代替登录信息。 PIN 码打印在发送给他们的文件上。
他们提供 PIN 码时显示的视图不会显示信用卡等高度敏感信息，而是显示不太敏感的信息，如产品名称、类型、价格、条形码、维修等。
有问题的问题是 PIN 码。我选择使用随机的 5 个字符 PIN（0-9，az AZ） - 区分大小写。 我将删除一些同形文字 ('I','1','l',' 0','O','rn','vv')，所以实际的组合数量实际上更少。
我对此有几个问题：
- 这种做法可以接受吗？
- 我应该编写一个锁定机制来“禁止”来自大量失败尝试的 IP 的流量吗？*
- 我应该编写一个错误检查系统（类似于信用卡号中的 Luhn 算法）吗？
- *我应该使用验证码系统吗？
I'm currently developing a system which has a functionality where clients can view details of their purchases/renewals/etc by supplying a PIN "number".
A PIN is being used instead of login information because of the type of clients we're targeting. The PIN is printed on documents sent to them.
The view shown when they supply the PIN does not reveal highly sensitive information such as credit card etc, but less sensitive one such as product name, type, price, barcode, repairs etc.
The issue in question is the PIN. I opted to using a random 5 character PIN (0-9, a-z A-Z) - case sensitive.
I'll be removing some homoglyphs ('I','1','l','0','O','rn','vv'), so the actual number of combinations is actually lower.
I've got a couple of questions about this:
- Is this practice acceptable?
- Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?*
- Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
- *Should I make use of a captcha system?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
至于验证码和锁定 - 我会选择验证码，并延迟 1）验证码失败的客户端，以及 2）无效登录：在检查之前，第一次尝试睡眠 1 秒，第二次尝试 2 秒，第三次尝试 4 秒，8 秒随后的。这不会给普通用户带来太多不便，但会显着减慢攻击者的速度。无论您做什么，人们都会出错 - 无需完全禁止它们。
校验和 - 作为第六个字符可能有用，用于检测打字错误，而不是为了安全。
就密码强度而言，这是一个弱密码 - 我不会使用它作为任何比“分享 lolcats 图片”更强的授权形式 - 考虑更长的密码，或者您的客户甚至可能会意外访问彼此的数据（当发生这种情况时，他们往往会非常感到不安：“您的意思是任何人都可以看到我的这样的数据？！”） 。
As for the CAPTCHA and lockout - I'd go for the CAPTCHA, and delay 1) the clients that fail CAPTCHA, and 2) invalid logins: before checking, sleep 1 sec on 1st attempt, 2s on second, 4s third, 8s on subsequent. This won't inconvenience normal users too much, but it will slow down an attacker significantly. No matter what you do, people will get it wrong - no need to ban them outright.
The checksum - might be useful as a 6th character for detecting typing errors, not for security.
As far as the password strength goes, this is a weak password - I wouldn't use this as the only form of authorization for anything stronger than "sharing pictures of lolcats" - consider a longer one, or your clients might even accidentaly access each other's data (and they tend to get really upset when that happens: "you mean that anyone could see my data like that?!").
很奇怪，但是可以这样写。我觉得你真的应该重新考虑一下是否真的有必要。但如果我理解正确的话，您是通过蜗牛邮件发送文件的吗？例如，是否可以向用户发送 PIN，然后让他们登录 openID(LightOpenID)。我会将其锁定为 Google 的 OpenID 提供商，因为这些帐户是“安全的”。这样您就增加了另一个级别的安全性。谷歌还使用验证码来验证帐户（使其
“安全的”）。
我认为这是可以接受的，尽管很奇怪。
我认为你应该编写一个锁定机制，因为暴力破解密码已经很容易完成，但暴力破解 PIN 可以毫不费力地完成。虽然我不认为你应该通过 IP 来做到这一点，因为最终用户可能坐在路由器后面，然后他就会被阻止。黑客也可以拥有僵尸网络来执行此类攻击。
感谢 stackoverflow.com，我今天读到了关于 HashCash 的内容，我也发现它非常有趣。也许你可以用它来保护自己免受攻击。
我不这么认为。
防止自动攻击的唯一真正方法是验证码，所以我认为你应该这样做。 Google/Twitter/等不使用验证码不是因为它们对用户友好，而是因为这是阻止自动攻击的唯一有效方法。如果您要使用 Google 的 OpenID 来实现我的系统，那么您可以跳过此步骤，因为 Google 已经为您提供了帮助。
Very strange, but yeah could write it like this. I think you should really reconsider if it is really necessary. But if I understand you correctly you sent the document via snailmail? For example Isn't it possible to send the user a PIN and next have them sign into openID(LightOpenID). I would lock it down to just Google's OpenID provider because these accounts are "safe". This way you have added another level of security. Also Google uses captcha to verify account(make it
"safe").
I think it is acceptable, although very strange.
I think you should write a lockout mechanism should because brute-force hacking password is already easily accomplished, but brute-force hacking a PIN can be done without any effort at all. Although I don't think you should do it via IP, because the end-user could sit behind a router and then he would be blocked. Also hackers could have a botnet to perform these kinds of attacks.
I read today about HashCash thanks to stackoverflow.com and I also found it very interesting. Maybe you could use that to protect yourself against attacks.
I don't think so.
The only true way to prevent automated attacks is CAPTCHA's, so I think you should. Google/Twitter/etc aren't using CAPTCHA's because they are user friendly, but because that is the only working way to stop automated attacks. If you would implement my system that PIN with OpenID from Google then you can skip this step, because Google already has you covered.
首先，不仅要求提供 PIN 码，还要添加一些客户知道的简单内容，例如在普通邮件系统中，您经常会被要求提供邮政编码。这对那些不知道某种“共享秘密”的人进行了分类。
如果验证码不是太难的话，那么它是有意义的，因为它有助于减少机器人的“猜测”尝试。正如 Stefan 提到的，由于共享 IP，按 IP 禁止是有问题的。
当基于错误检查的表单帖子错误时，您还可以实现某种“焦油坑”，例如，延迟传入连接的处理。简单的算法错误检查可帮助您避免对给定 PIN 进行无用的数据库查找。
First of all, ask not only for the PIN, add something simple the customer knows, like with snail mail systems where you're often ask for your ZIP-Code. That sorts out people that do not know the somehow "shared secret".
The captcha, if it's not annoyingly hard makes sense as it helps to reduce "guess" attempts by bots. As Stefan mentioned, banning by IP is problematic because of shared IPs.
You could also implement some kind of "tar pit" when form posts are wrong based on your error checking, e.g. you delay the processing of incoming connections. A simple algorithmic error check helps you to avoid a useless database lookup of the given PIN.
1）是的，但这取决于目标受众。
2）有时它是有意义的，有时它不起作用，因为系统的使用方式以及共享IP号码上有多少客户端。
3）它会增加什么价值？这难道不会帮助人们找到有效的 PIN 码吗？
4) 取决于目标受众以及验证码类型。
1) Yes, depends on target audience though.
2) Sometimes it makes sense, sometimes it won't work due to how the system is used, and how many clients are on a shared IP number.
3) What value would it add? Won't that just help people trying to find a working PIN?
4) Depends on target audience, and what kind of captcha.
我还建议您使用 mt_rand() 来随机化 pin（比默认随机更有效，它在统计上是正确的随机，并且默认集成在 php 中），同形文字删除应该是避免错误输入的好方法，但我可能还建议创建一个带有分隔符的较长代码，
这样用户应该理解这是一个代码，并轻松计算剩余的字符数或是否输入了错误的代码。
我可能会避免区分大小写的 pin，因为大写字符更容易阅读，并且即使您清楚地写出代码区分大小写，某些用户也会简单地将其粘贴为小写或大写。
I recommend also you use mt_rand() to randomize the pin(a lot more efficient than the default random,it's statistically correct random and it's integrated in php as default),the homoglyphs removal should be a good way to avoid error typing but i may recommend also to create a longer code with separators like
so the user should understand that's a code and easly count how many character are left or if he entered the wrong code.
I may avoid case sensitive pin because upper case characters are more easy to read and some user will simply paste it lower or upper case only even if you write clearly that the code is case sensitive.
公理“如果你要推出自己的安全性，你就已经失败了”，此处适用。
对于 5 个字符 [0-9、AZ、az] 引脚，您生成的熵少于 8.27 位 (
64310 = 2^n)。 [已修复]需要不到一天的时间（每秒 1,000 次猜测，对于攻击者来说，破坏您的系统的速度非常慢）。这是可以接受的吗？也许对于绕过安全性影响很小的普通系统来说。
IP 可能会被欺骗。
这实际上会减少熵中的位数，从而更容易闯入您的系统。
如果你觉得你需要锻炼。 验证码已被破坏并且除了作为减速带之外，它们没有任何用处。
更新
不幸的是，计算机安全没有现成的解决方案，因为它仍然是一个不成熟（不成熟？）的领域。任何说“哦，这样做，这样就没事了”的人都在跳过安全方面最基本的问题之一。
安全始终是一种权衡
最终安全的系统无法访问。另一方面，最终可访问的系统没有进入障碍。显然，这两种极端都是不可接受的。
作为软件开发人员，你的工作就是找到两者之间的最佳平衡点。这取决于几个因素：
从你的问题来看，我认为你正在有效地为他们生成“密码”。如果你把它翻转过来会怎样？将 PIN 设置为他们的帐户，当他们第一次登录您的系统时，他们必须创建一个密码*，从那时起就需要该密码。
*是的，如果这是一家银行，那么这不是一个好主意。
The axiom "If you're going to roll your own security, you've already failed," applies here.
For your 5 character [0-9, A-Z, a-z] pin, you're generating less than 8.27 bits of entropy (
64310 = 2^n). [fixed]It will take less than one day (a 1,000 guesses/sec, which is very slow) for an attacker to break your system. Is that acceptable? Maybe for trivial systems where bypassing security has very little impact.
IPs can be spoofed.
That would actually decrease the number of bits in your entropy, making it easier to break into your system.
If you feel you need the exercise. Captchas have been broken and are useless for anything other than as a speed bump.
Update
Unfortunately, there is no cut-and-dried solution for computer security, as it is still an immature (undermature?) field. Anyone who says, "Oh, do this-and-this and you'll be fine" is skipping one of the most fundamental issues around security.
Security is always a tradeoff
The ultimately secured system cannot be accessed. On the other end, the ultimately-accessible system has no barrier to entry. Obviously, both extremes are unacceptable.
Your job as a software developer is to find the sweet spot between the two. This will depend upon several factors:
From your question, I take it that you're effectively generating their "password" for them. What if you flipped it on its head? Make the pin their account and the first time they log into your system they have to create a password* that is then required from then on.
*Yes, if this is a bank, then this is not a good idea.