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.

You can argue about whether any given non-implemented or not completely implemented feature is important. But stack it up against releasing the features that *are* implemented. Does the cost of its absence or the benefit of its presence outweigh the cost of not delivering what’s already done?

Talking about requirements often leaves unchallenged the notion that there is some System that is the full and complete set of requirements. Feature talk is all about a world of infinite variety and choice.

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.