The God Login

I graduated with a CS minor from the University of Virgina in 1992. The reason it's a minor and not a major is because to major in CS at UVa you had to go through the Engineering School, and I was absolutely not cut out for that kind of hardcore math and physics, to put it mildly. The beauty of a minor was that I could cherry pick all the cool CS classes and skip everything else.


This is a companion discussion topic for the original entry at http://blog.codinghorror.com/the-god-login/
3 Likes

One subtle tweak… the Sign In and New Account buttons should have some space between them, to reduce the chance of a misclick. And the “expected” action should be the one directly below the name/password fields.

I find it kind of weird that the “Login” button looks different in different places:
Once, it’s an open lock, and once a person. Is there any particular reason for that?

All very good points, and it leads to a discussion about passwords in general. Pet hate of mine is websites that don’t allow anything other than alphanumeric characters, to my mind the site itself is not secure when they won’t let me use ! in the middle of my password string.

Have recently had to give up an account because the site decided that a few failed login attempts (thanks to a 2 year old) was a security risk, so they changed my password for me (gee thanks). They won’t show me all of the email address although from what they did show me I could figure out which one it was - and their forgot password email never arrives (apparently a common problem with this very large site). Naturally of course there is no way to contact anyone there either.

And in a site I run I often get people trying to be reunited with accounts where they have no matching information, yet they claim that they are the owner but they used false info for privacy reasons - if all I’ve got to go on is an email address, first name and birthdate and you’ve changed those then I’m not giving you this old account! I’m setting up a page of security questions to hopefully tackle that in the future.

I you don’t respect the {USERNAME}{TAB}{PASSWORD}{ENTER} sequence on your login form, me and my friend KeePass will be constantly looking for another alternative website. That and also making sure the title of your login page includes your website’s name and not only a generic “Log In” title.

Unless it’s your mobile phone number: Chinese Mobile App UI Trends

Maybe these plugins can help you with the “log in” titles:
http://keepass.info/plugins.html#urlintitle

These plugins show the URL of the website in the titlebar.

1 Like

A bit offtopic, but this has to be cutest login form from all. Try entering password:

7 Likes

This is awesome. Thank you. I’ll keep those in mind for the future as currently I have no websites with this problem as I just leave them behind hehe. And I have more than 400 entries in KeePass :smile:

Consider not giving the user a big and scar warning about caps lock, but instead check his password against a case-inverted version of itself.

1 Like

Have you thought about supporting SQRL in the future? Login without username, password or email. Very close to the way god would have designed it.

5 Likes

Seems like a bad idea; a lot of people use Caps Lock as an ‘easier way’ to type lots of characters in capitals. And they may not use it consistently. When they didn’t use it when signing up or changing their password but they are using it now, you will get a mismatch and you’ll be punishing them for not being consistent. That would be bad form.

A lot of users end up being behind the same proxy exit servers, and thus having the same small pool of IP addresses - back in the day, AOL was the biggest offender here. Be careful that rate-limiting bad logins by incoming IP address doesn’t make life hell or at least very confusing for these users. Perhaps make it based on the combination of email address -PLUS- IP address.

Another one that drives me nuts is the auto-caps of the first letter in a text input applied by Mobile Safari: giving the browser an indication that the field is an email or username is a must.

1 Like

Ok, I guess I am Frank9 here. yuck…Anyways…I liked this post Jeff. I am going to refer to this when I revise my login system to my CMS tool. I am dealing with an incremental rewrite with a designer in a few weeks and it definitely short circuits whats important and what is better than acceptable (I usually don’t have the luxury to think about this stuff the way you guys did). So you taught me something useful today…I can’t wait to see what else is up your sleeves on future projects. I have come to the conclusion that you and Sam and the Troutfish, make the internet a better place. Optimal Tip to Tip Efficiencies here. (second to last sentence is a honest sentiment and the wording came out funny, and the last one…well you get the joke(segway);

:slight_smile:

The idea is to accept both versions of a password always, effectively trading 1 bit of password security for a lot of user convenience.

1 Like

First time trying Discourse. Looks nice…

Regarding your email is your identity… I think, you’re identity is your identity. Email Twitter Facebook these are best considered - not identities but means of verifying your identity. So your “identitly record” in a system is related to each of those, but not one of those defines it. For a long time I thought using email address as your de-facto identifier as a login name made good sense.

I’m an older guy (w/ a teenage daughter), and its striking to the extent email is becoming much less relevant to the younger generation. They will inevitably have all of Twitter, Tumbler, Email address, and mobile phone number, but keying in on one as the God “identifier” if you will feels a little off.

The box with login w/Twitter, Facebook, etc… seems the right solution for the present, but still feels not quite right, at least not totally elegant. A universal standard for internet identification of course would consolidate and simplify things, but not just the adoption by so many providers, but the concerns about privacy and tracking etc… would seem difficult to even get off the ground.

One thing that’s always bugged me is forms, like the Discourse one, that effectively have login and register on the same form but if I put my name/pass in one form don’t carry them to the other.

In other words, I see both “log in” and “create new account” at the bottom. I type my username and password and click “create new account” expecting it to create a new account with the name and password I just typed. Instead it says Haha for typing your name/pass and clicking “create new account”. Instead I’m going to discard what you just typed and make you type it again because that misleading button actually leads to a different form. F.U!

WHY!!!

First you mislead me by putting 2 buttons that look like actions but one is not the action it claims it is. It’s not going to “create a new account” it’s going to “switch to the create new account form”.

Second you waste time type and throw away my work. This is especially infuriating if I happened to enter that on mobile where typing is super tedious, especially if my password follows some crazy rules.

It seems like copying the name/pass from one form to the other (or making them the same form and hide/un-hide the extra fields for registering) would be more respectful of the user’s time and slightly mitigate the fib that “create new account” doesn’t actually create a new account.

3 Likes

Malicious humans or bots can already figure out if an email address or username exists in the system by trying to make a new account with that email address or username. I don’t think there is any advantage to trying to hide that information here.

3 Likes