
Don’t Get Clever with Login Forms - octosphere
http://bradfrost.com/blog/post/dont-get-clever-with-login-forms/
======
joshuaheard
Another rule: make all fields pastable. If you have a form I can't fill in
with my password manager, I can copy and paste my username and password with
my password manager. Unless... you make those fields so I can't paste into
them. Then, I have to open two windows side by side and manually type in my 16
digit password with caps, numbers, and symbols. Tedious.

~~~
da_chicken
I've never understood this desire to make a web site behave like it isn't a
web site. The entire benefit of web sites is that they've got a consistent
interface even between web sites. Don't break that! Don't break copy and
paste. Don't break the back button. Don't change or break the right
click/context menu. Don't hide the toolbars.

~~~
phs318u
> Don't break the back button.

Can someone please tell SAP?

~~~
brazzledazzle
Add it to the giant list of suck.

------
colinramsay
There's been a recent tendency to split login forms into username/password
over two screens as mentioned in this article. It's maddening. Password
managers can't deal with this, unsurprisingly. I don't see the benefit this
provides for anyone.

~~~
amaccuish
That is quite useful however with some federated auth flows, where you just
need the email to see where to send them for the actual auth (e.g. Office365
and SAML login), otherwise you'd needlessly be entering your password.

I also much prefer it to the previous way e.g. Office365 worked, where once
you'd tabbed away from the email box, they'd detect you needed to be
redirected and send you off, whilst most people had begun typing their
passwords.

~~~
tomc1985
Pretty sure that is why... you enter your username and it checks to see what
authentication flow to use, if it's a password flow then you get a password
screen.

Pisses me off too

~~~
jrwoodruff
Bingo. This is why we went with a stepped process. Did you log in with Google,
Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need
to create one?

It frustrated everyone.

Since we've implemented the stepped process (and made other changes)
complaints have all but disappeared, and the number of failed sign in attempts
has been significantly reduced, successful logins has increased slightly, and
overall login attempts dropped.

It's not perfect, but all indicators are it's better than a screen full of
options - it allows us to guide users to the correct action.

Sure, it can still be annoying, but less so than what it was.

~~~
StavrosK
Your comment confuses me, can you clarify?

> This is why we went with a stepped process. [..] It frustrated everyone.

But then:

> Since we've implemented the stepped process (and made other changes)
> complaints have all but disappeared

~~~
thisacctforreal
"[..]" was a list of all the problems that frustrated people before the
stepped process.

~~~
StavrosK
Oh, I see, thanks. The list sounded to me like a description of the stepped
process, so I was confused.

------
Al-Khwarizmi
Tip from a non-native English speaker: if you want your website to be more
friendly to an international audience, don't use the terms "sign in" and "sign
up", use more distinct terms (like "login" and "register") instead.

Phrasal verbs, in general, are difficult to speakers of languages that don't
have them, especially when the same verb has different meanings depending on
the added preposition. Someone with a basic/intermediate level of English may
have difficulty telling between "sign in" and "sign up". In my own case, I
have a good level of English so I know what they mean, but "sign in" and "sign
up" always take 2 or 3 seconds for me to disambiguate, while "login" and
"register" (or similar) are instantaneuous.

~~~
dsego
Afaik, you "sign up" for something, like a newsletter, or health insurance.
You sign into a hotel, ie leave your signature at the check-in (or sign-in)
desk. Btw, also not a native speaker.

~~~
eslaught
Native speaker here. You sign in when you arrive at a fitness club, or when
you take your child to daycare. It's a regular, reoccurring action that you
use to indicate you've arrived. I wouldn't normally use sign in for a hotel
visit since it's not normally reoccurring; you check in to a hotel, not sign
in. Sign in would be appropriate if the hotel had a policy of asking you to
sign every time you enter or exit (to keep a minute to minute record of when
you're in your room). I've never seen a hotel that does this though.

By the way, this is why an English speaker would say "sign in to a website"
but not "check in to a website". Check in is generally a non reoccurring
action.

~~~
code_duck
A minorly relevant note is that GP said ‘sign into’ a hotel, while you said
‘sign in to’, which is a subtlety difference a native speaker would know.

~~~
dsego
Oh, I actually use Writefull to check phrases, this one came up in Google
Books. ([https://writefullapp.com/](https://writefullapp.com/))

"after the raid, it is known that Brown wrote to Kagi that he would sign into
a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"

These are the results I get for web:

    
    
        - sign in to a hotel appears 0 time in Google.
        - sign into a hotel appears 81 times in Google.
        - check into a hotel appears 577,000 times in Google.
        - check in to a hotel appears 69 times in Google.

~~~
code_duck
OK, that’s interesting. I wouldn’t really trust to google books since it is
OCRed.

I can’t get Google results like those with numbers on mobile, as far as I
know. What comes up for me is discussions about what is grammatically proper
in this case. [https://www.quora.com/Which-is-grammatically-correct-
check-i...](https://www.quora.com/Which-is-grammatically-correct-check-into-a-
hotel-or-check-in-to-a-hotel) for instance. All I had to search for was the
phrase “check into hotel“, and the results show this is a hot topic of
grammatical discussion because that is what came up rather than information
about hotels.

‘Check into’ sounds different than ‘sign into’ to me, probably because few say
sign vs check for a hotel. I suppose grammatically they’re the same.

I would certainly flag it when editing. I also do not commonly see anyone use
the contracted form for this. The reason is that the verb is the phrase “sign
in”. The word ‘in’ is not a candidate to be modified by being combined because
it is paired with ‘sign’. We would never modify a single-word English verb by
adding a suffix like ‘to’, and the same rule applies for phrase verbs. Beyond
that, I’m not a grammar expert, so I would imagine the above link could shed
more light than I can.

~~~
eslaught
Right, "check into the hotel" makes me think you're going to examine it, like
you're suspicious of it's going to be a good one or something. Similar to how
you might say "I'll check into that" if someone tells you to investigate
something.

------
0xCMP
Magic links are a valid method of login that is "right" for many users who end
up resetting their accounts anyways.

It's better than using true SSO in the sense that "email is decentralized."
Yes, that means if their email is compromised the account is compromised, but
how many accounts are there are aren't already compromised when using a random
password if the email account is insecure? Every story I've heard of an
attacker gaining "access to everything" involves attacking the Email account
in some way to then password reset everything.

You may also complain that Email is literally not secure so the link could be
intercepted unless it was PGP encrypted (somehow). I grant that I think this
is perfectly legitimate when the user is facing more advanced attackers
(possibly those with passive access to traffic or backend access to emails.
NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.

We get so many "password reset" emails on our old system that I think it'd
just be better if they could login with just an email.

Users should use strong and secure methods for their email(s) and websites so
err on the side of Magic Links or SSO. Preferably Magic Links because they
expose less about the user by default except their email.

~~~
eeeeeeeeeeeee
I like the magic links, but more as a secondary option or at least an equal
option to a password. I have yet to see a site completely depend on the magic
links and I hope that doesn't become a thing.

I also really like the "go to this website on your computer and enter this
code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30
character password on a TV remote.

~~~
kiliankoe
Notion uses magic links only for their login and it's aggravating. It may be
nice for some users, but using my password manager's autofill is much faster
than going to my inbox and clicking a link.

~~~
huy-nguyen
I think Medium does this too (unless you want to log in with your social
account, which I don't like for privacy reason) and it really annoys me.

------
Apylon777
The worst offender I have seen in the wild is treasurydirect.gov. The password
must be click in on an online keyboard, and they do not allow password
managers to enter the passwords.

Screenshot here:
[https://en.m.wikipedia.org/wiki/TreasuryDirect](https://en.m.wikipedia.org/wiki/TreasuryDirect)

~~~
humblebee
> A virtual keyboard, with keys that display in random order, is available to
> deter others from learning your password.

This is a weird way to describe keyloggers if that is actually what they are
talking about.

The random order I don't understand either unless the "keylogger" is also
recording mouse positions.

Otherwise, if this is actually talking about over shoulder lookers it probably
has the exact opposite effect because of the increased time require to enter a
password.

~~~
ben_jones
The irony is that if someone managed to install a keylogger, they could've
installed any other RATing tool such that the machine itself and everything it
touches it completely compromised.

~~~
Cpoll
I imagine 99% of keyloggers are the 'put this on as many machines as possible
and look for worthwhile logins' type, which are well-thwarted by this
approach.

Anything more bespoke than that is probably much rarer.

------
013a
> don’t split login across multiple pages

This is often necessary for enterprise applications; what they're often doing
is making an intermediate request once they have your email address to
determine how you log in. Do you use a password? Do you use SSO? If you use
SSO, is it SAML? Do you have multiple accounts?

Here's my experience, as an engineer at an enterprise company. We tried to put
everything on one page, and that included an SSO button for every type of SSO
provider. Users UNIVERSALLY hated it. They didn't create their account; their
company did, who purchased our product. They don't know whether they should
log in with Email, Password, SSO, hell: Most of them didn't even know what SSO
is or what Provider they use. They see a Google button and they click it, then
try to log in with their personal Google account; their company doesn't use
G-Suite, they use Office 365, we reject the login because they don't have an
account, we get a support ticket.

Its absolutely hilarious to me that all of these Suggestions are motivated by
the use of password managers. The number of people using password managers is
literally a rounding error.

~~~
argd678
There needs to be a standard or something here to facilitate password mangers.
Everyone should be using one and not reusing the same password.

~~~
nojvek
I hate password managers with passion. In general passwords are hard to
remember. Especially when every site has their own requirements. Password
managers add too much friction.

I very much like login in with google. Even two factor TOTP is nice. I don’t
have to remember things. I just need to carry a device with me.

~~~
geofft
The trick is to install a password manager browser extension, not to use a
password manager that operates as an isolated app / CLI tool / website / etc.
Then you unlock it once at the beginning of your session (or whatever
frequency you feel like) and it will fill in passwords for you when you click,
without having to copy/paste them. It's about as easy as external login /
login with Google.

(inb4 "but password manager extensions have bugs that cause them to fill in
the password on the wrong site": get one that doesn't.
[https://news.ycombinator.com/item?id=18984582](https://news.ycombinator.com/item?id=18984582))

~~~
tialaramex
Having auto-fill may be rather dangerous even if your password manager
extension has no bugs whatsoever. I would not recommend this configuration.

Having one touch form fill for credentials is good enough. It adds one touch
to every intended login, but deletes the risk of credentials being captured
when you weren't actually even trying to log in.

~~~
dumpsterdiver
Regarding auto-fill, I second this. Password managers are great, but I would
go so far as to advise against using password manager browser extensions
entirely. You're adding several more vectors to be compromised, and imo the
risk is not worth it.

Navigate to the site, open the password manager, copy and paste the username
and password into their respective fields. Yes, it's less convenient, but as
we know convenience is the bane of security.

With authorization we have a few things available to us - something you know,
something you have, something you are. To remain secure you will always use at
least two of these when authorizing with a service.

The login information for my password manager is stored in my brain -
something I know. The 2FA code I enter from my phone is gathered from not only
something I have (my phone), but must be authenticated to with something I am
(my face (although they could probably just brute force my pin)). I take it a
step further by storing the 2FA codes for my most valued accounts on a
completely separate device that I leave at home. /protip

~~~
geofft
> _Navigate to the site, open the password manager, copy and paste the
> username and password into their respective fields._

This leaves you vulnerable to (at least) two attacks:

1) Phishing. The password manager extension will refuse to send the password
to the wrong site; it can't be fooled when tired the same way you can be
fooled when tired.

2) The password stays around in your clipboard. There's a general risk of
accidentally pasting it (e.g. to the next site you log into). There's a
specific risk of sites that capture activity on unsubmitted form fields, which
is becoming way too common.

You should decide for yourself how you weigh these risks, but I'm a pretty
paranoid person (e.g., I have a Chromebook in a corner of my room which I use
as an SSH / web client for certain high-security sites like my domain
registration and maintaining certain servers) and my conclusion is that the
risk of phishing and mispastes is high and the risk of my particular password
manager extension having serious bugs is much lower.

> _Yes, it 's less convenient, but as we know convenience is the bane of
> security._

I'll be honest, I don't know that. Security keys are more convenient than SMS-
based 2FA, and significantly more secure. Signal is more convenient than PGP,
and (depending on threat model) more secure in real-world use. Doing string
processing in Python is way more convenient than doing it in C, and way more
secure.

"It's annoying, therefore it must be secure" is a fallacy. Sure, there's some
correlation, but it's not a perfect correlation.

~~~
tialaramex
Yeah, Security Keys definitely illustrate that "more convenient" isn't "less
secure". Signing in with a Security Key is so painless, it's just a shame I
can't do it in more places.

Use the clipboard as interprocess communications for secrets does seem
dangerous. The 'pass' password manager I use has an option to do that if you
want that, but I've rarely used it. However it may be less dangerous than you
realise - by default pass will destroy clipboard items it added after 45
seconds. This is easy on X and, as far as I know, any modern graphical
desktop, because the "clipboard" isn't (usually) really a static buffer, it's
a live negotiated relationship between desktop clients, so "pasting" is an
operation in which the copying software is itself actively involved, so if it
were to crash, the content is gone, not left on the clipboard.

------
argd678
My list:

1\. Don’t have your website take a longer password than your mobile app and
then not let correct passwords login inexplicably

2\. Don’t break completely on valid passwords because there’s a char you
didn’t expect, testing is a good thing in security critical code.

3\. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank
for a user by trying to replay a token code

4\. If you login to any 3rd party services on behalf of a user, support a
method that doesn’t require asking the users for their password such as OAuth2

~~~
Solvitieg
My biggest one is...

Requiring users to login with a username or customer id. (instead of email).

~~~
Casseres
My biggest (related) one is…

In the sign-up process, validate the email (don't trust the user). I get a lot
of emails that companies never validated, including for a while, from Wells
Fargo.

~~~
curun1r
Unfortunately, the trend is in the opposite direction. People have realized
that email validation is a step in the funnel where you lose users. And when
you look at it as a funnel conversion optimization problem, you arrive at
myopic conclusions that are insecure and have externalities like the one you
noticed.

------
analog31
Something I've noticed, since I've been living for a few days with "my cell
phone is my computer." When a login form appears, my on-screen keyboard pops
up and covers half the form. Thus, anything at the bottom of the form is
likely to be hidden unless I remember to look there. So a cell phone friendly
login form should put the most vital info in the upper half.

------
crazygringo
> _don’t put logins in modals_

LastPass fills out my username and password on modals just fine. Tested it out
on Hertz just now. If other password managers don't... then they should be
improved, no?

Why should a site bother with a slower page load when an instant modal works
just fine, as long as it's properly implemented?

> _don’t split login across multiple pages_

I've never seen this done except when it's necessary because depending on the
account identifier (username) a different authentication method is used --
e.g. redirecting to your institution's authentication page.

Of course if you have a direct account you have no idea and it just seems
annoying. But it is a feature, not a bug.

I'm not convinced the author has really done their full research here.

~~~
bwood
>> don’t split login across multiple pages

>I've never seen this done except when it's necessary because depending on the
account identifier (username) a different authentication method is used --
e.g. redirecting to your institution's authentication page.

I've actually noticed this becoming more common and I find it super annoying
when there's no obvious need for it. Even Google does this now:

[https://i.imgur.com/ZH1yiqH.jpg](https://i.imgur.com/ZH1yiqH.jpg)

~~~
scarejunba
That allows federated login. You can federate Google login to Okta etc.

~~~
gruez
Paypal and iCloud have 2 step logins as well. It doesn't seem likely that they
would need to support federated logins.

~~~
0xCMP
And yet they most likely do.

------
jillesvangurp
It's 2019 and we're still doing email based signups, by default. What's wrong
with this industry? OpenId was a pretty neat idea twelve years ago. And given
the amount of password databases getting compromised, quite many websites
would have been better off federating identity with a competent provider. But
no, world plus dog still outsources security to email providers like hotmail,
gmail, or worse. Basically compromise somebody's inbox and you gain access to
most of what they ever signed up for. Single point of failure, and even if you
protect it properly you are still at the mercy of their support not falling
for some social engineering attempts.

It would be nice if Mozilla followed through with their repeated attempts to
integrate authentication in the browser (they've been experimenting with this
for most of this decade) and deliver something that 1) works, 2) is stupidly
easy to start using for websites, 3) is bleedingly obvious to use for end
users. The current implementation of webauthn fails all 3 tests. I've not seen
it work once. I rarely encounter websites that support it and it does not work
with mainstream hardware like the nano ledger or now very common finger print
readers on many laptops.

I've had finger print readers on my laptop for ages. I've yet to encounter a
website or browser capable of doing anything productive with that. I thought
webauthn was supposed to be it but it seems to be out of scope and instead
require USB dongles. Even Apple, who apparently love dongles, are not
bothering to support that with a dongle or other people's dongles. The first
browser to do the bleedingly obvious thing to support built in fingerprint
readers in combination with webauthn would instantly incentivize hordes of
website developers to start relying on that. So much easier than messing with
passwords. Also, MS seems to perpetually get stuck doing proprietary whatever
instead of fixing security properly. Apple has been shipping touchid for a few
years now. Lenovos came with fingerprint readers last decade already.

~~~
treve
I also don't understand why Mozilla killed these projects. The original
persona (BrowserID) was a pretty solid idea, but I think it's pretty expected
for these things to take years of advocacy to pick up.

I wonder if it was changed and canned simply because they didn't hit their
early metrics.

~~~
WorldMaker
My (lay) reading of it was that it was indirectly killed by the FirefoxOS
efforts. A lot of the enthusiastic BrowserID/Persona folks got roped into the
login/auth parts of FirefoxOS. I think a lot of good enthusiasm/energy was
burnt by FirefoxOS not doing well, and that burnout was
accidentally/indirectly the death of BrowserID/Persona more than anything
else.

------
K0nserv
Progressive disclosure can be made to work with password managers, notably
Apple's Apple ID login page[0] does this while still allowing the password
manager to fill both username and passwords in one action.

0: [https://appleid.apple.com/](https://appleid.apple.com/)

~~~
extra88
As does [https://accounts.google.com](https://accounts.google.com)

------
alanh
I have seen some sites that only show a username field but nevertheless are
compatible with my password manager (1Password). What I suspect is going on is
that the password field is present but visually hidden (not missing and
probably not with display: none, but perhaps by being placed in an overflow:
hidden box with a height of zero or a similar technique).

I haven't confirmed this hunch as to the technique but it seems like a good
compromise if there is a good reason to hide the password field initially. And
I think there are some such good reasons. For example, if you are Google: Not
everyone logs in to Google with a password. I have to log in to my work
account using our company's SSO provider, so that Google account has no
password. In this case, I shouldn't see a password field, as its presence will
be more confusing than helpful. Still, a hidden-but-present password field
would allow my password manager to work in the case that my Google account
does in fact take a password. (Presumably care should be taken to avoid adding
extra confusion to users of assistive technology.)

------
geekrax
The login form on TreasuryDirect is cancer.

\- They split the form into two parts: Username/Account-Number and Password.

\- The Username field disables autofill.

\- The password field on the next page has a virtual keyboard. No autofill,
the field is readonly.

I have been using this bookmarklet to "fix" these fields and let the password
manager work on these fields:

javascript:document.querySelector("input[autocomplete='off']").removeAttribute('autocomplete');document.querySelector("input[readonly]").removeAttribute('readonly');

~~~
rblatz
I came here to specifically complain about TreasuryDirect. Thanks for the
bookmark fix. I've just been going in to devtools and manually deleting the
readonly. This will save me time and frustration.

------
mpicker0
How about username/password fields that actually look like data entry fields?
In the Delta example, the "fields" are indicated by a faint grey underline
with placeholder prompts nearly as dark as the page text. I've seen this on
multiple sites; I guess it's not fashionable to show "ugly" text entry boxes
in the UI, but without them, it's hard to immediately recognize where I should
click to enter my username.

------
jes
Could web developers and password manager developers get together and develop
a standard web API for authenticating with a website?

I want to specify a URL and have my password manager run a behind-the-scenes
conversation with the website and, ultimately, drop me into the home page in a
logged-in state.

~~~
koolba
Ditto for a standard API for updates. That way you could have your password
manager automatically rotate your password, either on a schedule or in
response to a known breach. Hell we should have an API or machine readable
stream for breaches too.

~~~
Ajedi32
At that point, you might as well just move to full public-key based
authentication.
[https://www.w3.org/TR/webauthn/](https://www.w3.org/TR/webauthn/)

------
rcfox
My company is planning to roll out a new login form with a "don't remember me"
checkbox. The guy who implemented is standing by it because that's what the
mockup showed, and the designer essentially covers his ears and shouts LA LA
LA LA when you try to address it with him.

So yeah, I expect some fun comments when that eventually rolls out.

~~~
bduerst
This default is only going to create security risks as users login on public-
facing devices, like a library or device they don't own.

I hope you don't make PII or transactions available inside your app, otherwise
I would urge escalating this issue internally.

~~~
Scooty
I'm probably in the minority, but I just expect web sessions to persist
regardless of what checkboxes I check. If I have to login to anything on a
computer that isn't mine, I just open a private session (usually incognito in
Chrome).

------
davidwitt415
Imo one key point is missing: Don't give users the option authenticate via
Google or Facebook. While it may be convenient at signup, it creates an
unneeded dependency and confusion if you forget how you log into a certain
site.

~~~
Someone1234
It is funny how trends shift.

A few years ago there was a glutton of articles telling us that we cannot do
authentication correction, and to just offer single-sign-on via
Facebook/Google instead.

Now everyone is back to doing their own home-grown, and Facebook/Google
authentication is seen as bloat.

~~~
postalrat
So everyone is happy with depending on a password manager? Because having 100
different passwords and having to rotate those isn't going to happen any other
way.

~~~
ocdtrekkie
There is no reason anyone needs 100 different passwords and/or those passwords
to rotate. This is terrible advice, you don't need it and you shouldn't do it.

As of current, haveibeenpwned hasn't found any breaches connected to my
current email address, which I switched to around three years ago. Which is to
highlight: Most breached password data is _really, really old_. A surprising
number of breaches come via an email address I was only signing up for
accounts on more than six or seven years ago.

Furthermore, most of your accounts don't matter. Things like your email, your
bank, your web hosting, need to be secured well. An account you used once to
sign up for a newsletter does not. Don't save your credit card info in every
single web store you log into, and your security on those accounts don't
matter either.

Focus your security and your password uniqueness and complexity on accounts
that matter, and stop caring about ones that don't. People have reached
security overload after being told all of their accounts must be secured, and
then offloaded the problem to a bad solution.

~~~
wipash
But with a password manager, you don't need to make that distinction. If it's
trivial to make all passwords unique, why not do it?

~~~
ocdtrekkie
The issue is that password managers are a huge weak point and a significant
compromise in your security. Generally password managers have some sort of
master password, which unlocks access to _all of your other accounts_. Why
bother setting different passwords for every account if one password unlocks
them all anyhow?

Password manager security flaws are also a dime a dozen, and none of them have
been without significant flaws at some point or another. None of them are
operated by companies with an ironclad reputation for security. And if you
don't want to have a lot of issues going from computer to computer to phone,
you more than likely will do what many password managers suggest, which is
_storing your password data in the cloud_ , which is even more laughable,
because now we've secured all of your accounts with a single password, and
then put the data that password unlocks out on the Internet where anyone can
try to crack it.

Which is to say, if you really want to manage your passwords, don't use a
password manager. Use a scrap of paper in your wallet, or a notebook, or a
sticky note. Because all of those are vastly less attackable than a password
manager, because they require physical access or physical proximity and
probably the will and risk of accosting your person to get. Password managers,
on the other hand, are somehow both the stupidest security idea we've ever
come up with, and the thing that every "security expert" currently recommends
ad nauseum. I don't understand it at all.

Now, sure, all those accounts you don't care about, if you want to randomize
their passwords and store them in a password manager and say it's "better"
than using a handful of common low security passwords, more power to you. I'm
going to say you're wasting your time and effort (and probably money), but
you're not hurting anything.

The problem is when you entrust that same password manager to your high
security accounts like your email, your banking, etc. Accounts that deserve
far more security than a single point of failure with some cloud app written
by some company that doesn't do much else.

~~~
FabHK
Because that one password is pretty long and secure, and you enter it only on
your own machine, into one known binary, no-where else.

It strikes me as sensible advice.

Connecting your password manager to the browser for auto-fill already
compromises the security, granted, but what other flaws have there been
otherwise?

------
i_cant_speel
Don't: Force users to come up with a username separate from their email if
they aren't going to be interacting with others under that name. (eg. Hacker
News this is OK. Logging into my bank account is not.)

Do: If the username is always the users email, call the field "email" and not
"username". (Looking at you, ComEd)

------
nickjj
Most of his issues with magic links don't exist everywhere. Maybe "Notion's"
magic links are bad, but not everyone does that.

They're not tedious if you persist the login beyond 1 session.

There's also no need for any type of codes. You just receive the email, open
it, click the link and then you could be potentially logged in for months or
longer (it's up to the site who issues the link).

It's one of the easiest and fastest flows you can ask for with technology that
works today in all major browsers.

~~~
seanwilson
How long should the link work for though? What are the security implications?

Also, you get cases where someone has email checking set up on their phone but
not the machine they're on so clicking the magic link isn't ideal. This can be
helped by supplying a code in the email you can type into the site though.

As a side note, how do developers working on systems that need magic links
deal with them while developing? Usually you need some way to bypass the email
checking part while you develop.

~~~
nickjj
> How long should the link work for though?

Up to you. An hour or 2 seems ok as a general rule.

> Also, you get cases where someone has email checking set up on their phone
> but not the machine they're on so clicking the magic link isn't ideal.

Does that really come up? I've never experienced this. If I'm signing up for
something on my desktop workstation, it is always capable of retrieving email.
A lot of password confirmation links (as an alternative to magic links) would
also expect you to click a link to verify your account, which means you would
have to do it on the same machine you signed up with.

> As a side note, how do developers working on systems that need magic links
> deal with them while developing? Usually you need some way to bypass the
> email checking part while you develop.

Couple of options. Bypassing it is a valid choice. Also if your framework
supports it, you can often configure things in development so that emails
aren't really sent, but you're given a URL that you can visit which opens a
web based inbox page. This way you can preview your emails and click links.
It's basically an in-memory no-op local mail server for receiving email. Rails
and Phoenix do this well.

~~~
seanwilson
> Up to you. An hour or 2 seems ok as a general rule.

Oh, I meant how long after you click the link should you stay logged in for?
My bank makes me reenter my password after maybe 1 hour of inactivity for
example which would be super annoying with magic links.

> Does that really come up? I've never experienced this. If I'm signing up for
> something on my desktop workstation, it is always capable of retrieving
> email. A lot of password confirmation links (as an alternative to magic
> links) would also expect you to click a link to verify your account, which
> means you would have to do it on the same machine you signed up with.

I haven't used magic links enough to be honest but when I sign up using
dev/test email addresses I don't often check, the hassle to get the email is
annoying. I guess that's true for account verification emails as well though,
which is a good point.

~~~
nickjj
> Oh, I meant how long after you click the link should you stay logged in for?

That's up to the service. I think for most use cases having the login last 3,
6 or even 12 months is ok and then it would get invalidated early if the user
explicitly logs out, they change their email address or the server blacklists
the token.

> My bank makes me reenter my password after maybe 1 hour of inactivity for
> example which would be super annoying with magic links.

1 hour of inactivity is a very very long time for a bank. I think my bank logs
me out after 15 minutes or so but I can't remember when that last happened.

Are you really idling for long periods of time on your bank's site? I
typically login with a specific purpose. Maybe it's to check my balance, or
see if a recent charge / deposit went through, etc.. It's things like that
where I'm in and out in 30 seconds, or at most a few minutes.

In both the password and magic link case, you can still re-validate the
session without any user intervention as long as they are actively using the
site. If there was a legit use case where people's sessions needed to expire
after 10-15 minutes of inactivity and it was very common for that session to
expire I would re-think the entire user experience and design things so
sessions expiring weren't so common because this sounds like a really poor
user experience in any case. But if the 0.00001% use case came up where you
wanted to torture your users with logging in every 10 minutes, then I would
avoid magic links.

------
jessep
This seems like brad coming up with a list of things that annoy him, without
any data to back it up. I also like using password managers, but all that
really matters are the results that services get from different flows. Magic
links, for example, have almost certainly been a/b tested by the services
using them, and most likely lead to better outcomes. There are a lot of
genuine issues with passwords that password managers solve, but I would guess
most people still don't use a password manager. For this kind of thing, doing
experiments and following the numbers seems like the only way to do it. Why
trust your gut when you can so easily get real data?

~~~
RickS
I think you and Brad are making different arguments. I think you're both right
in different ways.

You're correct that convenience features like this, despite undermining
password managers and interrupting power-user security practices, create
positive business outcomes. Ditto for things that win A/B tests.

But user experience != business experience. Positive business outcomes don't
imply that users are being maximally well served under the winning system.
Example: anything by Comcast or Verizon.

\---

Separately, I believe in the case of Notion specifically, their use of emailed
unique strings in place of passwords is a security decision made by them to
avoid storing credentials, which they consider riskier than the magic links.
While I find this tedious as well, I respect the decision and it's not a
frequent PITA.

~~~
nickdandakis
The magic link / Notion example is completely lost on me.

"The pattern is incredibly tedious"

That's the point. You log in to your email to log in to your Notion. It's not
2FA, but maybe there should be some other term for it (like External Factor
Authentication). I think unifying all of our logins against our email would be
a step forward, not backwards. Then, sure, use your password manager for your
email log in.

"This doesn’t work at all with password managers"

Yes, because there's no password to manage. Even if password managers end up
supporting this flow, that'd require email access, and that seems like a Bad
Idea™. Funnily enough, I'm sure that if password managers started supporting
magic links with email access, UX people would rejoice even though it's a
security concern.

"It forces users to learn a new convention"

Yes, it does. Granted, the Notion flow could be easier by injecting the
temporary password into the log in URL, such that the end-user doesn't have to
copy and paste it over.

------
tylerl
Splitting username and password across two different steps:

Google recently switched to this model/workflow, but for good reason. They
introduced support for integration with third-party authentication (using
SAML) so that you could authenticate to your Google account using your own
company's auth as it's source of truth (AD or Duo or whatever). And since it
decides whether or not you need a password based on your username, you can't
ask for both at the same time.

------
cletus
I would go further than this: don't get clever with logging in. Here's a list
of "don't"s:

\- DON'T arbitrarily restrict my password from being too long

\- DON'T arbitrarily restrict me from using special characters

\- DON'T arbitrarily me require to use certain classes of characters (eg 1
uppercase, 1 lowercase and 1 number as a requirement; see
[https://xkcd.com/936/](https://xkcd.com/936/))

\- (this is a big one) DON'T TRY AND STOP ME PASTING MY PASSWORD. I can't tell
you how infuriating this is.

Login forms aren't hard yet the desire to "add value" with little restrictions
and tweaks (because security) is maddening.

~~~
dragonwriter
A good idea is just to follow NIST SP 800-63B rules and recommendations for
passwords (“memorized secrets”) unless you have a really compelling reason to
deviate from it. And to be extremely skeptical if you think you have such a
reason.

This actually includes all of your rules and others, such as excluding use of
password hints and server-specified “security questions” (which are just a
kind of weak password used to protect a stronger password), and accepting
Unicode.

~~~
wccrawford
Do you have a good source for those rules in an easily digestible form?

~~~
dragonwriter
NIST (computing, at least) publications in general, and 800-63B specifically,
are pretty straightforward and digestible to start with, IMO.

------
quadrature
How do people feel about the passwordless option discussed in the article?. I
feel like it can be done smoothly by:

\- giving the user a link to their email service

\- providing a link in the email that completes the auth flow, no need to copy
paste anything.

~~~
Ajedi32
Well, for one it's far more secure than password-based logins are. (No need to
worry about weak passwords, brute-force attempts, credential stuffing, etc.)

------
RankingMember
While we're on the subject of bad login pages, can we also please stop showing
UI elements (e.g. upvote/downvote/flag in comment sections) that jarringly
take you to a completely separate login page when clicked (rather than giving
you a modal or some other non-jarring login opportunity)? The more egregious
ones don't even take you back to where you were after you login.

------
scotchmi_st
I think this falls under the principle of 'good design is as little design as
possible'.

------
guntars
Here's another one - DON'T disable the submit button if the fields are empty
since some native password managers like Chrome iOS will render as if they've
filled the fields, but only provide the values on the user's first interaction
on the page. A simple form doesn't have an issue with that.

------
thinkloop
What is the fundamental nature of a login page?

Is a login page a first-order feature of a site, a real piece of functionality
that should have its own url (aka `/login`)?

Or.....

Is a login page just one possible state of an actual page? For example, if you
have a secret dashboard page at `/secret-dashboard`, and Bob is logged in he
would see his dashboard data, while if Suzy was logged in she would see
different data for her (different pages). Doesn't it follow that a non-logged-
in user would simply be presented their "data", which in this case would be no
data at all and a login page instead? All while the url stays at `/secret-
dashboard`.

This would still allow being able to directly visit a login page (as the
article recommends) by simply going to any protected url.

------
edoo
I was a regular user of Expedia until some genius got the idea to disallow
pasting into the password prompt. That was a few years ago and I couldn't tell
you to this day if they fixed it or not. It was probably a short lived
experiment.

------
tzs
One bit of cleverness I would like to see is allowing username and password to
be entered together in the same field.

Provide the normal, separate username and password fields, and if both are
filled out proceed normally.

If, however, the username is blank but the password is not, check to see if
the value in the password field contains internal white space.

If it does, split it on the first run of internal white space, taking the
resulting two strings as the username and password.

This allows entering both the username and password with a single paste
operation. This would be convenient for people who are managing their
passwords via some mechanism that cannot automatically fill out fields in
their browser.

~~~
enobrev
Unless you have spaces in your password

~~~
tzs
It's only a problem if you have leading spaces in your password. If you want
the option of single field login you would have to avoid that.

I suppose an interior space in a password also raises the possibility of
accidentally logging in as someone else. Suppose your password is "foo
bar.spam", and you try to login using the normal two field approach, so you
put your username in the username field and "foo bar.spam" is the password
field, but somehow botch filling out the username field so it is blank.

The system will try the alternative interpretation, that you want to login as
user "foo" with password "bar.spam". If there happens to be someone with "foo"
as a username who happens to have "bar.spam" as a password, you will end up
logged in as them!

This could be addressed by requiring some special value in the username field
to signal you want to use the one field option. Say, "a" as the username means
look for combined username/password in the password field. It's slightly more
work for the user as they do have to enter something in username now, but
still only needs one copy/paste which is the main point.

------
elfakyn
Also, for the love of all the gods, don't prohibit pasting in the password
field!!

------
efficax
I agree with a lot of this but magic links are great and I love them. Don't
take away my magic login emails.

~~~
psychometry
You might be the only one...

~~~
thisisweirdok
They're not the only one. Don't shame other people for their preferences.

------
firexcy
Can anyone explain to me the rationale for the recent trend to split the input
of username and password into two steps? I noticed more and more services
(including Outlook, iCloud, Evernote, etc.) have adopted such an annoying
design, which makes no sense to me. I guess the purpose for doing so is to
preempt user from typing a wrong/non-exist username so that server resources
for checking unmatched credentials are saved and brutal force attacks are
prevented? But do they justify all the hassle caused to daily users?

------
montagg
> don’t split login across multiple pages

At a company I work with, we found that splitting account creation and login
fields across several pages actually simplified the account process for
customers and led to increase sign ups and more reliable log-ins. It’s not as
efficient for password managers—I use 1Password, too, and it’s a minor
friction point for me personally—but for users, we have some evidence it
actually increases clarity through focus.

------
astine
Is there any technical reason that a password manager cannot be made to work
with split logins or hidden fields? Shouldn't they have access to the same web
browser that user does? I'd think that could be scripted to handle these
things. Obviously this makes it more complex for password managers to auto-
enter passwords, different websites will have different scripts but I see no
reason for this to be an insurmountable issue.

~~~
schroffl
I made a custom password manager a while back [1] where I used the
MutationObserver API [2] to detect when a field is unhidden or newly added. I
mainly did it to deal with iClouds login flow. The performance of that could
probably be improved by figuring out the container of the login and only
attaching the observer to that. But the whole thing was never really finished
and I eventually forgot about it.

[1] [https://github.com/schroffl/browser-
password](https://github.com/schroffl/browser-password) [2]
[https://developer.mozilla.org/en-
US/docs/Web/API/MutationObs...](https://developer.mozilla.org/en-
US/docs/Web/API/MutationObserver/blob/master/content-scripts/login.js#L11)

------
Imburr
I contacted notion about their lack of passwords and having to use the login
link every time. It is inconvenient when you work as an IT field agent and
you're all over the place on different networks and devices needed to look up
IP addresses or passwords.

they did reply that the reason they did it was security so that they didn't
have to store passwords and worried about data breaches, which I can
appreciate.

------
JeffRosenberg
> Since password managers are terrible

Wait, why are password managers terrible? That's not an opinion I see much,
can you explain why you say that?

------
echeese
Also, set the autocomplete attribute: [https://developer.mozilla.org/en-
US/docs/Web/HTML/Attributes...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Attributes/autocomplete)

------
Spectral
This list reads like Brad trying to offering semi reasons why XX is bad, but
then at the end of each point his real motive comes out which is he's just
annoyed his password manager doesn't work smoothly. Some points are valid, but
the post just appears very biased.

------
neltnerb
I think I'd settle for not using javascript to actively block autofilling
passwords! I've actually encountered this with the washington post and it was
just amazing that they took active measures to break my ability to log in with
a password manager. They did fix it after I complained a bunch though!

I see the point of some other posters about enterprise systems, but I would be
thrilled beyond belief if simple websites with simple login flows who and
aren't offering complex services, at the least, keep things simple.

I shouldn't need to spend minutes of active attention to log in to a news
website. (but kudos to the washingtonpost for eventually getting my point)

------
indysigners
Despite its simple appearance, login forms bring in a bunch of usability
failures that so many sites suffer from, actually most of them. Social media
login hasn’t necessarily helped matters either.

There’s a whole book dedicated to good, simple, mobile input-friendly and
accessible forms at [https://www.smashingmagazine.com/printed-books/form-
design-p...](https://www.smashingmagazine.com/printed-books/form-design-
patterns/) and it has a whole chapter dedicated to good login forms... sorry
for the plug, but I think it’s a really good book — I learned a whole lot
while reading it!

------
taylortrusty
The reason the Delta interface hides the last name field is it's only
necessary when entering a username. If you enter a Skymiles account # and
password, you're not prompted for a last name (or at least I'm not).

------
mLuby
I just want to call out Mullvad VPN (in a good way) for only having one field,
a super long account number, that acts as both username and password. Extra
simple and extra private!

------
CM30
Here's another one:

Don't do what some banks do when they separate the password field into
multiple boxes for various characters in your password. It's enough of a
hassle trying to remember the password sometimes, let alone when you've got to
randomly work out what the 3rd, 7th, 10th and 15th characters of it are too.

They also do this for the pin number too, which is obviously much easier to
figure out but again adds unneeded stress for little extra security.

------
Jefff8
I disagree a bit with the article. The premise is that you shouldn't make
login forms behave badly for password managers, and I agree with this. But at
the same time, people using password managers are not necessarily the major
use case for a site or some software. You should make it easiest for the
largest number of people you can, and that might mean decluttering the UI and
co-incidentally making it harder for password managers.

------
dustinmoris
I agree with the many points but it's worth noting that login forms are made
for humans to identify themselves with a service and all his suggestions are
designed to make it as easy as possible for a bot/machine to identify as the
human. There is always another side to the story and whilst password managers
are one type of machine for which this becomes useful, it's not the only one.

------
eridius
Progressive disclosure works with password managers as long as the hidden
fields are still in the DOM and are simply rendered invisible to the user. For
example, Apple's login forms work this way where they don't show the password
until you've entered your Apple ID, but it still works just fine with
1Password (and with Safari's built-in password manager).

------
rubenswieringa
Point well made for 99% of the cases. Years back though, I worked on a web
application for the elderly – try not getting clever with login forms to a
userbase that doesn’t know the difference between logging in and signing up.
There are definitely situations where it’s merited to (try to) overcome a lack
of tech-savviness with unconventional UIs.

------
alkonaut
I think the Delta example looks pretty ok. If the user enters a number in a
field a second field isn’t required. Then it shouldn’t be visible and enabled
until we know that it’s needed.

We don’t make a worse UX for humans to make a better “api” for scripts.

There must be a way of satisfying both here without being worse for humans. If
not: optimize for humans.

------
sircastor
I keep running into the hidden fields mentioned in this article. I'm also
maddened by Evernote, which has a login link on it's home page that's only
visible to the desktop. If the window is too narrow, is a phone/tablet
interface and the only link for login is at the bottom of a clickable menu.

------
ronreiter
The reason password entry is sometimes split to two forms is because of SSO
logins. The alternative is what Microsoft does which is to dynamically check
the email after filling it and passing on to the password field and quickly
redirecting if needed which is also weird. That’s also why Google does it.

------
pjc50
One of these days someone will "solve" login and we won't need all this. Today
is not that day.

~~~
polynomial
Based on some really outstanding examples I've seen in the wild, the solution
is here, it's just not evenly distributed yet.

------
philip1209
What does HN think of Google Invisible Recaptcha on login pages?

We have it implemented but have been receiving feedback lately that it doesn't
play nicely in many cases (no Google account, private browser windows, privacy
plugins, etc). I'm trying to decide whether to remove it.

~~~
0xCMP
I really dislike when it's blocked, but I have no idea.

Login forms should 100% have an error state shown to the user when the problem
is the captcha not loading, being sent, etc.

I personally white-list the Recaptcha stuff just because there is a legit
security benefit to it and not much else I'm aware of to work as well as it
does.

------
cjohansson
Google has probably the most tedious logins of all services, with multiple
pages and maneuvers you need to do to login with another account without
automatically linking the accounts. Often it’s just easier to clear all google
cookies than try using the login interface

------
g4k
Shopify started not just splitting the login, but also redirecting to another
domain for the password entry. This leads to the situation, that the password
manager can not find the correct password anymore as the login domain is not
visible during password entry.

------
aschampion
Evernote is guilty of this. They don't create the password field until you've
typed in your username, breaking every login manager. This along with their
synchronization getting worse over time has effectively caused me to stop
using it.

------
blhack
Since these threads often become: patterns I think are stupid.

On the Xbox One (which runs the home theater in our house): it hides the
characters of your password, which I think is somewhat silly to begin with,
but you type it in with a giant, on screen keyboard!

~~~
exochrono
As someone else in the room who doesn't want to see your password, it's a lot
easier to avoid seeing all the characters you're typing in than avoid
accidentally seeing the password if it's in plaintext on the big screen.

------
known
How to create a responsive login form with CSS
[https://www.w3schools.com/howto/howto_css_login_form.asp](https://www.w3schools.com/howto/howto_css_login_form.asp)

------
monkpit
> I think this may have started with Slack, but I’m seeing other digital
> products [...] send users a temporary password to their email in order to
> login

Pretty sure that’s about as old as time itself, I don’t think it was invented
by Slack

------
epynonymous
regarding his point about separating the login process in multiple pages, not
only does spotify do this, google, outlook, they all do this, i think it’s
because there’s enterprise custom single sign on which requires a different
flow, so they commonize the parts from enterprise and consumer. i’m not saying
that i think this is a good workflow or not, just saying that there’s reason
to it. and it probably breaks password managers, but for enterprise, there are
a lot of different password managers like vmware workspace one, etc which may
be different from 1password

------
gwbas1c
Entering an email address first, and then the password, is needed for systems
that support SSO.

If you're dealing with enterprise users, supporting SSO is the most important
thing you can do to keep logins quick and seamless.

------
mnm1
Atlassian does this multi page login and it's shit. Google too though as least
their shitty implementation works with password managers without having to
fill in the info multiple times. There's a simple rule one can follow: if it
doesn't work with a password manager, the login is completely broken and your
engineers and product team are morons. If it kinda works with a password
manager, the above still applies. Login has been a solved problem for awhile
so messing with it just shows what little care the website has for its
customers and how out of touch it is with them and the rest of the internet.
Such websites should be ashamed of themselves for not getting the simplest
part right. I'm looking at you jira. After login it just gets worse and worse.

------
kissgyorgy
> But it’s not just about creating consistency within your own ecosystem, it’s
> about being consistent with the rest of the internet.

FINALLY someone understands how important this is!!! Great article!

------
astrea
OpenCollective's method of emailing you a link that sets a 30 day cookie is a
pain for me as I have to be logged into my email on another tab and it seems
very insecure to me.

------
allochthon
One thing I ran into recently: a signup form that did not allow pasting a
password (one generated by my password manager). It was very annoying to have
to type it in manually.

------
randlet
Every time I logon to the AWS console I curse because the login is split
across two pages and I have to select the correct login to autofill from my
pwd manager twice.

------
shereadsthenews
This site looks great and loads quickly on mobile and desktop. Makes me so
much more inclined to seriously weigh this advice, which seems solid anyway.

------
grdeken
Just build your login form like this.
[https://my.spark.app/login](https://my.spark.app/login)

------
catchmeifyoucan
1 more pain point...I almost always forget my "special" username, so login
forms that have the email as the username are my preference

------
abalone
Here's another don't: Don't block pasting passwords!!

Amazingly there are some sites that do this. I never understood the theory
behind it.

------
sergiotapia
I stopped using Notion because of the email login thing. It got too annoying
every time and slowly eroded my love of the product.

------
ncmncm
In Wales, they'd say "Don't Tit About with Login Forms".

Seems like a thing to print on T-shirts and hand out at trade shows.

------
1023bytes
The Delta example is not quite the case. It only asks you for the last name if
you provide a username instead of their number.

~~~
crossman
Yeah I was looking at that one thinking something was off. I log in to my
delta account frequently with a password manager and haven't had an issue. I
guess that's why

------
soheil
Pretty obvious stuff what's not obvious is the attention it got on here, I'm
not hating just making an observation.

------
StreamBright
> don’t get funky with magic links

I am not sure why he brought up this. Magic links the single best option that
could have happened with website logins in the last while.

I have extremely well guarded email setup with MFA (app based not SMS based)
and any suspicious login gets flagged immediately. How many websites can do
the same? I appreciate sites who allow me to identify myself with my email
without using a password. It is one step froward for a better web.

------
ianwalter
"Don’t split login across multiple pages" should be #1. Why is this a thing?!

------
Grue3
tumblr.com manages to hit 3 don'ts out of 4: modal login window, magic links
and multi-stage login where you have to enter your username first, then
password on another page. It's extremely painful.

------
alexashka
I think the article misses a larger point - why is everyone re-inventing the
wheel?

We really don't need 'how to create a wheel' tips and tricks - it's a solved
problem. We can move on. Can't wait for a sane registration/login cross
platform widget to end this madness.

------
wishinghand
Tumblr and iCloud also split up username and password onto separate pages.

------
philliphaydon
“Don’t hide fields” this is a honeypot. Not a required field...

------
fudged71
Now do one of these for Captive Portal WiFi please!!

------
lamby
Perhaps being predictable is most of it, UX wise.

------
sfopdxnonstop
Yes, in that case ok. All others, no.

------
cronix
TLDR: I use some password managers that don't work on websites unless you use
the format the particular password manager _I chose_ to use, is using.
Therefore, web devs, please adjust _your_ code so that _my_ password manager
of choice will work, and keep up with the ever growing list of password
managers that have nothing to do with your website. It will make my life
easier. Thank you!

------
shapiro92
the split sign up fields is actually a security design

------
joduplessis
Must be those blasted full-stack developers at it again.

------
sonnyblarney
Modality is ok. The reason being, a 'login' is often an interruption to the
normal flow of experience. Trying to do 'A' then 'B' \- need to login for 'B'.
This is why modals exist.

The background to the modal gives the context to 'where the login is
happening'.

If there is no context then it can have it's own screen.

The absolute worst is when you're doing a bunch of stuff, you login, and the
app does not forward you on to 'that thing' you were trying to do, rather, you
just get to the home page after login and have to re-search etc..

~~~
mikewhy
Agreed. Modality isn't bad. The author's concerns about them can be boiled
down to "make sure your login form has a URL".

~~~
CM30
Yeah. Works fine to have a modal based login form for those with JavaScript
and a static page version as a non JS/general fallback, and that'd be the best
of both worlds.

------
thisisweirdok
Most of these patterns are fine if implemented correctly. It's not hard to
trigger a modal with a URL for example.

Password managers work fine with multi-page forms, you just have to label the
inputs correctly and the user might have to press a button twice.

Magic links are fine, and can even be good if it's you include a log-in link
in the email that does the work for you. Certainly better than a weak password
(most people don't use password managers).

I'd suggest that implementing a magic link for log-in would be superior to all
of these recommendations because it's a better layer of security than the
_literal nothing_ most people use to secure their accounts.

------
ocdtrekkie
Since password managers are terrible, I'm not fond of any of his advice here.
Every bit of feedback is regarding supporting password managers. I'll expand a
bit more on why they're completely unnecessary here:
[https://news.ycombinator.com/item?id=19172769](https://news.ycombinator.com/item?id=19172769)
but suffice to say, this is a recommendation that is getting really old,
really fast, and breaks every well-understood security principle. Single point
of failure for your entire online presence is really, really dumb.

One-time login codes are, in fact, really the ideal way to handle login, and
he's expressly asking you to not for the benefit of a far weaker security
method. And in an attempt to emphasize how frustrating it is, he adds a lot of
steps that rarely, if ever exist. Usually, you switch the tab to your email
which is already open, and click the link, which opens into a tab where you
are logged in. Two steps, not eight.

