
The God Login - robin_reala
http://blog.codinghorror.com/the-god-login/
======
laurencei
The author refers to "Handle common user mistakes" \- by displaying a message
"your caps lock is on".

Personally I love the Facebook approach. Facebook just accepts passwords with
caps lock inverted, so you never have the problem in the first place. No need
to display a message to the user.

Link: [http://www.zdnet.com/article/facebook-passwords-are-not-
case...](http://www.zdnet.com/article/facebook-passwords-are-not-case-
sensitive-update/)

~~~
nmc
This "Facebook approach" almost certainly requires you to have, at least once,
access to your users' non-hashed passwords.

Which is widely regarded as bad security practice because your users'
passwords can be compromised by an attacker getting read-only access.

[EDIT] Well, good thing I used "almost", since I was wrong: of course, case-
inverting the password and hashing the result could also be done client-side,
silly me!

[EDIT'] Answers pointing out that you always have access to non-hashed
passwords, and I believe this is wrong. When the user submits their password,
it _SHOULD_ be hashed _client-side_ and only the hash _SHOULD_ be sent to you.

~~~
dsacco
You're right that it's bad to store non-hashed passwords, but your point about
security is unfounded.

Facebook, and any other company you'll log in to, requires a non-hashed
password _at some point_ to check against the hash. You need a cleartext
password at some point, otherwise the user can't send anything to you.

The best practice for security is to not _store_ passwords in cleartext. You
can certainly perform extremely limited actions on passwords in cleartext
(like hash checking), and you inevitably have to.

Which brings me to my overall point - as the Facebook security team has
explained before on their whitehat page, you do not practically reduce
security by allowing caps lock inversion to check a hash.

What you're saying about Facebook having an abnormal process also isn't true
either - Facebook does one of two things, both of which are secure:

1\. Stores two hashes for each password, one the real password and the other
the case inverted, or

2\. Checks a password against a hash, and inverts the case and checks again if
it fails.

There is nothing about this which is different from normal password
transmission in cleartext, and Facebook doesn't store the cleartext password
you send them.

EDIT to your EDIT:

No, no no no no, no. Don't do clientside things like that. Allowing a user to
directly manipulate something as major as whether or not their password is
hashed before it is sent to you is bad. It doesn't even matter that it's just
them hacking themselves; it's just bad form to put that in their browsers'
hands. Plus, a stored cross-site scripting error that went viral on the login
page pre-auth could screw your password database, leading to a layup for mass
cleartext password compromise. Or in a worse scenario, you're giving a user
direct write access (and then maybe reads) to the password database.

It's much safer to do the industry best practice of destroying cleartext
sensitive information upon successful hash.

Say no to clientside security. There are arguments for hashing clientside, but
they can all be summed up by "You shouldn't let people potentially sniff
users' passwords" \- if you implement TLS/SSL correctly, this won't be an
issue and the cleartext password will exist briefly, then get destroyed.

The one other argument is that someone could compromise the server handling
the hashing process and write a script watching all the passwords. But this
isn't a valid concern - if someone has backdoored your login server, it _no
longer matters if passwords are cleartext_ for the damage they'll do. The
level of difficulty you introduce by having passwords hashed originally
becomes moot at that point.

Finally, consider that a client-side hash of a password sent to a server
becomes the effective password for that user, not the _hash of the password._
This means that, effectively, if no other action is done at the server, you're
actually then storing the password in plaintext. If a user was MITM'd while
sending the password, the hash can now be sent directly to the server in place
of the user's password, because it is the de facto password.

The bottomline: client-side hashing offers no real addition to overall
security posture under TLS/SSL, and removes most of the benefit of hashing.

~~~
ceallen
> if someone has backdoored your login server, it no longer matters if
> passwords are cleartext for the damage they'll do. The level of difficulty
> you introduce by having passwords hashed originally becomes moot at that
> point.

If your hacker has a cleartext password and their login ID (email address),
you've just given the hacker access to a bunch of their other accounts on non-
compromised sites (for the significant % of your userbase that recycles
passwords). I think the possible collateral damage creates a far more severe
worst-case scenario.

~~~
dsacco
That's a fair point, though it doesn't outweigh the myriad other reasons not
to do client-side hashing.

Security is always a battle of usability and tradeoffs. Client-side hashing
simply doesn't make sense for security. It removes the fundamental point of
the hash in the first place and introduces an avenue for possibly attacking or
manipulating your database.

In fact, there's hardly ever a reason to do client-side security.

~~~
mentat
Perhaps you can quality "client-side security"? You mean never trust the
client right?

~~~
dsacco
Yes, that's exactly what I mean. Treat all user-input (and by extension,
client-side anything) as dangerous. A server putting a security protocol in
the hands of the client when it is not unavoidable is usually bad.

------
laurencei
I never really understood the reasoning behind the whole "maybe your email or
password is wrong - but we wont tell you which" message that websites love to
give.

The reasoning tends to be along the lines of "prevent spammers getting emails"
and "security by obfuscation".

But almost all these websites have a sign up page, and if the email address is
already in use they will happily let you know that.

Therefore if a hacker/spammer/bad guy wants to brute force your application
for emails - they can just use the 'sign up' page to get the emails instead of
the 'forgot password' page.

~~~
unfortunateface
I would argue that registration pages should not let someone know if an email
is in use - if a duplicate email is used in registration then the site should
just send a quick email notifying the user that this email is already in use
(with sensible DOS protection and email opt-outs etc.)

Your use-cases miss out one type of hacker/spammer/bad guy - the one who is
only looking for you, they know your email, they want to profile you
specifically.

Over the top/exaggerated example (with many implicit caviats!)...

Mr Smith has Mrs Smiths email - he uses it to try to register with a Dating
Website - but hold on, it's already registered!

Now there could be 3 reasons for this...

1\. infidelity

2\. It pre-dates the relationship

3\. A third party trying to cause trouble by signing Mrs Smith up.

I don't believe a company has the right to decide what data they hold on you
is visible to the outside world - without expressly asking you.

~~~
maaarghk
What happens on the front end in that case? Would it be an irritating "Please
check your email to continue registration" kind of situation? Because people
don't like that as of 2010 ish

~~~
unfortunateface
What sp332 said - there wouldn't be any extra steps as you would have to go to
your email to complete registration anyhow.

You could have an extra link in your email which lets you update your existing
registration details with the ones you've just entered, but that's not going
to significantly extend the amount of time you take to register.

------
AndrewDucker
This is what I was hoping Persona would do for us - you could click "Login",
it would ask which identity to use, and then use that to log you in.

Sadly, it doesn't seem to have achieved enough traction (although I still
hope).

~~~
WorldMaker
Me too. Persona is great and has a very nice login flow, and is the best as a
user in terms of what is/is not shared with an IdP... Just need to get more
websites to use it. (I've written about setting it up in an ASP.NET website
and it is really easy to do and work with.)

------
s_kilk
In a recent side-project ( nightchamber.com ) I experimented with the idea of
something like a "God Login". A user account is automatically generated on
first visit and keyed against a uuid, the id is then stuffed into the session,
and used to make a link the user can bookmark to get back to their "account".

As long as that link/id remains secret, the user has a unique account to use
with no effort on their part.

I'm still not sure this is a good idea, but it seems to work for nightchamber,
where the account doesn't actually have much value, and there is no valuable
information an attacker could gain by "compromising" the account.

~~~
FreezerburnV
Have you considered being able to convert between an automatically-generated
link/id user, and a username/password user? That way someone could potentially
make a more "permanent/secure" account from the easy one. This might require
removing a generated account if someone logs into an existing account from a
new browser though.

~~~
s_kilk
Probably, at some point.

I'm pretty sure at some point we'll have features which are worth protecting
and at that time we'll need to offer an opt-in stronger method of account
security.

EDIT: for some reason I can't reply to FreezerburnV's comment below, so I'll
answer here: yes, I would be interested in talking further about this, drop me
an email (in my profile)

~~~
FreezerburnV
I don't see an email in your profile (by clicking on your username attached to
the post). I just see submissions/comments. I can send an email to the one
listed on the nightchamber about page, or you can check my profile where I
just added an email address that I can be reached at. I should have put a
contact email in my profile a while ago, my apologies for only having done so
now.

~~~
s_kilk
huh, that's odd, anyway, I can be reached at shane @ kilkelly.me :)

~~~
FreezerburnV
I sent an email to that address. It has the title "From FreezerburnV".
Hopefully it doesn't end up in a spam folder or something.

------
tasty_freeze
That little aside about "log in" vs "login" irritates me because there is a
correct answer. "login" is a noun, while "log in" is a verb phrase. They are
two separate things. The button to log a person into the system is a command
(a verb), thus it should be "Log In", not "Login".

~~~
palebluedot
While what you say is true, what matters more is the UI experience. Some
people will naturally conflate "login" and "log in", even if they shouldn't.

Also, there are other factors - fonts, monitor dpi, and other factors may make
it more difficult to discern between "login" and "log in" on a button, for
instance.

------
Frozenlock
> So, with Discourse, rather than all that, I decided we'd default on a solid
> absolute minimum password length of 8 characters

8 characters is way too much for someone just 'poking around'. Sure, 6
characters is much less secure, but then again how secure do you need to be
for a forum/commenting platform?

It's much better to let the user know his password is weak while letting him
take it anyway.

~~~
elboru
Exactly my point, I hate to be restricted with my passwords for meaningless
websites.

"Sorry, but your password must contain an uppercase letter, a number, a haiku,
a gang sign, a hieroglyph, and the blood of a virgin." (old joke)

But why? Your website is not important, do you know?

And if your website is that important (maybe it involves paid subscriptions or
something). Then freakin' remind me of those restrictions when I'm trying to
log in, so I don't have to think about all the character combinations I might
have tried when signing up for your website.

~~~
harshreality
Why does it matter how unimportant the site is? When you pick a password,
either you pick something simple and totally insecure (password, 3jane, god),
something not so weak but still easily crackable ("kLY8rT"), or you use a
password manager.

The "not so weak but still crackable" intermediate level doesn't make sense.
It's probably going to be reused (how many different 6-character random
passwords are you going to remember), so it's just as easy to make it 8 or 12
characters to make it harder to crack when one of the sites inevitably has
their password database stolen. If they're not hashing, of course, you're
screwed no matter how long the password is.

If you're going to allow 6 character passwords, that indicates there's
basically no cost to user account compromise, so why should there be any
password testing at all? If a user wants to use the password "1" and gets
hacked, that's their problem, they can create a new account after all. It also
indicates that user's contributions to the site are probably of low value,
since they don't expect to gain any social capital from their contributions
that are worth protecting with a better password. If they think the post(s)
have value but are going to abandon the account, they can just as easily use
"1password" as their password instead of "123123".

It seems like an 8 character minimum and checking against a wordlist is a
small price to pay for preventing naive internet users (there are a lot of
them) from using horrible, not just bad, passwords.

~~~
mod
> When you pick a password, either you pick something simple and totally
> insecure (password, 3jane, god), something not so weak but still easily
> crackable ("kLY8rT"), or you use a password manager.

No I don't.

------
shalmanese
I wish, also that a login page would tell me if I entered in a password that
doesn't meet their password requirements and then show me what those
requirements are again. Often, when I get the password wrong, I have to go to
the signup page to see what random password requirements this site requires so
I can remember what password I made up for it.

------
HCIdivision17
Do we even need a sign-up dialog? Couldn't we just log in, and if it doesn't
exist yet, tell the user to verify via the incoming email?

I'll grant that there's likely some stuff that some sites want to do on first
visit, and that if some do it, users will eventually expect all to be like it.
And perhaps that's why we have two dialogs now. But is there any security/pain
point related to it? (Assume there's some small snippet of text that makes it
clear what's going on, I guess.)

~~~
Lan
I can see this causing some issues with users that have multiple email
addresses. It may cause panic if they log in, see that it is successful, but
do not see any of their normal account data. They may assume that their
account has been deleted or their data lost.

~~~
oddevan
Similarly, I've lost count of how many times I've hit "log in with Facebook"
and accidentally created a new account.

------
derekp7
The problem I have with using email for login, is I often don't know which
email address I used to sign up for the given service. There is my Google
Gmail address, my work email, and the primary one I use for my personal
domain. On top of that, I use wildcard forwarding on my personal domain, so
anything@example.com gets to me@example.com. The only way I can tell which ID
i used when I signed up is to go through my email archive and try to find
something from that site.

~~~
mseebach
How is remembering an arbitrary string (your user ID) different from
remembering [arbitrary string]@yourdomain.com ?

~~~
mercer
because the former is just an arbitrary string that you might be using in many
places, and the latter is an arbitrary string PLUS a domain for one of your
potentially many email addresses. Sure you see the difference...?

~~~
derekp7
yes, that is my situation -- I'm more protective of email addresses than I am
of login ID's. I happen to be derekp7 almost everywhere.

------
alexggordon
> ...and verify the password to make sure it is not one of the 10,000 most
> common known passwords by checking its hash

Am I missing something here? 1\. I navigate to discourse 2\. Select "try
discourse" 3\. "Sign Up"[0] 4\. Dummy username/email 5\. Password: 12345678
6\. Wait, it succeeded? What did I just read?

Have they not implemented this yet? Maybe I'm the first person to test it?
Definitely a common password[1]

[0] [http://try.discourse.org/](http://try.discourse.org/) [1]
[http://www.cbsnews.com/news/the-25-most-common-passwords-
of-...](http://www.cbsnews.com/news/the-25-most-common-passwords-of-2013/)

~~~
dspillett
> > ...and verify the password to make sure it is not one of the 10,000 most
> common known passwords by checking its hash

That bit confuses me - why the need to check the hash? You have the password
plain and you have the list plain, just compare the strings directly.

If you have a hashed version of the list and are comparing hashed passwords to
that, then you are hashing your passwords wrong: the parameters to your salt
function should vary per-password so that people using the same password as
each other (or someone using the same password for many accounts) are not
obvious should your credentials store be compromised.

~~~
alexggordon
Exactly. I don't know why you need to check the hash, not to mention it
doesn't seem to be working at all.

If you're just checking to see if it's a common password, wouldn't it be
easier to just store a dictionary?

------
d23
> I think a nice middle ground is to insert standard pauses of moderately
> increasing size after repeated sequential failures or repeated sequential
> forgot password requests from the same IP address. So that's what we do.

I like this. Captchas annoy the end-user and have been completely broken by
foreign manual typers with an API (e.g.
[http://humancoder.com/](http://humancoder.com/)). It seems to me pauses would
solve the issue, at least an IP level, without any inconvenience to the end-
user.

------
peterwwillis
The 'email does not exist' decision they make here is debunked for one single
reason: risk assessment. Is there a risk associated with implementing this use
case that outweighs not implementing this use case? Here the use case is 'tell
someone if their email is [not] registered', and the risk is 'identifying
existing user accounts at login time'. So let's see which is appropriate.

In the best case, implementing this feature lets a user know which of their
e-mail addresses are registered on your site, giving them an easier log-in. In
the worst case, an attacker can immediately identify what users have accounts
on this site, exposing the users to a violation of privacy.

Some counter that site registration will always provide this information when
attempting to register an existing e-mail address. But this is easily
mitigated: a captcha as well as holding off verification until the last step
of registration puts the brakes on the attacker, making it more difficult to
scan through potential accounts. By slowing down their attack methods you're
helping to reduce risk.

And finally, do we really need to tell the user what e-mail they used? I'll
wager that the great majority of users enable browser form-filling, and so
their e-mail is sitting right there in the login box waiting for a password.
And i'd also wager that most users with multiple e-mails will be cognizant of
which they use for an account on a site like yours. So to avoid the few times
a user doesn't save form fields and can't remember which e-mail they use for
sites like yours, bad people get an easier way to do bad things.

For these reasons I think it's clear that the minor inconvenience in a very
small number of cases is worth it to help slow down privacy violation en-
masse.

\---

Nit-pick: why would God call the field 'User' if they really meant 'Email'?

------
gadders
Maybe out of scope of the article, but for the section on rate-limiting he
could maybe mention tptacek (and others') advice and recommend using bcrypt.

[http://codahale.com/how-to-safely-store-a-password/](http://codahale.com/how-
to-safely-store-a-password/)

------
TheLoneWolfling
> Oops, the user entered their email as [email protected] instead of [email
> protected]? Or [email protected] instead of [email protected]?

...

> when presented with a login dialog, like to rapidly type

> [email protected], tab, p4$$w0rd, enter

...

So... Tell me. Considering that you don't block people finding out email
addresses on Discourse in the interests of user-friendliness, why on earth are
you blocking email addresses, and ones for the purpose of examples at that? An
interesting juxtaposition there, and rather ironic, to put it mildly.

Also:

> I think a nice middle ground is to insert standard pauses of moderately
> increasing size after repeated sequential failures or repeated sequential
> forgot password requests from the same IP address. So that's what we do.

So what about NATs? There are countries with one public IP address.

------
gambiting
I was actually surprised by how Snapchat handles it. When I tried creating an
account, it told me my login is already taken(something that is super weird,
since I have never found anyone else using it), so I assumed I already must
have an account. I clicked on "forgot your password" , entered my email, and
in fact - I have received a "password reset" email. Clicked on the link, typed
in new password.....but then when I tried logging in it told me this account
doesn't exist. So it allowed me to reset a password for an account that never
existed - and that struck me as really interesting.

~~~
untilHellbanned
What is "interesting"? Does this mean they have a crap login workflow? Or are
you suggesting they are doing something intentional?

~~~
gambiting
Yeah, I am sure they are sending the "password reset" email out intentionally
even though they fully know this account doesn't exist, so an attacker wastes
resetting a password for it.

------
blergh123
"Your best course of action is not to build a login dialog at all, but instead
rely on authentication from an outside source whenever you can."

What do people use as their outside source for authentication?

~~~
ProAm
OpenID I presume, or something similar?

~~~
oddevan
Probably something Oauth-like, say Facebook, Twitter, GitHub, tumblr., Google,
Yahoo...

------
ap22213
Email is such a terrible way to associate identity. And, I think the industry
is really misguided in not taking on the challenge of standardizing identity
in a way that's not tied to email (or phone, or phone number, more recently).
Sure, it's the quick way, the path of least resistance, but there are so many
issues with email as identity, and it's really frustrating to me, as a user.

~~~
sp332
Like what? Email gives you a name and a domain, which gives you the ability to
pick your name and your namespace. It's a pretty good system. In fact, I work
for an ISP that will let you pick an email-looking identifier to log into HBO
Go etc. even if we don't actually host your email.

~~~
ap22213
Over the years, I've had to accumulate many different email addresses. I have
all of my work addresses, and then I have all the multiples of gmail, hotmail,
live mail, yahoo mail, icloud, etc. Each of these addresses is associated with
different web accounts, and I can't consolidate or even associate different
addresses to different accounts. Worse, I can't migrate to a new email
provider (say, my own) without lots of work.

Now, I have new 'identities', too - facebook, twitter, linkedin, my phone,
etc.

To me, it's a mess, but maybe I'm in the minority.

~~~
sp332
It's definitely a mess, I just can't think of anything better.

------
gatehouse
On letting the user switch between register and login at any time, there is
one small thing that tumblr does that I like.

If you go to tumblr.com it displays the registration page with
email/password/username. If you just type in email+password on this page, it
still works. So an incomplete registration form can be used to login.

------
theanirudh
I think email+password is still too confusing for "normal" people. Phone
number + OTP is becoming very popular in apps, especially in developing
countries where a lot of people don't even have/know what email is. I think
this was mentioned in a recent a16z podcast as well.

~~~
Kurtz79
I would never put my phone number anywhere near a login screen.

At least my email has a spam filter.

------
aerialcombat
It's funny how many people choose to talk about something besides the point of
the story.

~~~
Dirlewanger
People always need to feel superior in some way (picking apart spelling
mistakes, ad hominems, etc.), and on the Internet, it's so low-cost to do so.
Doesn't matter how "civil" the community may seem.

------
MarkMc
I suspect that many users when told their password is too common simply add a
"1" or "123" suffix. Such behaviour would significantly weaken this method of
using the top 10,000 password list as a filter.

------
tempodox
As I see it, this problem will only be solved satisfactorily once we have
technology (and security) to do away with frigging passwords completely. As
the Internet plays a role in ever more aspects of society and industry, we
need a concept of identity there that is usable by absolutely _everyone_
without any mental effort.

Until then, this post gives advice worth heeding.

~~~
TeMPOraL
The problem is, this goes totally against the idea of Internet privacy. I
think it's either-or case. If you want to solve passwords, you'll have to drop
any dream of anonymity.

------
Exuma
I've never seen the Randy Pausch video before, that was amazing.

------
cheshire137
Site seems to be down.

------
benihana
Offtopic but:

>that users could accept __an __URL as their "identity"

Does this imply Jeff Atwood pronounces URL as earl?

~~~
jpitz
That or he isn't aware of the subtle exception to the a vs an rule regarding
leading 'y' u-sounds.

------
minikites
> The beauty of a minor was that I could cherry pick all the cool CS classes
> and skip everything else.

This explains a lot about the quality of his code.

