3

I'm interested in implementing PIN based authentication for a web application, similar to what Facebook provides in their mobile web site.

Here is the user flow:

  1. User visits the site for the first time in a new browser and enters username & password at prompt.
  2. User is prompted to create a 4 digit pin.
  3. On future visits to the site from the same browser only the user can authenticate just by entering the 4 digit pin.

Debugging Facebook in a web browser, I can see that the server returns a new "nonce" after the user sets the PIN and after each successful PIN based login. This nonce is stored in the browser. When the user attempts a PIN based login, the stored nonce and PIN are sent to the server for validation.

What I don't know is what's likely happening on the server.

  1. What might the server be storing? A hash of the nonce + PIN?
  2. How might the server be validating PIN login attempts?
  3. Are there any reference implementations for a system like this that I could look at?
  4. Assuming that the content stored in the browser is not taken by an attacker, is it possible for this system to be at least as secure as traditional username/password authentication? If not, what kind of attack would it be more vulnerable to?
3

Your question seems to be both about, what does Facebook do, and what could be done. I don't know what FB does, but I can try to make some good guesses at what makes a secure system. I hope that helps.

Let me try to rephrase what Facebook is doing. Sites typically support a single factor of authentication, something you know (ie: your password). Sites that support a "remember me" functionality, use the something you have factor (the "something" is the cookie in your browser). This can be weaker as anyone with access to your browser, even a remote attacker, can now log in as you. But not having to type your password every time you access a site, especially if you have a strong password, is a hassle. So Facebook is choosing a middle-ground, basically having a two-factor "remember me" feature where you need the nonce (something you have) and your PIN (something you know).

  1. What might the server be storing? A hash of the nonce + PIN?

It is very likely that Facebook is storing a hash of the nonce+PIN. Note that this could be a simple, secure hash instead of something like the more complex bcrypt password storage function. A hash such as SHA512 is irreversible when operated on large, cryptographically random data strings. The nonce is (presumably) such a random number.

  1. How might the server be validating PIN login attempts?

The server simply redoes the hash and compares it against the appropriate field in the database.

  1. Are there any reference implementations for a system like this that I could look at?

Not that I know of, maybe others can help.

  1. Assuming that the content stored in the browser is not taken by an attacker, is it possible for this system to be at least as secure as traditional username/password authentication? If not, what kind of attack would it be more vulnerable to?

If we make that really big and unfounded assumption, this system is more secure than regular uname/pwd as this has the effect of making the password the concatenation of a cryptographically secure random number, the nonce, and the PIN. Cryptographically secure random number passwords are very strong.

But, in the real world, browser data can never be assumed to be secure so the security of this mechanism boils down to the security of the PIN and nonce. That is difficult to put concretely. This is definitely more secure than simple "remember me" functionality. If your browser data is reasonably secure, this may be more secure than standard passwords. Otherwise, standard passwords may be more secure. In almost any situation, this beats weak passwords because of the something you have factor.

Some points of note:

  • The server must perform the hash. If the client were to do the hash, then a stolen database table could be used as login credentials. This can't happen with the server performing the hash because the hash is irreversible.
  • Extra security could be added by using a password storage function such as bcrypt instead of a standard hash. This is only needed if you use a shorter nonce. Longer nonces will provide sufficient protection against a brute-force attack, even with a simple SHA512 (or similar) being used.
  • I think it makes sense to record failed attempts at PIN logins and, after say 3 failed attempts, delete the PIN login from your database and force the user to login with their password. This provides a lot of protection against a dictionary search for the PIN, even in the face of a leaked nonce, as the PIN will be rendered useless. Even if the user reuses the same number as a new PIN on their next login, they will get a new nonce that an attacker will need to steal to try more PIN possibilities.
  • Thanks Neil. This is exactly the kind of answer I was hoping for. You mention that SHA512 should be sufficient for the stored hash. The is a key thing that I was struggling with on my own before posting here. Why would SHA512 be advisable here, whereas something like bcrypt is recommended when storing salted password hashes? Is it because dictionary attacks are practical on salted password hashes but not on PIN+nonce hash, when the nonce is not exposed? – Jonathan Schoeller Mar 1 '16 at 10:27
  • Yes, dictionary and brute force attacks are infeasible because the attacker needs to guess not just the PIN, but the nonce as well. – Neil Smithline Mar 1 '16 at 15:03
  • 1
    The idea being, that strong password hashes are needed to protect weak or mediocre passwords from dictionary and rule-based attacks. If a good hash is used something like a 5-word diceware phrase will probably suffice in the short term even though it only has 64ish bits of entropy; with a poor hash it will fall quickly to a large organization. With 128 bits of entropy or more (presumably your nonce contains many bytes of random data) there isn't enough computing power in the world to crack the passwords in a reasonable time. Fast hashes suffice if you can guarantee that level of entropy. – Ben Mar 1 '16 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.