The God Login

Please be aware that keyboard use is not just for power users or password managers. Keyboard navigation is essential for screen readers and is step 1 of testing your site for accessibility.

1 Like

I believe there are attributes you can set on input fields to tell the browser to not autocapitalize… login forms should add this to the username field.

You don’t have two input password fields to verify the user’s password upon signup. People might type it in wrong. You can’t be serious when you say you have a good singup box, right?

I have little hope for SQRL to ever become mainstream, but I really want it to.

Given the choices you have already made, your login dialog could be further simplified to just two fields and one “Login/Register” button. If there is no email address matching the user input, you can then ask if they would like to create a new account. If the password does not match, you can ask if they have forgotten their password, and would like a reset email sent.

In any event, you should never clear the text fields, so that if the user has simply made a typo it is easy to fix.

This would particularly suit me. If I want high security for a site (that does not provide two factor authentication), I often just use a really long random string as a password, that even I do not know, and then use the reset email as my primary way to access the account (setting a new long, random password on my way back in). Always having exactly the same dialog would be my God login!

In addition to Google, Facebook, Twitter, Yahoo and Github, any reason why Microsoft account support is not provided as one of the options?

Well, there’s one thing to stop people from doing that. Namely, such a solution basically requires a confirmation email is sent, received, opened, and the link clicked upon before that account can actually be used.

This in itself is a major source of lost users, and the reason why many organizations have made email confirmation optional in their sign up funnel.

Unless your service is truly reliant upon email integration for your users, you’re probably better of using a combination of rate limiting and suspicious behavior identification.

Forgive me if this has already been covered, but I think the idea of preventing people from signing up with popular passwords is at least a bit more problematic than it is helpful.

Initially I was going to complain that a mere 10,000 wasted attempts per hash wasn’t that much, but it turns out that even in 2015 bcrypt, and especially scrypt, hold up incredibly well even with GPU hashing.

That said, I think what you’re looking at is adding at most 20 minutes per hash (assuming they have to use CPUs) onto the cracking time if you’re using a bcrypt factor of 10 or scrypt factor of 13. Check out this video for some interesting stats on that http://video.adm.ntnu.no/pres/5499318fcce2c.

And what do you trade for that? A large majority of your users, for most sites, are then forced to use a password that they don’t normally use. A password they’re likely to forget. If they even bother continuing to sign up after some stupid website told them their password was dumb. And it’s not like the acceptable password they choose is going to be massively better, it’ll probably still be in the top 100,000 or million passwords guessed by a competent cracking program.

Philosophically, I think it’s my responsibility to assume that every single one of my users is so unconcerned about security that they really will make their password ‘password’ (or whatever minimum additions to that are required to fit my stated requirements). The best I can do is pick password-related technologies and designs that protect them as much as possible in the event of a breach.

The user’s responsibility, OTOH, is to assume that I’m so unconcerned with their security that I’ll store their passwords in plaintext. In that case they’d use a password manager, or insist upon a stronger technology like PAKE and/or two-factor auth. Sadly not enough users assume this, but we also can’t make them.

I literally rushed to add this comment, in the hope, however vain, that it would be the first. Alas…

1 Like

I like the game. If we extend this outside the www domain. Cop stops you and asks for your driving license. What will a GOD require? He wouldn’t stop you, just write you a ticket and withdraw fine from your bank account. Sounds freakish! :smile:

1 Like

Because the same login credentials are likely to be used on banks and other sensitive sites visited by the user. Since most people stick with passwords that are easy to remember, they’re probably using them everywhere, so their security profile is a chain as strong as its weakest link. A hacker who’s obtained hundreds of user logins is guaranteed to have at least a few dozen of those that are valid for BofA.com, PlayStation.com, etc.

With most registration tools only the encrypted version of the password is stored; it’s hashed before being saved to the database. So there’s no server-side access to the unencrypted password to populate the form with it. That’s the same reason why most “Forgot your password?” links require a password reset, regardless of how annoying it is to the user.

Of course, forms could probably do some client-side validation and simply reject invalid submissions up front so that the password remains in the field.

I disagree with the rather pedantic arguments in the left column implying that “Sign Up” and “Sign In” are indistinguishable. On the contrary, they’re visually and grammatically consistent, and since they’re different buttons in the same region, users can easily parse that they’re distinctly different options. This is what Tufte calls the Least Effective Difference. You don’t need to accentuate the difference further by varying the wording or style. I personally find those superfluous differences aesthetically incoherent without offering any additional usability advantages in return.

I came across a lot of those password length limitations and forbidden characters etc. One website even required me to use a number in the username.

I don’t get why web sites need those limitations in the first place. I mean, they should just do SHA2(saltySalt + “correct horse battery staple”) anyway.

I wonder what they’re doing. Using their own basement-grown hash? Or maybe they’re not sure which characters will cause mysql_query("INSERT INTO my_users VALUES ('$user', '$password')"); to break.

Instead of telling users that they gave the wrong email address on the site, why don’t you just send an email to them at that address telling them of the error? That way hackers can’t use your form to expose user accounts. Within that email you can provide a link to recover the forgetten email address using security questions.

If they sanitized their inputs then all characters would be safe. Since they’re hashing (salted bycrypt ) anyway (or should be) there is no need to worry about odd characters.

Did you consider Mozilla Persona? I see it as the spiritual successor to what OpenID tried (and somewhat failed) to do and the interesting part of it is that some of what I think makes it superior to OpenID are similar to some of the thoughts presented in this blog post. The most obvious one being that Persona revolves around email address as the key username/login field (in the same way that classic, vanilla OpenID revolved around a URL). I think Persona has a really nice login flow and I’m somewhat disappointed that more websites aren’t using Mozilla Persona… (Yes, I know Persona development resources are currently on “life support”, but in the typical open source spirit, it won’t get more developer resources unless more websites and people start to actually use it.)

Fucking Good Post :slight_smile:

I can’t agree with the notion that a single email address provides identity. Email addresses aren’t permanent, can be retired or lost or stolen, or just you & the company providing that email address have parted ways (for a host of reasons).

Frankly I’d be happier if the N systems that store my details don’t have my email address at all, so that when Baby’s First Forum gets hacked (again), the hackers didn’t hoover my email address to sell to spammers, or that they automatically have my username for logging into N other sites. The less these arbitrary websites know, the better in my view.

Please consider the use case of someone who forgets whether they’ve signed up, or forgets what the password criteria are!

User forgets they have signed up: now to press either log in or sign up, guessing… Why not have a single button that does either? If they’ve signed up and the login matches, log them in. If it isn’t in the database, sign them up. One button is all you need.

Otherwise, if I haven’t signed up, I want to sign up, and you’re going to make me put it in again. Or if I try to sign up and it turns out I already have, then I want to log in, and you’re going to make me put it in again.

User forgets the password requirements: Often I create a password to fit the requirements on signup. But going back to the site, I am not told those requirements on the login screen, so I try a password, it fails, I get a change-password email sent, I go to the change-password screen, and finally read the requirements. Ah! Of course! It was atomicBomb3.14, because I needed a punctuation and a number and uppercase. I think I changed my password for my credit card authentication about 20 times because I could never remember the requirements and ALSO you were prevented from using the previous password! So now that I knew what the requirements were, I could no longer use the password I knew it was. Grrrrrrrrr.