All systems for logging in that I know of do not enforce uniqueness among passwords. It would be a strange constraint on a user’s password and I think there are enough of those already. (passwords gone wild)

So, you could never reliably look up a user by the password entered. The only choice is to first look up by the unique token (email address, user name, whatever) and then make sure the password entered matches the password stored. (I’m simplifying, we shouldn’t store the original password.)

With this said, your example doesn’t actually cause a problem. “def” could be the password for multiple people and it is simply ignored because we can make no claims with the paucity of information it contains.

On the other hand, because user names are forced to be unique, we can very well assume that if a person enters John123, they intended to sign in to that account.

It still comes down to an incomplete or misguided notion of security by the developers of the common rails authentication gems.

We’re definitely closer now than we were a year ago. There are getting to be more systems that people are signed into all the time. Outsourcing authentication to those other sites where people are almost always signed in, to automate authentication for your site – where your users are probably almost never signed in – is the way to go.

With the latest funding for JanRain, we’ll probably see many improvements in the coming year.

But for now, as a site owner, I get a bit nervous about my user’s understanding that process. Looking forward to when this is no longer an issue.

However, there’s an even deeper rant that I have… Just use OpenID! Let another service worry about authentication issues. That shouldn’t be your app’s concern. Slap on something like https://rpxnow.com/ and be done with it.

This is wishful thinking, though. It’s the thinking of a programmer who’d rather outsource this nonsense and get to the real meat of the app.

I’m aware that you’ll probably just lose a ton of customers who can’t figure out OpenID. But it’s my dream of convenience that one day, every web app I sign in to is just OpenID.

“They know what the real risks are at work, and that they all revolve around not getting the job done. Those risks are real and tangible, and employees feel them all the time.”

http://www.guardian.co.uk/technology/2009/aug/05/bruce-schneier-risk-security

1. They may already know the username (because they’re targeting a specific person). In this case, obfuscating the error information doesn’t mitigate the risk.

2. The hack attempt is automated and is based on a high volume of attempts. This is what things like Authlogic::Session::BruteForceProtection are for.

3. I assume banks have to worry about this problem more than just some random website. What do banks generally do? Nowadays, they seem to make the login a two-phase process: username first. Presumably, the result of entering a non-existent username is different than the result of entering an existent one. That’s probably the best evidence so far that obfuscating the error information in a one-phase process is a questionable mitigation.

What I’m getting at is there isn’t actually a trade off. If you think you’re implementing a security measure through obfuscation in the login form, but you provide that same information in the forgot password form, then the only thing you are doing is irritating your users. No security/risk mitigation has been implemented.

Unless I’m missing something, which is totally possible.