The God Login

8/9/2019 The God Login

1/35
http://feedburner.google.com/fb/a/mailverify?uri=codinghorror&loc=en_UShttp://feeds.feedburner.com/codinghorrorhttp://www.cs.cmu.edu/~pausch/Randy/Randy/Vita.htmlhttp://www.discourse.org/https://profiles.google.com/codinghorror1http://my.statcounter.com/project/standard/stats.php?project_id=2600027&guest=1http://blog.codinghorror.com/http://twitter.com/codinghorrorhttp://blog.codinghorror.com/http://stackexchange.com/http://blog.codinghorror.com/recommended-reading-for-developers/http://en.wikipedia.org/wiki/The_Last_Lecturehttp://ghost.org/http://blog.codinghorror.com/about-me/


2/35
http://bigocheatsheet.com/http://blog.codinghorror.com/everything-is-fast-for-small-n/


3/35


http://blog.codinghorror.com/the-god-login/ 3/35

This kind of blew my mind at the time.

I always suspected that programmers became

programmers because they got to play Godwith the

little universe boxes on their desks. Randy Pausch

took that conceit and turned it into a really useful

way of setting boundaries and asking yourself hardquestions about what you're doing and why.

So when we set out to build a login dialog for

Discourse, I went back to what I learned in my

Algorithms class and asked myself:

How would God build this login dialog?

And the answer is, of course, God wouldn't bother

to build a login dialog at all.Every user would

already be logged into GodApp the second they

loaded the page because God knows who they are.

Authoritatively, even.

This is obviously impossible for us, because God isn't

one of our investors.
http://www.discourse.org/http://blog.codinghorror.com/bridges-software-engineering-and-god/


4/35



But.. how close can we getto the perfect godlike login

experience in Discourse? That's a noble and worthy

goal.

Wasn't it Bill Gates who once askedwhy the hell

every programmer was writing the same File Open

dialogs over and over? It sure feels that way for login

dialogs. I've been saying for a long time that the best

login is no login at alland I'm a staunch supporter of

logging in with your Internet Driver's license

whenever possible. So we absolutely support that, if

you've configured it.

But today I want to focus on the core, basic loginexperience: user and password.That's the default

until you configure up the other methods of login.

A login form with two fields, two buttons, and a link

on it seems simple, right? Bog standard. It is, until

you consider all the ways the simple act of logging in

with those two fields can go wrong for the user. Let'sthink.
http://blog.codinghorror.com/cutting-the-gordian-knot-of-web-identity/https://www.commandprompt.com/community/pyqt/x3581http://blog.codinghorror.com/your-internet-drivers-license/


5/35



Let the user enter an emailto log in

The critical fault of OpenID, as much as I liked itas an

early login solution, was its assumption that userscould accept an URL as their "identity". This is flat out

crazy, and in the long run this central flawed

assumption in OpenID broke it as a future standard.

User identity is always email, plain and simple.

What happens when you forget your password? You

get an email, right? Thus, email is your identity. Somepeople even propose using email as the only login

method.

It's fine to have a username, of course, but alwayslet

users log in with either their username or their email

address. Because I can tell you with 100% certainty

that when those users forget their password, and

they will, all the time, they'll need that email anywayto get a password reset. Email and password are

strongly related concepts and they belong together.

Always!

(And a fie upon services that don't allow me to use

my email as a username or login. I'm looking at you,

Comixology.)

Tell the user when their
http://notes.xoxco.com/post/27999787765/is-it-time-for-password-less-loginhttp://blog.codinghorror.com/openid-does-the-world-really-need-yet-another-username-and-password/


6/35



email doesn't exist

OK, so we know that email is de-facto identity for

most people, and this is a logical and necessary state

of affairs. But whichof my 10 email addresses did Iuse to log into your site?

This was the source of a long discussion at Discourse

about whether it made sense to reveal to the user,

when they enter an email address in the "forgot

password" form, whether we have that email address

on file. On many websites, here's the sort of messageyou'll see after entering an email address in the

forgot password form:

If an account matches [email protected], you

should receive an email with instructions on how

to reset your password shortly.

Note the coy "if" there, which is a hedge against all

the security implications of revealing whether a given

email address exists on the sitejust by typing it into

the forgot password form.

We're deadly serious about picking safe defaults for

Discourse, so out of the box you won't get exploited

or abused or overrun with spammers. But after

experiencing the real world "which email did we use

here again?" login state on dozens of Discourse

instances ourselves, we realized that, in this specific

case, being user friendly is waymore important than

being secure.
https://meta.discourse.org/t/different-password-reset-for-wrong-username-email/15909http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html


7/35



The new default is to let people know when they've

entered an email we don't recognize in the forgot

password form. This will save their sanity, and yours.

You can turn on the extra security of being coy about

this, if you need it, via a site setting.

Let the user switch between

Log In and Sign Up any timeMany websites have started to show login and signup

buttons side by side. This perplexed me; aren't the

acts of logging in and signing up very different

things?

Well, from the user's perspective, they don't appear

to be. This Verge login dialog illustrates just how

close the sign up and log in forms really are. Check

out this animated GIF of it in action.


8/35



We've acknowledged that similarity by having either

form accessible at any time from the two buttons at

the bottom of the form, as a toggle:

And both can be kicked off directly from any page via

the Sign Up and Log In buttons at the top right:


9/35



Pick common words

That's the problem with language, we have so many

wordsfor these concepts:

Sign In

Log In

Sign Up

Register

Join

Create Account

Get Started

Subscribe

Which are the "right" ones? User research data isn't

conclusive.

I tend to favor the shorter versions when possible,

mostly because I'm a fan of the whole brevity thing,

but there are valid cases to be madefor each

depending on the circumstances and userpreferences.
http://uxmovement.com/buttons/why-sign-up-and-sign-in-button-labels-confuse-users/http://ux.stackexchange.com/questions/1080/using-sign-in-vs-using-log-in


10/35



Sign In may be slightly more common, though Log In

has some nautical and historical computing basis

that makes it worthy:

A couple of years ago I did a survey of top

websites in the US and UK and whether theyused sign in, log in, login, log on, or some

other variant. The answer at the time seemed to

be that if you combined log in and login, it

exceeded sign in, but not by much. Ive also

noticed that the trend toward sign in is

increasing, especially with the most popular

services. Facebook seems to be a log in hold-

out.

Work with browser

password managers

Every login dialog you create should be tested to

work with the default password managers in

Internet Explorer

ChromeFirefox

Safari
https://support.mozilla.org/en-US/kb/password-manager-remember-delete-change-passwordshttps://support.google.com/chrome/answer/95606?hl=enhttp://windows.microsoft.com/en-us/internet-explorer/fill-in-forms-remember-passwords-autocomplete#ie=ie-11http://www.designcult.org/2011/08/why-do-we-call-in-logging-in.htmlhttp://support.apple.com/en-us/HT204085


11/35



At an absolute minimum. Upon subsequent logins in

that browser, you should see the username and

password automatically autofilled.

Users rely on these default password managers built

into the browsers they use, and any proper modern

login form should respect that, and be designed

sensibly, e.g. the password field should havetype="password" in the HTML and a name that's

readily identifable as a password entry field.

There's also LastPassand so forth, but I generally

assume if the login dialog works with the built in

browser password managers, it will work with third

party utilities, too.

Handle common usermistakes

Oops, the user is typing their password with caps

lock on? You should let them know about that.
https://lastpass.com/


12/35



Oops, the user entered their email as

[email protected] instead of [email protected]? [email protected] instead of [email protected]?

You should either fix typos in common email

domains for them, or let them know about that.

(I'm also a big fan of native browser "reveal

password" supportfor the password field, so the

user can verify that she typed in or autofilled the

password she expects. Only Internet Explorer and I

thinkSafari offer this, but all browsers should.)

Help users choose betterpasswords

There are many schools of thought on forcing

helping users choose passwords that aren't

unspeakably awful, e.g. password123 and iloveyou

and so on.

There's the common password strength meter, which

updates in real time as you type in the password

field.
http://answers.microsoft.com/en-us/ie/wiki/ie11-iewindows8_1/the-use-of-the-password-reveal-eye-button-in/19a9dee2-fb0c-4c26-a6bc-ac02cf98d80ehttp://blog.codinghorror.com/dictionary-attacks-101/


13/35



It's clever idea, but it gets awful preachy for my tastes

on some sites. The implementation also leaves a lot

to be desired, as it's left up to the whims of the site

owner to decide what password strength means. One

site's "good" is another site's "get outta here with

that Fisher-Price toy password". It's frustrating.

So, with Discourse, rather than all that, I decided we'd

default on a solid absolute minimum password

length of 8 characters, and then verify the password

to make sure it is not one of the 10,000 most

common known passwordsby checking its hash.
http://thepasswordproject.com/


14/35



Don't forget the keyboard

I feel like keyboard users are a dying breed at this

point, but for those of us that, when presented with a

login dialog, like to rapidly type

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

pleaseverify that this works as it should. Tab

order, enter to submit, etcetera.

Rate limit all the things

You should be rate limiting everything users can do,

everywhere, and that's especially true of the login

dialog.

If someone forgets their password and makes 3

attempts to log in, or issues 3 forgot password

requests, that's probably OK. But if someone makes

a thousand attempts to log in, or issues a thousand
http://blog.codinghorror.com/rate-limiting-and-velocity-checking/


15/35



forgot password requests, that's a little weird. Why, I

might even venture to guess they're possibly not

human.

You can do fancy stuff like temporarily disable

accounts or start showing a CAPTCHA if there are too

many failed login attempts, but this can easily

become a griefing vector, so be careful.

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.

Stu I forgot

I tried to remember everything we went through

when we were building our ideal login dialog for

Discourse, but I'm sure I forgot something, or could

have been more thorough. Remember, Discourse is

100% open sourceand by definition a work in

progress so as my friend Miguel de Icazalikes to

say, when it breaks, you get to keep both halves. Feel

free to test out our implementation and give us your

feedback in the comments, or point to other

examples of great login experiences, or cite other

helpful advice.

Logging in involves a simple form with two fields, a

link, and two buttons. And yet, after reading all this,
http://tirania.org/blog/https://github.com/discourse/discourse


16/35



Continue Discussion79 replies9 Jan

MadOverlord

One subtle tweak... the Sign In and New Account buttonsshould have some space between them, to reduce the chance ofa misclick. And the "expected" action should be the onedirectly below the name/password fields.

9 Jan

kram1032

I find it kind of weird that the "Login" button looks different indifferent places:Once, it's an open lock, and once a person. Is there any

particular reason for that?

9 Jan

I'm sure you'll agree that it's deceptively complex.

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.

Like, say, God.

Written by Je Atwood

Indoor enthusiast. Co-founder of Stack Exchange and

Discourse. Disclaimer: I have no idea what I'm talking

about. Find me here: http://twitter.com/codinghorror
http://twitter.com/codinghorror


17/35



All very good points, and it leads to a discussion aboutpasswords in general. Pet hate of mine is websites that don'tallow anything other than alphanumeric characters, to my mindthe site itself is not secure when they won't let me use ! in themiddle of my password string.

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

And in a site I run I often get people trying to be reunited withaccounts where they have no matching information, yet they

claim that they are the owner but they used false info forprivacy 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 notgiving you this old account! I'm setting up a page of securityquestions to hopefully tackle that in the future.

9 Jan

marioawad

I you don't respect the {USERNAME}{TAB}{PASSWORD}{ENTER} sequence on your login form, me and my friendKeePass will be constantly looking for another alternativewebsite. That and also making sure the title of your login pageincludes your website's name and not only a generic "Log In"title.

1 reply9 Jan

pnuk

codinghorror:

Thus, email is your identity.

Unless it's your mobile phone number: Chinese Mobile App UITrends

1 reply


18/35



9 Janmarioawad

Pommes

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 reply9 Jan

Papuass_

A bit offtopic, but this has to be cutest login form from all. Tryentering password:https://dash.readme.io/login

1 reply

9 JanPommes

marioawad

This is awesome. Thank you. I'll keep those in mind for thefuture 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

9 Jan

DenisSokolov

Consider not giving the user a big and scar warning about capslock, but instead check his password against a case-invertedversion of itself.

2 replies9 Jan


19/35



stefan19

Have you thought about supporting SQRLin the future? Loginwithout username, password or email. Very close to the waygod would have designed it.

1 reply

9 JanDenisSokolov

erikheemskerk

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 maynot use it consistently. When they didn't use it when signing upor changing their password but they are using it now, you will

get a mismatch and you'll be punishing them for not beingconsistent. That would be bad form.

1 reply9 Jan

jaginsberg

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

9 Jan

jgustie

Another one that drives me nuts is the auto-caps of the firstletter in a text input applied by Mobile Safari: giving the

browser an indication that the field is an email or username is amust.

1 reply9 Jan


20/35



frank9

Ok, I guess I am Frank9 here. yuck...Anyways...I liked thispost Jeff. I am going to refer to this when I revise my loginsystem to my CMS tool. I am dealing with an incrementalrewrite with a designer in a few weeks and it definitely shortcircuits whats important and what is better than acceptable (I

usually don't have the luxury to think about this stuff the wayyou guys did). So you taught me something useful today...Ican't wait to see what else is up your sleeves on future projects.I have come to the conclusion that you and Sam and theTroutfish, make the internet a better place. Optimal Tip to TipEfficiencies here. (second to last sentence is a honest sentimentand the wording came out funny, and the last one...well you getthe joke(segway)

9 Janerikheemskerk

DenisSokolov

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

convenience.

9 Jan

sa12

First time trying Discourse. Looks nice..

9 Jan

digplan

Regarding your email is your identity.. I think, you're identityis your identity. Email Twitter Facebook these are bestconsidered - not identities but means of verifying your identity.

So your "identitly record" in a system is related to each ofthose, but not one of those defines it. For a long time I thoughtusing email address as your de-facto identifier as a login namemade good sense.

'


21/35



,extent email is becoming much less relevant to the youngergeneration. They will inevitably have all of Twitter, Tumbler,Email address, and mobile phone number, but keying in on oneas the God "identifier" if you will feels a little off.

The box with login w/Twitter, Facebook, etc.. seems the rightsolution for the present, but still feels not quite right, at leastnot totally elegant. A universal standard for internetidentification of course would consolidate and simplify things,

but not just the adoption by so many providers, but theconcerns about privacy and tracking etc.. would seem difficultto even get off the ground.

9 Jan

gmanjapan

One thing that's always bugged me is forms, like the Discourseone, 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 theother.

In other words, I see both "log in" and "create new account" atthe bottom. I type my username and password and click "createnew account" expecting it to create a new account with the

name and password I just typed. Instead it saysHaha for typingyour name/pass and clicking "create new account". Instead I'mgoing to discard what you just typed and make you type itagain because that misleading button actually leads to adifferent form. F.U!

WHY!!!!

First you mislead me by putting 2 buttons that look like actionsbut one is not the action it claims it is. It's not going to "create anew account" it's going to "switch to the create new account

form".

Second you waste time type and throw away my work. This isespecially infuriating if I happened to enter that on mobilewhere typing is super tedious, especially if my passwordfollows 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 extrafields 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.

2 replies9 Jan


22/35



Bob_Wise

codinghorror:

If an account matches [email protected], youshould receive an email with instructions on howto reset your password shortly.

Note the coy "if" there, which is a hedge againstall the security implications of revealing whether agiven email address exists on the site just bytyping it into the forgot password form.

Malicious humans or bots can already figure out if an emailaddress or username exists in the system by trying to make a

new account with that email address or username. I don't thinkthere is any advantage to trying to hide that information here.

1 reply

9 JanDenisSokolov

adregan

Perhaps, but this wouldn't be very helpful for a mixed casepassword (eg. for me, capslock + shift doesn't producelowercase text).

9 Jan

MT83

"I put on my robe and wizard hat."

1 reply9 Jan

ambiguator

OK, Jeff, how's this for instant feedback? (I registered just so Icould submit this comment):

Easily switching between "login" and "register" is great.


23/35



But why did you delete my input? I had already typedmy email address and password, thinking the "create newaccount" javascript trigger was a submit button. Now I'mfrustrated that I had to retype it.When I click the "confirm" link from email, please sendme back to the thing I was trying to do. Now I have 3codinghorror tabs open (three!) plus my email. Just so Icould post one comment.

9 Janpnuk

JonCoder

That may sound great in theory, and maybe it's great for theChinese market, but to that I have this that came to mind:

In the 10 years I've held the same email address, I've changedmobile numbers at least 4-5 times.And mobile numbers get recycled. I've gotten many phonecalls directed at the previous owner of a phone number Irecently acquired.I would never consider using a mobile phone number asidentity due to how volatile they can be, at least in the westernworld.

9 Jan

speising

i actually object to "email as username". i hate it when sitesrequire that, because it limits your options massively. and ifsomeone hacks the user database of one site, they knowyourusername, and possibly your password, on a lot of other sites.

even without that, if they know your email (and we know a lotof spammers do) they can try it at those sites.regarding recoverymails: an email address is not the same as anemail account! you need access to the latter to use the recoverymail feature.

9 Jan

reavy

An important feature to include is when logging into a website,there should either be a statement about the password policy or

-


24/35



password requirements.

Sometimes when I'm in a rush to register on a site, I'll use aquick variation of a common inexpensive password I keep inmy head, and I'll modify it to fit the password policy that site isenforcing. I'll then neglect to make a note of that registration inmy password manager (if I were going to use the passwordmanager, I suppose I'd have it generate my password anyway).When returning to the site later, having forgotten myregistration, I'll try one that makes sense based on what I wouldhave done for that site, but I'll get incorrect password errors.

It would be really nice, even if only after a first failed passwordattempt, for the site to tell me, "Hey, your password is wrong.It should be 8-40 alphanumeric characters, no hyphens or anyother silliness." So that I'm not trying otherwise strong

passwords that don't make any sense for that site.

Furthermore, when a site states a password policy whileregistering, it should darn well enforce the policy it states. Itfrustrating when it says certain characters are (dis)allowed andthen proceeds to enforce some other hidden policy.

Edit: P.S. Also, please please don't truncate my password andthen not tell me about it! It's ever so much fun when my

password is shortened at registration by the form's characterlimit and then a different (longer) limit is encountered on thelog in page and suddenly I don't have the correct password

anymore

2 replies9 Jan

cavedog123

If using the email address as username, be sure to include away to change that email address. My Steam account still

forces me to use my @yahoo.com address. At least a fewyears ago they allowed you to change your real address whereemail goes to.

1 reply

9 JanBob_Wise

Balfa

There's nothing to stop the "create new account" screen from '


25/35



,then instead of sending a "welcome to this site!" email, it willsend a "zomg, somebody might be phishing for your account -or maybe you just forgot you already had an account here"email. Only the owner of the email account will be aware ofthe state of the system, and the attacker is none the wiser eitherway.

1 reply

9 Jancavedog123

davidzych

Same thing for me, except a @hotmailaddress.

9 Jan

jon49

If the e-mail matches an e-mail in the database then why offerthe registeroption at all? If the e-mail doesn't match then whyoffer the sign inoption? If you are storing the sessionanyways you can get the ID once you know the e-mail iscorrect and then it will be really quick to test the password.You could show both sign-in/register at first, but as soon as thee-mail/username is filled in, there is no reason to show one orthe other. That way, if the user put in the wrong e-mail theyhave immediate feed back.

9 Jan

louiseroho

As a Web Developer, I thought about this issue and realizedthat cannot be a "One Login Method to Rule Then All" becauseif that login method gets hacked for one type of site, then everysite that uses that specific tool is also hacked. So, every securesite must integrate with others, but still needs to have its ownspecific spore on the security.

9 Jan

e rl en d s h


26/35



_

I find it a bit amusing that you show this:

And this:

... so close together. Any particular reason why Discourse's"Sign Up" has not been renamed to "Register"?

1 reply9 Jan

codinghorror

I downloaded my UVa transcript online to confirm, and indeed:

Pasted image1024x151 25.3 KB

Definitely the Pausch class, the timing and class title is

consistent with his CV. I got a B!

And then check out the excitement of my last semester...


27/35



Pasted image911x311 55.1 KB

1 reply9 Jan

timbojones

You should either fix typos in common email

domains for them

No don't do this! What happens when actual [email protected] to register? It is impossible because the site 'corrects' theaddress.

or let them know about that.

Prompting "Did you mean [email protected]?" is a fineapproach.

9 Jan


28/35



Spot on. Except I don't like the 8 character passwordrequirement for non-financial sites.

9 Jan

zstewart

There's a critical corollary to the principle of using email asidentity - you need to confirm it before treating the account as afull user of the site! Or you get this.

9 Jangmanjapan

Kendall1

This is my biggest pet peeve also. Whatever they user has goneto the trouble to type in, remember it. Not just the username but

password too please!

9 Jan

Kendall1

One of the things I'm considering doing for a new project foriOS is in fact the zero form login. You can save a customUUID you generate into iCloud storage for an app and use thatas a login ID and/or password (to send to a server), until suchtime as the user choses to give you more information to log in

with. A user doesn't even know if they WANT to use yourservice/app yet, but so many systems throw the login wall upright away... it has to be dropping out many users. Let themslowly lock down their account as it grows in importance tothem.

Another thing to consider is password strength requirements -think about who you are. If you are not a bank, if I cannotspend money through your system why do you have ANYREQUIREMENTS around your password at all? Let people

use a stupid password they will remember, and then reallycrank up that afore-mentioned rate limiting to make guessingmore than three times impractical. No it is NOT OK to requirethey use 1Password and the like.

1 re l


29/35



9 Jan

Harry_Johnston

Troy Hunt (in Introducing the Secure Account ManagementFundamentals course) recommends advising the user that theydon't have an account at that email address by emailrather thanon the web site. That avoids the information exposure I canimagine there are people who don't want it known that they areregistered with a particular site. (Even a site like StackOverflow, because some bosses seem to really hate the ideathat their employees might be helping "the enemy" whether it'son their own time or not.)

If you've got a lot of email addresses, this wouldbe less

convenient than the direct method. I'm not sure whether that'senough of a problem to enough people to justify allowing theinformation exposure.

Of course you then need anti-automation defenses to avoidspamming the innocent. That might well tip the balance.

9 Jan

johnlbevan

With regards to email also ensure that users can registermultiple email addresses against a single account that waythey don't need to recall which mail they used all work thesame way. Have a primary mail address for any notificationsfrom the site (i.e. separate to login concerns), or better yet,allow the user to add conditions around mail use (this is my

primary mail for useful notifications, this is my mail for

newsletters / stuff I may read if bored).

10 Jan

michelle_o

Please be aware that keyboard use is not just for power users or

password managers. Keyboard navigation is essential forscreen readers and is step 1 of testing your site for accessibility.

10 Janjgustie


30/35



scunliffe1

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

10 Jan

karissamck

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

2 replies

10 Janstefan19

matthew_ickstadt

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

10 Jan

msummerfield

Given the choices you have already made, your login dialogcould be further simplified to just two fields and one"Login/Register" button. If there is no email address matchingthe user input, you can then askif they would like to create anew account. If the password does not match, you can askifthey have forgotten their password, and would like a resetemail sent.

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

This would particularly suit me. If I want high security for asite (that does not provide two factor authentication), I often

just use a really long random string as a password, that even Ido not know, and then use the reset email as my primary wayto access the account settin a new lon , random assword on


31/35



my way back in). Always having exactly the same dialogwould be my God login!

1 reply10 Jan

Leo_Nel

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

10 JanBalfa

Hamled

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 accountcan actually be used.

This in itself is a major source of lost users, and the reason why

many organizations have made email confirmation optional intheir sign up funnel.

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

10 Jan

Hamled

Forgive me if this has already been covered, but I think theidea 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 wastedattempts per hash wasn't that much, but it turns out that even in2015 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 20minutes per hash (assuming they have to use CPUs) onto thecracking time if you're using a bcrypt factor of 10 or scrypt


32/35



.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'tnormally use. A password they're likely to forget. If they even

bother continuing to sign up after some stupid website toldthem their password was dumb. And it's not like the acceptable

password they choose is going to be massively better, it'llprobably still be in the top 100,000 or million passwordsguessed by a competent cracking program.

Philosophically, I think it's my responsibility to assume thatevery single one of my users is so unconcerned about securitythat they really will make their password 'password' (orwhatever minimum additions to that are required to fit mystated requirements). The best I can do is pick password-relatedtechnologies and designs that protect them as much as possiblein the event of a breach.

The user's responsibility, OTOH, is to assume that I'm sounconcerned with their security that I'll store their passwords in

plaintext. In that case they'd use a password manager, or insistupon a stronger technology like PAKE and/or two-factor auth.Sadly not enough users assume this, but we also can't makethem.

10 JanMT83

dave_steinberg

I literally rushedto add this comment, in the hope, howevervain, that it would be the first. Alas...

10 Jan

saurabhguptatwt

I like the game. If we extend this outside the www domain.Cop stops you and asks for your driving license. What will aGOD require? He wouldn't stop you, just write you a ticket and

withdraw fine from your bank account. Sounds freakish!

11 Jan

andrekibbe


33/35



Kendall1:

If you are not a bank, if I cannot spend moneythrough your system why do you have ANYREQUIREMENTS around your password at all?

Because the same login credentials are likely to be used onbanks and other sensitive sites visited by the user. Since mostpeople stick with passwords that are easy to remember, they'reprobably using them everywhere, so their security profile is achain as strong as its weakest link. A hacker who's obtainedhundreds of user logins is guaranteed to have at least a fewdozen of those that are valid for BofA.com, PlayStation.com,etc.

1 reply11 Jan

andrekibbe

gmanjapan:

It seems like copying the name/pass from one formto the other (or making them the same form and

hide/un-hide the extra fields for registering) wouldbe more respectful of the user's time and slightlymitigate the fib that "create new account" doesn'tactually create a new account.

With most registration tools only the encrypted version of thepassword is stored it's hashed before being saved to thedatabase. So there's no server-side access to the unencrypted

password to populate the form with it. That's the same reasonwhy most "Forgot your password?" links require a passwordreset, regardless of how annoying it is to the user.

Of course, forms could probably do some client-side validationand simply rejectinvalid submissions up front so that the

password remains in the field.

11 Janerlend_sh

andrekibbe

I disagree with the rather pedantic arguments in the left columnimplying that "Sign Up" and "Sign In" are indistinguishable.On the contrary, they're visually and grammatically consistent,


34/35



and since they're different buttons in the same region, users caneasily parse that they're distinctly different options. This iswhat Tufte calls the Least Effective Difference. You don't needto accentuate the difference further by varying the wording orstyle. I personally find those superfluous differencesaesthetically incoherent without offering any additionalusability advantages in return.

11 Janreavy

roelandsch

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

I don't get why web sites need those limitations in the firstplace. I mean, they should just do SHA2(saltySalt + "correcthorse battery staple") anyway.

I wonder what they're doing. Using their own basement-grownhash? Or maybe they're not sure which characters will causemysql_query("INSERT INTO my_users VALUES ('$user',

'$password')");to break.

1 reply12 Jan

t1oracle

Instead of telling users that they gave the wrong email addresson the site, why don't you just send an email to them at thataddress telling them of the error? That way hackers can't use

your form to expose user accounts. Within that email you canprovide a link to recover the forgetten email address usingsecurity questions.

12 Janroelandsch

t1oracle

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.


35/35

Documents

The God Login