Automatic Password Reset - is it a good idea?

Question

I am designing a new web application. Each user of the application has an account bound to his e-mail address. The e-mail address is also the username of the user's account.

Users log in using their e-mail address and PIN. The problem is I cannot force users to use passwords that are strong enough; 6-digit PIN is the strongest password they are able to enter when logging in because of some stupid hardware restriction.

I am thinking of resetting the PIN to a random one after specified number of failed attempts as a countermeasure against brute force attacks. This new PIN would be sent to the registered e-mail address.

Is it a good, or a bad idea? Does it provide any extra safety? How much safer is 6-digit PIN which is reset after each 20 failures than a plain 6-digit PIN (how many more guesses do I need on average)?

Are there any other pitfalls I should think about when implementing this automatic reset feature?

Answer 1

Probably not a good idea because if I wanted to prevent Bob from logging in I just can keep sending automated login requests for user [email protected] to your service with any PIN.

Additionally, sending passwords/PINs by email is not recommended because a user's inbox is not a secure location for storage of this sensitive information.

It is more secure in the sense that on every 20 guesses a new PIN is generated, meaning the attacker only ever has a 20/1,000,000 (1/50,000) chance of correctly guessing.

An alternative that avoids the DoS issue is that you could introduce email verification for logins that have more than say 10 failed logins within the last week or so. e.g. when they enter the correct username and PIN combination, an email is sent to their registered account containing a link with a random string. The user must click that email link in order to complete login to your system.

Even if the device with the hardware restriction cannot view the email, another device that can also enter the PIN but receive the email could "vouch" for it this way.

As ilkkachu notes, it would be wise to rate limit login attempts against the same username. However, as the number of possible PINs is 1,000,000, even with a 20 second delay on average, an attacker would be able to gain access after around 17 weeks of constant login attempts. Therefore I would either add 2FA to protect accounts, or implement email verification of suspicious logins in combination with rate limiting.

Answer 2

Theres no problem with this, but a better solution in your case is to use a random "hardware PIN" used only when communicating with the "stupid hardware", that is stored inside account, possibly encrypted with a hash of the user's password. (and to verify password at login, use hash(hash()) of password). Thus you can use a normal password for the web frontend, and thus does not need to enforce hard try limits. (instead you can enforce a timed try limit)

Answer 3

I would say it's a good idea. If you can create it so that if there is a certain consecutive number of wrong PIN attempts, since brute-force will get A LOT wrong at first you can code it so your script notices this, and it will only send one email. This saves your servers handling out way too many unnecessary emails. I would also implement that the IP the user is trying to brute-force from, if you can identify will have their incoming connections blocked, so it fails to connect to you at all. If you can do this, I would say it's a really good method.

Another thing you would have to look out for is if the user trying to brute-force, let's say, knew that this feature was implemented into your PIN system, then he could, more or less perform a MITM attack and hopefully grab the email before it reaches the specified recipient. So cover all your ends and make sure your network is communicating with encrypted SSL, using things like TCPCrypt, etc.

Oh, and people don't usually have to reenter their password 20 times, I would say 10. But, that's up to you, you can put anything for that.

Answer 4

For one, I suppose the system you're planning is for a limited use case, since I don't think it should be impossible to demand a bit more from passwords in general use: even Stackexchange requires eight characters with numbers.

---

In a way, one million possible codes is both very little, and large enough. If an attacker gets your password database, and can try to crack the hashes off-line, they'll be gone in an instant. Even if the hashing would be slow enough to only allow testing for ten codes per second, the whole keyspace would be through in a bit over a day. It's not going to be that slow.

On the other hand, since you can rate-limit on-line login attempts, it should be quite controllable. To get just a 1 % of guessing a passcode, the attacker would need 10000 tries. That shouldn't be usual, especially from a single source IP or against a single account, and you should block the source at that point, and consider locking the account. (If you have lots of users and are attacked by a botnet, then it's harder to detect.)

Though with digit codes, you must make them random, instead of letting the user decide. Otherwise they'll just pick dates, making the effective keyspace seriously smaller. You already touched this when planning a random reset, but it has to be random to begin with, otherwise finding out people's birthdays will be too profitable.

---

As for the automatic changing of the PIN, heck no. Apart from the spam others have mentioned, it might also lock out the legitimate user if they cannot access their email just at the right time. And if you do no rate-limiting at all, they won't have time to read their email before the attacker has churned through another 20 attempts, and the code changes again... Then again, if you do rate-limiting, you could just lock the account on purpose for a while.

Of course, locking accounts is a a DoS vector, but it's a trade-off you need to choose. Do you want to prioritise locking out the bad guys or making sure the good guys get in?

---

Would the automatic changing make the code harder to guess? Well, yes, marginally. For an unchanging passcode, you'd have K in N chance of guessing it, when doing K guesses against N possible codes. For a changing code, the chance of guessing it is a constant 1/N for every guess, or 1-(1-1/N)^K for K guesses. Works out to about 500000 vs. 700000 for a 50 % chance of getting it right. It's more, but in the same scale. Do you want to allow those hundred thousand login attempts in the first place?

Answer 5

It would be a very similar idea to sending the user a 'reset PIN' email when they press 'I forgot my PIN' on the website, but instead of sending them a random one, maybe give the user an option to set there own? That seams to be the standard method. You could lock there account after X attempts forcing them to use the reset PIN option.