PHP client PIN security

Question

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:

1. Is this practice acceptable?
2. Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?*
3. Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
4. *Should I make use of a captcha system?

Answer 1

1. yes but it depends on the value of the information,if the information value is hight and you think that someone may try to break in you should consider additional protections
2. It may be a good idea if the information you are protecting have an hight value,in this case you must warn the user that he have a limited numer of possibilityes,create also a log file to monitor failures on code typing and consider that if the user is behind a NAT a lot of user may use the same ip(all the user on an office or in school for example,also connection like fastweb use one ip for a large group of people) so don't block the ip for a long time(15-30s every 3-5 fails should be enoght to avoid brute force attacks,you can double it every time the user fails a second time)and,most important,block only the code immission not the whole site.
3. it's not needed but you can implement it,as i sayed it also depend on the value of the information
4. it's a great idea to avoid proxy and crawlers but i recommend something different: use an image with a question like " five plus 2 =" or "what's the color of a red apple?",they're a lot more hard to understand by crawlers but a lot more easy for users.

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

 AXV2-X342-3420

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?!").

Answer 5

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.

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").

Is this practice acceptable?

I think it is acceptable, although very strange.

Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?*

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.

Should I write an error checking system (similar to Luhn's algo in credit card numbers)?

I don't think so.

Should I make use of a captcha system?

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.

Answer 6

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 (64 310 = 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.

Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?

IPs can be spoofed.

Should I write an error checking system (similar to Luhn's algo in credit card numbers)?

That would actually decrease the number of bits in your entropy, making it easier to break into your system.

Should I make use of a captcha 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:

1. The technical expertise of your users
2. The willingness of your users to put up with security
3. The cost (time and money) to implement and maintain (i.e., a more sophisticated system will generate more support calls)
4. The impact a breech would have on your users and company
5. The likelihood of a breech: are you the US Department of Defense? Visa? You're probably under attack now. Bob's Bicycle Shop in Ojai, CA is on the other end of the spectrum.

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.