In what appears to be some form of risk management strategy, these login forms introduce a different risk to the websites that use the default behaviors – in RoR sites, this is often either AuthLogic or RestfulAuthentication.

Both are broken in a big way.

First, the bug.  And you might not even recognize it is a bug because the behaviour is so wide spread, so ingrained, and so “sensible”.

On almost every login form, if I submit either the wrong username OR the wrong password.  I get the same error message.  Usually it’ll be something brief like the following.

Notice the very important word in this message.  OR.  Because the error message is the same if I enter the wrong user name OR the wrong password, I don’t know which piece of data I entered incorrectly.

I’m guessing virtually everyone reading this is now thinking “well yeah, if you tell them which piece is wrong, someone can keep guessing until they get it right.”

Before we get into that, what are the risks being mitigated in this process?  You don’t want someone to hack into one of your user’s accounts, right?

Right.

But what else?  How about the risk that someone, a new user, comes back to your site and has forgotten which password they are using?  Maybe you forced them to use some complex password.  Maybe not.  In any case, maybe they want to use your site, but it isn’t really that important.  As web app builders, we’re constantly thinking about lowering the barriers to join and begin using a web application, right? Why would we add a barrier here.  It is possible that a user with difficulties signing in might just leave.  Never to come back.  Never to pay you for your service.

All because you were not kind in telling him/her why the credentials they gave on login didn’t work.

So, that’s a risk.  And for a startup, this is a significant risk.  You need every new user you can get.  Especially those people that have taken the time to actually create an account.

But let’s get back to the “common sense” reason for not telling the user more about why their credentials didn’t work.

You may notice on the signin form above, that link to “Forgot“.  If you click that link and enter a user name (email address in this case), the system will almost always tell you if that user name exists.  Using the above site, it’ll look like this.

So, lemme just repeat the problem.

Login forms almost never tell you if your user name is wrong

Compared with

Forgot password forms almost always tell you if your user name is wrong

So let’s get back to that risk that is supposedly being mitigated by not telling the form submitter what piece of data is wrong.  We’re trying to keep people from guessing user names, right?  And yet we provide a form for doing exactly that!

The risk is not mitigated in the slightest by the error message.  Not one bit.

Now, I’m not going to go into how this process should be done.  For two reasons.  One, I’m out of time for writing this morning.  And Two, because I want people to disagree with me so I can understand their thought process.  It is possible I’m missing something here.  Unlikely, but possible.

It opened a new window to this page which looks like this screenshot (for those who dun wanna click.)

Hopefully you can see that search box in the upper right of the page. If you’re looking for help, don’t search there.

That is the search box in the header of every page of Adobe.com (well, most every.)

In many cases, putting a search box in the header of every page is a good idea. When it’s a bad idea is when you’re on a page with its own specialized search, like the help page for Photoshop Express.

On this Photoshop Express Support Center page, the knowledge base search is below the fold. Below. The. Fold. (inexcusable)

Ok, so there are 2 Major things wrong here:

• Don’t put a site wide search box at the top of a subject domain search page.
• Put the search of a knowledge base above the fold of the help home page

Nielson has lots of data about how many users are search centric and how many web users scan quickly for the first search box they can find. On this page, that strategy would fail because they’d be searching the overall Adobe.com site. Oops!

There is a simple solution. Make the site wide search contextual and don’t display it on pages such as the Support Center home page which have their own, highly specific search functions.