Techniques to avoid the oracle attack on matching accounts info that a password reset system could lead to

Let's say you create a password reset system for your webapp. The system requires either a username or an email to send out the reset link to an account's email.

Consider these conflicting requirements:

• Cracker A inputs into the system's form potential usernames (or emails) in an attempt to discover matches currently in the system.

Ideally, the system should neither confirm nor deny the presence of existing usernames and emails, giving exactly the same feedback to either case to prevent revealing matches.

• User B tries to reset their password, but misspells, or worse, misremembers, their user name, such that it does not match any account on file. As such, their reset request will never be fulfilled.

Ideally, their mistake would be made plain to them seconds after they request a reset, with a friendly message like" I'm sorry, we have no such username (or email) on file. You could try checking your spelling, or go ahead and create a new account." Otherwise, they may check their email, find nothing, wait, nothing, reset again, nothing, (because no match is availabl开发者_StackOverflowe to send out) perhaps take their business elsewhere? If you're lucky, call customer service?

What ways are there to resolve these conflicting goals?

Edit:

After thinking the problem through, I'm considering that one way to solve the problem may be using email address only and if that email doesn't exist in the system, send out a "That account doesn't exist, here is a link to make a new account" to the email instead of the reset link.

That way, the user would always get informed, and a cracker could only get emails sent to accounts that they already had access to, which wouldn't be useful to them.

Make sense? Problems with that approach?

The usability for User B probably trumps the security risk for Cracker A, so the key is probably to limit what Cracker A can find out.

One way of handling Cracker A is rate-limiting the responses. User B will submit one request every 10 seconds (say) from speed-(mis)typing their name, and will do so from the same IP address. Cracker A will be trying to submit as many requests as possible in as short a time as possible, possibly from a botnet of many infected PCs under his command. If you always take (at least) 5 seconds to respond to a request, even when your system is perfectly capable of managing requests quicker, then Cracker A can only search a limited portion of the namespace in a reasonable time. Actually implementing this might be harder than I'd like to think it was.

Your system might need to be aware of attack patterns, and if there is a wide-spread attack fishing for responses, it should increase the time to respond. Such techniques require more intelligence in the reset response system, to detect where requests are coming from and how frequently. You might need to spot bad patterns in the IP addresses sending requests. If the same address sends many requests, especially if it does so after getting a match (response sent to given email address), you become rather suspicious of the IP address.