
Passwords Evolved: Authentication Guidance for the Modern Era - Spydar007
https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/
======
koolba
This is a nice article. Only thing missing is calling out "secret questions"
as asinine.

I loathe when sites require you to set them up as it requires manually
generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3)
and saving the pair (question plus random text) as metadata associated with
the account. Not exactly pulling teeth but it's pretty annoying to manually do
that for 3-5 entries.

Even worse offenders are the sites that don't even let you enter a value in a
text box but instead require you to pick from a drop down with a handful, say
10-15, of entries ( _cough_ United Airlines _cough_ ).

And the very worst offenders are the ones that, after successfully
authenticating with your password, ask you for the answers to the secret
questions every single time you log in ( _cough_ again United Airlines _cough_
).

~~~
chias
When joining my place of employment I had to fill out my I9 electronically.
The website had me set up an account to store my information, and gave me the
following dropdown for my secret question:
[https://i.imgur.com/iOsNmIk.png](https://i.imgur.com/iOsNmIk.png) . For those
unwilling to click, they are:

\- What is your mother's maiden name?

\- What was the last school you attended?

\- What color eyes did you have when you were born?

\- What was the last year you attended school?

So obviously you just fill in some random string as the answer, but
immediately after it you had to check a box that said that you swear under
penalty of perjury that all information you put into this form is accurate...
I'm sure that was intended to apply to the I9 stuff but technically it
includes the secret question :[

This "protects" an account that has my social security number in it, among
other things.

~~~
rbritton
Could you preface your random string?

    
    
        more secure random value instead: fd0987as0fh98a0b89safhsa
    

You're technically not lying then.

~~~
NMDaniel
But then you're not answering the question, which is also bad.

~~~
iak8god
"my eyes were brown when I was born, and here's a random string:
fd0987as0fh98a0b89safhsa"

~~~
MikeTV
"Value must be 10 characters or less"

------
tomp
Ah, passwords.

Look, webmasters, the simple truth is - I don't care. I have a default
password that is very simple to memorise (and hence guess/hack), that I use
for most logins, because frankly, I just don't care. Unless you're vitally
important to my life (email, Facebook, backup, services that I use so often
that they keep my personal/credit card data), your login/password is just an
annoyance for me, as is your password security policy.

I commend reddit and webshops that allow "checkout as guest", that recognise
this.

~~~
Analemma_
You really should be using a password manager then. You still only have to
memorize one password, but you’re not severely compromising your security
anymore.

~~~
TeMPOraL
Parent's point is that _they don 't care_. It's not _their_ security being
compromised, but the site's.

There are plenty of sites out there with unnecessary registration
requirements. I don't mind setting a weak, throwaway password on those.

~~~
BlackFly
Don't forget to use a throwaway email account! Lot's of good email providers
give temporary aliases for this reason.

~~~
msla
I like Spam Gourmet:

[https://www.spamgourmet.com/index.pl](https://www.spamgourmet.com/index.pl)

------
MarkMc
This is a great article, but it doesn't acknowledge that there is sometimes a
tradeoff between security and profit.

For example, imagine a typical user who tries to choose a password:

User: I want my password to be "monkey"

System: Sorry, that password is in the dictionary

User: OK, I want my password to be "monkey1"

System: Sorry, that password is on a list of exposed passwords

User: Grrr! OK, I want my password to be "monkeymonkey"

System: Sorry, that password is on a list of exposed passwords

User: Grrr! OK, I want my password to be "monkeyfuckyou!!!"

System: Sorry, that password is on a list of exposed passwords

User: Screw this, I'll just sign up with one of your competitors.

~~~
weinzierl
It's a usability nightmare. I played a bit with password crackers recently and
to me it is still often completely counterintuitive which passwords are easy
to crack and which are not. Now good luck explaining that to your users
without frustrating them. Take for example '_=$%=_$ _ !'. Why is that a bad
password? Because it's in one of the common wordlists (yes, it has two spaces
and no, I didn't make that up).

That's why I think there should be more focus on the point that users should
_never_ produce passwords themselves, but leave that job to a good random
generator. This is also something I missed from Troy's otherwise excellent
article. What is the point of using a password manager if you only use it to
store your weak passwords?

I also believe the argument about passwords being memorable is a red herring.
It _is_ possible to remember a low number of sufficiently long truly random
passwords. It takes effort and it is risky, but it is not impossible.
Producing a good password without the help of a random generator on the other
hand is simply impossible.

~~~
lostcolony
I have a few sites where this is effectively what happens. They have really
bad security to where triggering a password change has them send me a new
-password-, not just a link to reset my password. And then it doesn't force me
to change the password when logging in.

Well, that actually works out (except that the password is too short to
survive brute forcing), because I then log in with that, do my business, and
move on. Next time, same thing happens, "forgot password".

Which presents a much better authentication flow to my mind. Nevermind
passwords at all; just focus on whether they own a particular email account.
If the email account gets pwned, the attacker can likely log in with them
anyway (and if that's an issue you need 2-factor).

So rather than force a password at all, send them a verification email, and
have that immediately give them a token. If/when the token expires, have the
login window require their email address, and send them another link that,
when clicked (in the next X amount of time) will log them in with another
token.

I know for me that would mean -every- account I have is suddenly 2-factor
(since my email account is), they all have strong security (since my email has
a long, complicated, hard to brute force password that I keep only in my head;
it's the only one like that), and I'd stop having to rely on a password
manager.

Curious if there's any obvious flaws that I'm missing.

~~~
onli
No, you missed nothing, that scheme works. Add a bit of OAuth magic to support
direct logins for gmail, and you basically described portier
([https://portier.github.io/](https://portier.github.io/)), a successor
project for Mozillas Persona.

~~~
lostcolony
Thanks, I'll check that out!

------
BlackFly
For anyone who is thinking about using unicode for passwords, remember to
normalize the unicode before hashing it. Different human input devices may
output different codepoints for what appears to a human to be the same
character/string. Obviously make sure you manage the decoding/encoding as
well.

------
karrotwaltz
Here is what NIST has to say about allowing the user to display the password
on screen:

> In order to assist the claimant in successfully entering a memorized secret,
> the verifier SHOULD offer an option to display the secret — rather than a
> series of dots or asterisks — until it is entered. This allows the claimant
> to verify their entry if they are in a location where their screen is
> unlikely to be observed.

------
waynecochran
Math tells us longer passwords are better than longer alphabets, yet I am
often forced to add special characters. If I have 12 character password over
an alphabet of 26 characters, there are 26^12 possible passwords. If I have
the choice between adding 5 special characters or increasing the length of my
password by 5 characters, math says do the latter:

    
    
       (26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24
    

That's over _six_ orders of magnitude higher. How come supposedly computer
savvy people don't know the difference between x^N and N^x?

~~~
dublinben
What makes you think that these composition rules are being set by the
computer-savvy folks in the room, not box-checking bureaucrats? No engineer
worth his salt would propose any of the terrible password requirements (10
char max, no pasting, etc.) featured in this article.

~~~
WorldMaker
Except for the poor engineer that has to maintain password compatibility with
an ancient COBOL database that was plaintext EDCDIC in the middle of a binary
fixed field record file. In which case, give that engineer a drink, and then
the budget to build a modern system before the whole house of cards comes
tumbling down.

------
aidos
On systems that disable the pasting of passwords: could I give a special
shout-out to Apple OSX which, in 2017, still refuses to allow users to paste a
passphrase when the ssh agent pops up a window to request it?

~~~
ivanhoe
The single most annoying thing in OSX IMHO. However this little script solves
the problem: [https://github.com/EugeneDae/Force-
Paste](https://github.com/EugeneDae/Force-Paste)

------
dustinmoris
One thing which I find Troy constantly misses to advertise and which I
personally think is a much better solution than using password managers and
each individual system having to develop their own login + verification and
security system is to use 3rd parties to authenticate.

I am a big fan of password managers, but I don't think there is a need for
them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email.

If someone gets access to your email address then they have effectively access
to every single service you signed up with that email. Therefore every single
service might as well just use Google/Hotmail/Microsoft/etc. to authenticate
their users instead of building their own login system and asking people to
come up with a new password which forces them effectively to use a password
manager and yet another place to store all eggs in one basket.

The password to your email account == the password to your password manager.

If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we
would be even more secure then everyone having to use a password manager, and
it would be a much better user experience. Also I am pretty sure that Google +
Microsoft + Facebook have a lot more talent + resources to secure their
accounts then every new service which pops up every day. Let them do the
security and you focus on your actual business value...

~~~
CM30
This has numerous problems though:

1\. Not everyone uses those email services. Indeed, for a certain subset of
users (especially on technical forums like Hacker News), using them is seen as
opening yourself up to unwanted surveillance.

This means tech forums relying on such a system are potentially driving away a
decent portion of their userbase.

2\. Not everyone wants to use the same account details. For instance, if I
join a site with a more professional audience, my current username (and my
email one) may come across as awkward or robotic. If I join a fan forum, I
might want a username based on the game or show. Etc.

3\. A lot of people want to keep their online identities seperate for security
reasons. I mean, do you really want to use the same email for a dating site as
you do your bank? Not really, but tying the login systems of each site to
Gmail or the likes means you've either compromised said privacy or given
yourself another Gmail/Hotmail account to memorise the details for.

4\. It encourages centralisation. We've already got a problem with a few large
services having an untoward amount of influence online, and having their login
systems used for numerous other sites only makes that worse. It means if they
decide your site is against the rules or 'hate speech', your users can't log
in.

So nah, I'd rather sites didn't use third party authentication. It has too
many drawbacks.

~~~
dustinmoris
re 1.: Support the 10 most used email providers and you will probably cover
99% of users. Most people have a Gmail even if not as their primary email, but
so they can use various Google services on Android, or an Apple ID to do the
same on an iPhone. Unless you have data that suggests differently, I really
don't think this is a valid issue nowadays anymore.

re 2.: If you don't want to use your private email for everything, then you
already must have another secondary email, because there is literally no
registration process which you can get past without an email. So just use the
email which you find appropriate for a given website.

re 3.: Same as 2. You must have any sort of email to register anyway, so
whether it's your primary email or your secondary "anonymous" email, it's
still the same principle.

re 4.: Not doing something smart today, because there could be potentially a
futuristic abuse scenario in some point in the future is not smart. Do what's
best today, if tomorrow all email providers turn evil, then re-introduce your
own login system, but you'll still need these email providers to verify your
users.. so not sure how far you will get... but anyways.. this is a non-
existing problem today and probably never going to happen. So why degrade
experience and security for a Utopian future?

So yeah... I much rather use a secure and convenient auth system, because it
has way too many advantages and we already rely on it, we just don't admit it.
Might as well go the full length to get the best experience from it.

------
brightball
When I talk about security, the question I like to pose is this:

Imagine every password for every one of your users is published...can you
identify people? How would you clean up the mess? Imagine a malicious person
logged into EVERY one of your user accounts and tampered with them, changed
email addresses, etc. Can you identify it? Can you clean it up? Can you
prevent it from happening again?

If the answer to any of those is no...then you're sitting on a time bomb.

Start with the assumption that the username and password is convenient but
unreliable, then move forward with actual security.

------
kutkloon7
The problem with a password manager is that you don't have easy access to one
when you're on a different machine.

A better way is to use a scheme that hashes your username, service name, and
master password to generate a password. A problem is that this doesn't always
comply with the arbitrary demands on your password.

This is why these arbitrary demands need to die: they make the only way to
securely and conveniently access accounts from different devices impossible.

~~~
wutwutwutwut
Your suggestion is bad for a ton of reasons. For example, how do you change
your password for a specific site after it had been compromised or due to
normal password rotation?

Another downside is that changing master password means you need to change
passwords for all sites or have multiple master passwords.

Another is that an attacker can use the knowledge of your password on site A
to bruteforce your master password offline.

And so on...

~~~
Lagged2Death
_...an attacker can use the knowledge of your password on site A to bruteforce
your master password offline._

This might be a concern if you're the victim of a state-level targeted attack.
That's not a threat most of us have to deal with. Hackers aren't likely to
spend a lot of effort cracking John Doe's password list; they want to steal a
few million password hashes and sift out a few thousand easy or re-used ones.

Your other points about the weaknesses of the scheme stand. Still, if we could
get more users to use not-terrible, not-duplicated passwords, even with a
flawed scheme like this, overall internet security would improve immeasurably.

~~~
dublinben
You don't need to be the victim of a state-level targeted attack. You just
need to be a public figure online[0] and attract the attention of a bored
hacker.

[0] [https://www.theverge.com/2012/8/6/3224597/mat-honan-
hacked-a...](https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-apple-
icloud-google-twitter)

~~~
Lagged2Death
I'm not super familiar with the Honan story but I recall (and quick skimming
seems to confirm) that it was more about lax security policies at Apple et al,
the interconnectedness of social media accounts, and social engineering than
it was about reversing a computed hash or human "hashing" scheme.

Did those attackers guess or compute even one password at all?

~~~
dublinben
Not in this specific instance, but they could have. And that level of scrutiny
would have enabled a complete digital takeover like Honan suffered if his
accounts were poorly protected by a system of passwords proposed above.

------
zwily
Does anyone provide a regularly updated bloom filter of exposed passwords you
could use for meeting the last point? Seems like something Troy could do...

~~~
jdormit
Do you think the chances of false positives would make a bloom filter a bad
choice for this?

~~~
Deimorz
It's not ideal, but shouldn't be a big issue, since a false positive just
means that you (very rarely) tell a user that a password is unacceptable when
it should have been fine. That's a bit annoying for the user, but the result
is that they just end up picking a different secure password. False negatives
would be worse.

Really though, a list of common passwords to block is such a small amount of
data that it's probably best to just use an exact list. I can't see it being
more than a megabyte or so.

~~~
zwily
A "list of common passwords" isn't the guidance though - it's a list of
passwords exposed in previous breaches. That list can be huge, and only
practical to check with some efficient lookup mechanism.

~~~
Deimorz
Ah okay, sorry. I was thinking about it from the perspective of common
passwords since that's something I've tried to find an existing bloom filter
for before.

I agree with you that Troy would probably be one of the best people to provide
something like that. I wonder how feasible it is, that would be a really great
resource to have available.

------
xoa
While I think there is growing recognition that password based authentication
is a highly suboptimal path dependency, we're also stuck with them on the
majority of systems/services for the time being. Even if UI and market
standards for cryptographic based auth finally gets improved, it'll still be a
long haul for it to grow in usage. That being said this seems like a solid
overall listing of the basics that all password using services should follow,
except as koolba said earlier "Security" Questions (scare-quotes extremely
intentional) were always a horrible anti-user & anti-security idea and should
be eliminated everywhere.

My only actual quibble/concern with this piece is in the _" Notify Users of
Abnormal Behaviour"_ section. I agree it's a good idea in principle to perform
notifications, the only niggle though is that some common forms of
notification are not authenticated in general, and in practice that
particularly means email. I have only ever seen a few companies, even in the
financial sector, that sign emails (and without that more aggressive automated
domain anti-forging is hard too). At least from the stats I've seen on my own
servers and for users I'm responsible for, "Notification/Alert" emails are an
ever greater favorite of spearphishers & spammers. A lot of the major
companies deal with this by using better authenticated purpose-made
notification systems or even just text messages, but email still enters in,
and if the practice spreads I'd expect to see a lot more places just using
email. I think it's worth being careful about getting users trained into any
habit that might lead them to immediately assume something from an
unauthenticated source is real and should be clicked. This might be an area
that'd be worth coming up with better standards and UI for as well.

~~~
pishpash
"While I think there is growing recognition that password based authentication
is a highly suboptimal path dependency, we're also stuck with them on the
majority of systems/services for the time being."

There is a pretty clear path off of it, via physical token authenticated
password managers. The only thing missing is a standardized and well
popularized protocol for changing passwords.

~~~
xoa
> _There is a pretty clear path off of it, via physical token authenticated
> password managers. The only thing missing is a standardized and well
> popularized protocol for changing passwords._

I don't think it's that simple. After all, the basic tech to handle this stuff
has been around for literally decades at this point. Even in terms of open
source, projects like OpenSC date back a decade and a half (2002 or before).
The problem has always been in terms of bringing the elements together into a
standardized system that has a least a few major implementations with good UI,
and gaining critical mass to kick start a virtuous circle of adoption, uptake,
demand, and more adoption. It's not a technology problem. I've seen enough
hopes raised followed by false starts or even flat out regression that I think
it'll be a hard slog, though as the problem is only getting worse I'm hopeful
we'll get there eventually. And even more, that once there is at least one
good mass example showing people how things could be better there will be mass
demand and we'll see a nice S-curve of adoption rather then linear.

------
jimktrains2
The problem with passwords on the web is that they require sending and
trusting private credentials to someone else. As devs we need to working on
making better systems (e.g. TLS client certs and SRP (e.g. TLS-SRP or PAKE))
more usable.

It's not a magic bullet and not something a switch can be flipped on, but the
status quo is terrible.

~~~
IshKebab
Or OAuth.

~~~
wedowhatwedo
Not the current OAuth. It is different for each provider. The standard isn't
strict enough. I have to write something special each implementation I want to
use. The standard needs to be modified so every implementation works exactly
the same way - then I'd say OAuth would be a good potential solution.

------
SeoxyS
One thing that bothers me about this article, and the way everyone does
passwords is this assumption that the output of a cryptographic had function
is alphanumeric. It's not, is binary. Store the actual data in your database,
not the base16 representation! This applies to anything, not just passport
hashes—don't transmit around data as base64 unless you're actually using a
medium that requires it (e.g. email)

~~~
GordonS
What's the issue with storing password hashes encoded as base64?

~~~
yourapostasy
Good question, I'd like to know SeoxyS's reason, too.

Aside from the space consideration already mentioned, if I had to surmise, I'd
guess it would be faster to process because we're skipping the encode/decode
steps unless we are explicitly "importing" or "exporting" the hash, and less
chance of making mistakes to encode/decode through Base64 before doing
anything with the hash.

It is marginally more of a hassle to debug in a live production environment,
though. When you are troubleshooting, grabbing the binary representation and
running it through a Base64 decoder is annoying. Doing this from inside a mass
file search to look for all instances of the same hash can be a bother.

I suspect we're storing as Base64 everywhere because so many hashes are held
in XML files, and the standard strongly encourages storing binary within XML
as Base64. Once they are doing it in an XML file somewhere, I gather lots of
teams make that the canonical representation everywhere, even in a database
when it isn't strictly necessary.

------
shadowashe
passwords are clearly still a gigantic problem in infosec for the users
[https://blog.binaryedge.io/2017/07/24/antipublic-password-
an...](https://blog.binaryedge.io/2017/07/24/antipublic-password-analysis/)

~~~
dspillett
On a quick scan that looks like interesting analysis. Though one point that I
find most run-downs like that miss is the number of accounts that are throw-
aways, where the user simply doesn't care and will never use it again. At that
point using "123456" or "password" isn't an issue, anyone who hacks the
account gets nothing more than they would get if they just created a throw-
away account themselves.

~~~
codinghorror
The hacker can grief / spam everyone else in the system from this "normal"
account. Depends how much public interaction / content posting there is,
though.

~~~
DownGoat
True, but this is not really a problem for the user, but a problem for the
system. It is reasonable to assume that the user that creates these type of
accounts does not really care about the security of the system either.

------
_nothing
Whenever a site requires special characters, it just ends up limiting me to
one of the few memorized passwords I have that matches the criteria, most of
which are barely 8 characters long.

I use LastPass but I don't like using the password generator because I want to
be able to log in on mobile or other computers when necessary, but I don't do
so enough to justify signing up for a subscription (I dislike subscription
models) that would allow me to access use it on mobile.

I wish I could just use giant password strings on all of my sites.

~~~
drewmol
Not a huge fan of subscription models, but if using password manager software,
it seems like an appropriate pricing model. You expect/demand the software
vendor to be consistentsly up to date on best security practice and
vulnerability patching. A subscription model gives more incentive to provide
this due to the risk of losing future revenue(subscribers & reputation) in the
event of a failure.

------
gourou
[https://www.baekdal.com/insights/password-security-
usability](https://www.baekdal.com/insights/password-security-usability)

------
rietta
Excellent read. I've finally decided to do what I've been saying I would do
for two years and create an open source demo Ruby on Rails application that
applies these principles using the Devise gem and a few others. Will show it
supporting multiple two factor strategies as well as account lockout,
recovery, and access downgrading based on confidence. It's a private repo at
the moment but I will share as soon as its worth showing.

------
Someone1234
I like the concept of "Notify Users of Abnormal Behaviour" but how. I mean
that in a technical sense. This XKCD seems to apply[0].

People take for granted that an organisation can just hook into a bunch of
paid external services, GeoIP, Browser/Device Database, etc. First off,
there's a great many organisations who cannot or will not be able to use an
external GeoIP database for example, and even if they could how is a threshold
of "abnormal" determined?

I too love Facebook's implementation. How do I make that without hooking into
half a dozen paid external providers? I'm legitimately asking, because this
seems like a "research team and five years" type of issue.

[0] [https://xkcd.com/1425/](https://xkcd.com/1425/)

~~~
raesene6
You can implement a basic level of this just by storing some information about
users and then comparing it on login. Some relatively simple examples

\- Inform users of unsuccessful login attempts since their last sign-in. This
can let them know if someone is trying to attack their account.

\- Notify the user if they login from a new browser. You can record
information about the client (user agent plus other identifiers that are
visible server-side) and then notify the user when connections are made from
new systems that haven't been seen before.

\- For GeoIP there are basic datasets that cover things like country of origin
that are generally available for free. You could use one of those to note the
customers general country of origin and then notify when that changes.

None of these are flawless of course, but they could provide some basic means
to help users protect their accounts.

------
utexaspunk
Is there an independent body that certifies that a site uses good practices? I
mean, I have no way of knowing whether a website is storing my password in the
clear (unless they email my password to me), using a symmetric cypher, a site-
wide salt, etc. It would be nice if a trustworthy party could investigate a
site's security practices and certify that they are doing things properly.

------
EGreg
Or you can move beyond passwords.

[https://github.com/Qbix/auth](https://github.com/Qbix/auth)

~~~
striking
The "Specification" section is blank.

As much as I hate passwords, I don't think we should get rid of them without
replacing them with something else...

~~~
EGreg
We are still working on the formal spec. However, the overview is totally
complete!

I just put the link here to get some feedback. This _is_ what replaces the
passwords.

------
pishpash
A person only has so many memorizable passwords that they can hold at a time;
the entropy source is very very low rate. Revealing _any_ memorizable password
to stupid random sites is itself an antipattern.

~~~
pault
I use a pass phrase salted with the first n characters in the name of the
site, so I only have to remember one password and have unique passwords for
all accounts. For example, monkey + ycombinator = myocnokmebyi

------
iooi
What is the consensus on not allowing previously used passwords?

i.e., when changing your password: "You used this password too recently, you
can not use your last 20 passwords"

~~~
smichel17
I am not a security expert; I'm sharing my experience, not attempting to
answer the question.

Back before I used a good password manager setup, I used a mental algorithm of
[base password] + per-site modifications. These were saved in Firefox and I'd
sometimes forget them when I wasn't on my normal device. If I needed to get on
to a service (eg, email) whose password I'd forgotten, I'd reset it, then
reset again, back to what it was, when I got back to a place it was saved.

At some point, gmail prohibited this, and I had to update all my passwords
whenever I needed to reset. The result was the same as forced password
rotation: I just started using more memorable (less secure) passwords.

That said, there's definitely measures Google could take to mitigate this
effect. For example, drawing from the article, there could be tiered access
control, where one tier (eg, 2fa but no pw) lets me get some limited access
without changing the password. Then there would be no legitimate reason for
returning to an old password, so such a policy is not harmful.

------
ojr
No mention of how to authenticate on mobile? I don't think a guidance on how
to authenticate for the Modern Era is complete without having a mobile
solution

~~~
dublinben
Every decent password manager and 2FA solution is available on mobile.

------
wepple
I'm curious; why aren't we dropping the use of passwords in favor of U2F?

I guess for one; not everyone wants to buy and carry a key. But we're at the
point where you have to have a password manager anyhow, a token isn't that
much more of a burden.

~~~
ivanbakel
The first general-user services to enforce 2FA of any kind will be sacrificing
a massive number of users to do it. As a company running a service for money,
you have no incentive to make your system more secure on the user end -
obstacles for the user are just users lost.

Security-conscious users can push for 2FA on services, but we probably won't
hit it being mandatory any time soon.

~~~
danneu
But if there's any money at stake, then any money exfiltrated from your users
is money that you never receive, so there's certainly an incentive but also
trade-offs.

~~~
ivanbakel
Assuming

1\. Your profits come directly from your users

2\. A password crack can result in them losing a significant amount of money,
and

3\. This happens often enough that it offsets the userbase losses of 2FA

If your user accounts are important enough to let them lose a large amount of
money, your users are probably demanding better security from you already. The
real blocker to 2FA are services which rely on being convenient, and make
money off their users being users e.g. social media.

------
BucketSort
I believe eventually passwords will become cognitive thumbprints. I.e. instead
of a password, we play a short game, type in some text of which the cadence
can be analysed.

~~~
pishpash
Authenticating against something that cannot be changed but can be
counterfeited is a horrible idea. Plus, good luck storing that kind of thing
securely.

------
Piccollo
I like my passwords 1, 2, 3, and 4 5.

------
gourou
[https://www.xkcd.com/936/](https://www.xkcd.com/936/)

~~~
dspillett
Somewhat redundant as that is actually referenced by the article itself, both
as a general discussion point regarding passphrases/passwords and specifically
because that specific string is actually found a number of times in the
reference data sets.

------
ss248
>Embrace Password Managers

I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't
look like he completely understands the whole problem. The main problem is
that passmanager holds a lot of metadata.

For example, you use unique password with high entropy for every service you
use. Once attacker gets your one master password (through zero-day or just by
watching you type it), potential damage is massive. He doesn't have to try to
find where you are registered, password manager will tell everything, about
every single account and possibly more; some people even store credit
card/banking info in passmanager. At that point it's over, you lost.

"... if (password manager) gets compromised it's going to be bad news. But
this is an exceptionally rare event compared to the compromise of an
individual service which consequently exposes credentials."

This is not an argument at all. Let's consider the situation when individual
service gets compromised. Attacker has thousands of salted hashes. With good
hash algorithm, he have to spend considerable amount of time cracking every
single hash. He doesn't target you in particular. You are just one of many. If
attacker cares about you, after cracking hash and getting your password, he
has to do a lot of research (trying to find other sites where you used that
password and hope you didn't change anything there) to make any use of it.
Objectively, he doesn't actually have much. So going after popular services
you use, just to get your password, doesn't look like a good attack vector in
the first place.

People should know, that password manager is just a glorified notepad file
with one password. By using them you are trading safety in situations when
attacker targets you, for safety in situations when attacker targets someone
else and you are just a collateral damage. If you must, use them only for
information you don't care to lose.

~~~
seppin
> Once attacker gets your one master password (through zero-day or just by
> watching you type it

A bit off-topic perhaps, but can a keylogger really grab your master password
as you type it? 1password and OSX has secure entry for entering a system
password, no?

~~~
scott_karana
Key loggers don't need to be software. A USB interception, a weak proprietary
2.4GHz radio interface, or a badly implemented Bluetooth keyboard can all leak
password plaintext directly to an attacker.

~~~
seppin
so very specific, targeted attacks. In other words, unless pros are going
after you do enjoy (relative) security

