
Password Security: Why the horse battery staple is not correct - simoleone
https://diogomonica.com/posts/password-security-why-the-horse-battery-staple-is-not-correct/
======
dllthomas
This article includes some good points, but puts them together into something
inane. It's true that silly constraints lead to trivial changes that lead to
crackable passwords. It's also true that assuming brute force over all
character classes included in a password is wrong. Those are _precisely_ what
the "correct horse battery staple" comic was getting at. Picking words at
random (that is, based on a PRNG - _not_ "random" meaning "arbitrarily, by
hand") from a dictionary, brute force over that dictionary is the best an
attacker can do, and the (dictionary size ^ number of words) calculation is a
_correct_ measure of entropy, and with sufficient entropy no passwords will be
duplicated. The "correct horse battery staple" hypothesis is that this gets a
better score on "entropy per difficulty memorizing" than generating passwords
by drawing randomly from a dictionary of typeable characters, and I find that
to hold - it's also easier to type actual words.

The other odd point is that we shouldn't be advocating stronger methods of
choosing passwords because we should be using multifactor authentication. I
don't dispute that we should be using multifactor authentication in more
places, but even in that case weak passwords are a problem!

~~~
tempestn
His primary point is that people should not be choosing passwords _at all_ ,
and should instead use a password manager, except for a select few passwords
such as logins for computer and phone, and the password manager master
password itself.

Yes, the correct horse battery staple has more entropy than most common
passwords, but the point is that we don't _need_ a way of generating better
memorable passwords. We can already just generate random, long, completely
non-memorable sequences of characters and store them in a password manager,
and that's what we should be doing.

~~~
Dylan16807
>people should not be choosing passwords

CHBS is a method for generating passwords, not choosing them.

~~~
tempestn
OK, but its purpose is to generate memorable passwords. The point of the
article is that focusing on making passwords memorable is counter-productive,
since we shouldn't generally be trying to remember passwords. And if you're
not trying to remember it, a string of 16 random characters works fine.

~~~
dllthomas
Yes and no. Secure and memorable passwords are still vital for securing your
password manager. Having a means to generate them is not counter productive.

------
cantankerous
For what it's worth, the horse battery staple is completely correct for the
problem it's trying to solve. This article is about another (arguably more
important) problem.

~~~
wpietri
Yeah, I get why he was trying to tie his point to something well-known. But I
found the title maddening. If he had said, say, "Why horse battery staple is
solving the wrong problem," I would have read his article with interest. But
my increasing irritation as I waited for him to deliver on the promise in the
title kept me from properly appreciating his point.

~~~
diogomonicapt
I agree that the title is more link-baity than it should. For what it's worth,
part of it was just a witty title.

~~~
Retric
Reading that you come off as an idiot who has no idea what there talking
about. Password managers are banned from high security applications, because
their not secure.

That said, the random part of randomly generating a password is an issue, but
combining that with something you have is reasonably secure.

PS: Some places require a 20+ character password and will fire you on the spot
if it's ever written down or stored on a device of any kind. 99% of the time
it's overkill but real security is rarely convenient.

~~~
tsotha
Having worked in places with those kinds of rules I can tell you most of those
passwords is written down. At one government shop we did an audit and found
the longer and and better a password is (and the faster it expires), the more
likely users will write it down. Not only that, 70% of them _put the written
down password in their top right desk drawer_.

We also found a large percentage of our fancy two person authentication safes
had both combinations written somewhere on the signout sheet.

You can't make peoples' lives too difficult with security directives. They'll
start to ignore you no matter how much you threaten them.

~~~
Retric
No offence, but if your not going to fire people when you find their password
written down then there going to write their password down. Written policies
are practically irrelevant it's enforced policies people pay attention to.

One example of security. Someone (A) giving a breafing has someone (B) grabs
at it so they can read the document. At which point (A) pulls his sidearm and
threatens (B). Later (A) is given an intense debriefing to verify that he was
willing to shoot (B) and simply wanted to clarify the situation vs being
unwilling to shoot (B). (B) was later told he was lucky not to have been shot.

~~~
tsotha
It doesn't matter if you fire people. You're not going to catch the vast
majority of them, and they know it.

~~~
dllthomas
From what you said earlier you can catch 70% of them pretty easy.

~~~
tsotha
Sure, if you go through all their stuff. And then what? Do we fire 70% of our
staff?

~~~
dllthomas
Well, you could. Whether you should depends on the context, including
importance of security, importance of institutional stability, other available
mechanisms for punishment, &c...

But honestly, I mostly just thought the inconsistency between your two figures
was amusing.

~~~
tsotha
The inconsistency is a result of the fact that that number came from a one-
time, expensive, intrusive audit that necessarily covered a subset of all our
people. Even then we didn't go through anyone's wallet where I would expect to
find at least that many.

After that the password policy was substantially relaxed so people could
remember them more easily, and dire warnings were issued about writing them
(and safe combinations) down. I moved on to a new job shortly after, so I'm
not sure how much those warnings were taken to heart.

~~~
dllthomas
Well, wallet is a much better place than desk drawer.

[https://www.schneier.com/blog/archives/2005/06/write_down_yo...](https://www.schneier.com/blog/archives/2005/06/write_down_your.html)

Still may or may not be acceptable, depending on context.

------
paulrr
So I've got a question. Isn't using a password manager with unique, big, long,
randomly generated passwords per site essentially the same as two-factor
authentication? Something I know (the master password) and something I have
(the encrypted password list). The password list lives on my laptop, on my
phone, etc. Furthermore, when I use 2 factor auth, I end up storing the lose-
your-phone recovery password in the password manager anyway, so I'm probably
missing the point of the SMS-, token- or Authy- based validation anyway.

~~~
MarkMc
No. Here are two differences between a password manager and 2FA:

1\. A password manager will prevent someone from hacking into a website you
use, stealing your password, then logging into another website as you. 2FA
won't prevent this because someone who hacks into to a website can get access
to the unique random seed that is used to generate the 2FA sequence, and can
then use brute-force to determine your password.

2\. 2FA will prevent someone from infecting your computer with a virus,
stealing your password as you type it in, then using that password to log in
as you in future. A password manager wont prevent this because the virus will
gain access to both your main password and the list of encrypted randomly-
generated passwords.

~~~
arnarbi
Re 1: If a.com is hacked, only a.com's OTP seeds are compromised. b.com should
(hopefully) use different seeds, so 2FA still prevents someone from logging
in.

~~~
MarkMc
Yes you are right - I was thinking about the case where only a.com uses 2FA,
not b.com

------
morgante
Despite the slightly linkbaity article, I agree with the article's actual
premise (you shouldn't be remembering passwords in the first place).

Unfortunately, it'd be tough pill to swallow for sites to push/encourage users
to get a password manager—you never want to be the site which people bounce
from because they don't understand what a password manager is.

At the very least, I wish sites would abandon the abhorrent process of
disallowing copy & paste. The completely random password my generator supplies
is _much_ more secure than me trying to remember a password for your site.
Sadly, the sites which fail at this the most are also the ones where security
is most important (ex. banks).

~~~
tempestn
I've found banks on average to be absolutely terrible with password security.
I mentioned in another comment, my bank requires a password of exactly six
characters, alphanumeric only. It's like they're trying to make it as
crackable as possible. (I believe the reasoning is that they want you to be
able to enter it for telephone banking using a touch tone phone, but obviously
it would be far better to use a separate password for that. (Especially since
I expect there's little overlap between people who use automated telephone
banking and people who use internet banking...))

~~~
vegedor
If you only have three attempts entering the PW, how is that remarkably
insecure?

~~~
tempestn
If you only have three attempts to enter a password, even most dictionary
words are secure. The problem is when the unexpected happens, and someone
finds a way around that restriction. In the worst case that might mean getting
a hold of a copy of password hashes. Or it might just be an exploit that lets
them try more combinations over the internet. Regardless, just because there
are other safeguards in place doesn't mean that password strength should be
ignored.

As far as why exactly six alphanumeric characters is bad, it should be
obvious, but it significantly reduces the difficulty of brute-forcing. You
have 2B possibilities, total, not even taking into account dictionary attacks,
which also become far easier.

------
nikcub
You have to be pragmatic with users and offer them a path of least resistance
while implementing a greater level of security. I've only recently been able
to get users to pay attention to why they need a password manager - the iCloud
hack helped more in that than even Snowden did.

That path of least resistance right now, I find, is installing a password
manager and securing it with a primary password that is generated from four or
five dictionary words. Combine that with two-factor authentication for the
most important accounts (Google Authenticator is surprisingly easy to teach
people to use).

You find corner cases that cause problems: apps that don't support
automatically having the password entered, or pasting the password in, mobile
apps that become frustrating to enter long random passwords into so users just
change them to something simple (including Apple ID's).

Four random words is beyond 'good enough' and _far_ better than what most
users are doing now. Rolling out and advocating new security measures is much
about compromise and pragmatism. When somebody who is an ordinary computer
users asks you what a good password technique is, do you spend 60 minutes
explaining entropy and how people are bad at generating passwords (putting
them to sleep), or do you just point them to a comic and one of the random
xkcd password generators?

The iCloud hacks have done more for security awareness than what a million
blog posts could ever have. It would be good to take advantage of it with a
common approach rather than mixed signaling (I just _know_ that at some point
i'm going to hear someone say "but I saw something on hacker news about how
those xkcd passwords _aren 't_ secure" \- and I will have to take a deep
breath).

Advocacy now could be focused on developers, where there is some catching up
to do - a common protocol for password managers, allowing copy and paste,
hooks in apps, agreeing on a set of weak passwords that should be not allowed
(a lot of services already do this, most use top x from RockYou), removing
those silly character restrictions (example: apple ID's can't be XKCD
passwords since they enforce a capital letter and number), building password
generating into more systems (based on an open spec - it should be an OS
feature, not an app)

~~~
dllthomas
I agree with most of this. I do think it's worth stressing the point
periodically that "random" in "four random words" needs to be "picked by a
computer", not "picked arbitrarily by a human" \- humans aren't nearly as good
at randomness as we think, even when that's what we're trying for.

------
guygurari
Password managers, combined with randomly-generated passwords, solve the most
serious problems afflicting user-selected passwords. Adding two-factor
authentication solves yet more problems. And yet both password managers and
2FA are not widely adopted by users. Where do we go from here?

I use a password manager, and the UX of registering to a new website is just
awful. On the registration page I need to check what sort of password is being
asked for (e.g. 'no longer than 15 characters'), and configure the password
generator accordingly. After registration I need to manually convert the
password into a login; my password manager can try to do it automatically, but
it often fails because it doesn't know how to translate fields from the
registration page to the login page. Compare this with what most users do:
just enter the same password everywhere. Much less friction.

I think we can make using password managers _easier_ than entering the same
password everywhere. We can do this by introducing a standard web interface
for password managers. This interface will let browsers fill in usernames and
passwords on registration and login pages, automatically. It may include
password specifications, such as 'password should be between 10-15 characters
long'.

Here's the use case: imagine the password manager is integrated with the
browser (say as an extension). When it detects this interface on a web page,
the password manager _hides the password field_ , replacing it with a message
like 'secure password is auto-generated'. Similarly, login pages that support
the interface will not show a password field at all. From time to time, the
user has to enter their single password (to allow the password manager to
access its database). In this scenario, the user has to do less work (on
average) than when they enter their password manually. When no password
manager is installed, the browser simply displays the same old password field.

Given a standard interface, implementation is simple: on the server side, it's
just a few tags that specify user and password fields on registration and
login pages, and what to replace them with when the password manager works.
There should probably also be a site identifier to let the password manager
know which registration page corresponds to which login page. (Currently
password managers rely on URLs to figure this out, and this heuristic
sometimes fails.) The whole architecture of storing passwords stays the same.
On the client side, password managers already do much of this work anyway,
including trying to heuristically figure out which fields correspond to the
username and the password. This sort of interface makes things much simpler
for them.

~~~
arnarbi
> my password manager can try to do it automatically, but it often fails
> because it doesn't know how to translate fields from the registration page
> to the login page.

I have yet to find a case where my pwd manager fails to do this (lastpass).
I've also never (with the default settings) had a site reject a password
generated by it.

> We can do this by introducing a standard web interface for password
> managers.

I think the web is closer to that than you think (it's fairly easy to figure
out the fields in a login/registration/pwd-change form). Mobile apps are a
different story, that's where we really need standard system support for
delivering credentials.

~~~
guygurari
> I have yet to find a case where my pwd manager fails to do this (lastpass).
> I've also never (with the default settings) had a site reject a password
> generated by it.

A few minutes ago I registered to T-mobile, and 1Password thought that my
username was something like mytmobile.aspx. I also find that 1Password has a
very hard time with banking sites. There is at least one bank where it simply
fails to login. YMMV of course.

Going beyond these anecdotes, even if these heuristics almost always work, I
believe that having heuristics involved at all is preventing mainstream
adoption. I think that if the password management interface is standardized
and heuristic-free, then we will see password management support in the
mainstream browsers. I am imagining a future where the auto-generated
passwords work transparently so that users don't even know about them. I think
this cannot happen without browser support.

> Mobile apps are a different story, that's where we really need standard
> system support for delivering credentials.

I agree that password management on mobile is a greater pain point, and (as
mentioned elsewhere in this thread) the additional problem there is with
entering the master password.

------
salmonellaeater
_Even if we entertained the XKCD comic and started training users to select
four random words instead of a complex single-word password, I argue that it
would not amount to a significant increase in security._

 _People are not very creative and tend to think the same way when choosing
passwords. This would lead to the exact same problem we have now, where a few
passwords such as "password123" become very common._

The XKCD comic[1] says to use "four random common words." There seems to be
some confusion between the popular use of "random" to mean "arbitrary" and the
specific information-theory meaning of "random" (better worded as "randomly
chosen"). Bruce Schneier criticized[2] the XKCD method based on the
"arbitrary" interpretation, and the best explanation of the problem I've seen
is in an answer[3] on the cryptography Stack Exchange site:

 _Random choices are random and uniform. This is hard to achieve with human
users. You must convince them to use a device for good randomness (a coin, not
a brain), and to accept the result. [...] If the users alter the choices, if
only by generating another password if the one they got "does not please
them", then they depart from random uniformity, and the entropy can only be
lowered (maximum entropy is achieved with uniform randomness; you cannot get
better, but you can get much worse)._

[1] [http://xkcd.com/936/](http://xkcd.com/936/)

[2]
[https://www.schneier.com/blog/archives/2014/03/choosing_secu...](https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html)

[3]
[http://security.stackexchange.com/a/6096](http://security.stackexchange.com/a/6096)

------
zanny
Two factor is not a good solution either. Having to lug around your phone
pulling up randomly generated strings from an RNG on both ends... defeats the
point. Instead of an RNG seed, have a shared secret.

Of course, you need a trusted party for that, but that is how oauth and
friends work. And how Persona should have worked. Logging in to _anything_
should be clicking login and everything happening behind the scenes, because
you are already trusted and authenticated by a dozen other services that
whomever you are trying to access should defer to to identify you.

At least that is what Persona was supposed to do, and then fell flat due to
slow adoption. But it was a chicken and egg problem through and through -
nobody would use an immature Persona, and Mozilla abandoned it before it had
time to shine.

Oauth is the maimed cripple of what should solve all of this, but at least it
gets the correct UX to end users most of the time, even it if means wading
through a half a dozen login buttons from various services selling your
identity.

Considering modern browsers all support synced data stores, why the hell is
there not some standards pushing api a la webrtc (in scope and adoption) to
get randomly generated unique id keys made browser side for each service you
use, that you can then sync between devices and across your browser "account"?
Persona was meant to become that, but it died. Where is the successor?

~~~
ayrx
Uhm... The 2FA used in Google Authenticator _does_ use a shared secret. The
algorithm is TOTP (RFC 6238). It's simply a HMAC applied on the current unix
timestamp with the shared secret as a key and truncated to 6,7,8 digits
depending on the implementation.

~~~
zanny
My point is that you are taking what should work behind the scenes (common
shared secret) and forcing a user interaction (typing or copying out a code)
because synchronizing that secret across user accounts on disparate devices is
considered "too hard" a problem, even though like I said the browser can be a
perfectly good commonality and Persona was on the brink of fantastic
innovation on that front.

------
A1kmm
I am skeptical of the security of the self-organising map based scheme in the
paper of his own (s)he links to in the article, despite the Fourier-transform
based hash scheme.

For a start, the scheme requires all passwords to be stored in plain text (or
with reversible encryption), or at least the DFT output for them, for the
final adjustment of node popularity levels, which is itself a risk.

Given the self-organising map (which is supposedly safe to distribute widely),
take the nodes which are flagged as the highest danger level (i.e. most widely
used). For each of these nodes, you have the amplitude of the DFT, but not the
phases. However, performing a brute force attack on the phase space is likely
relatively easy, because it would normally be relatively small. An attacker
could fix the values of all phases except one (phase_i), and then find, using
the simplex algorithm, the next value of cos(phase_i) or sin(phase_i) that
changes one of the time-domain values to round to the next output value. For
each value of phase_i, the attacker then recursively repeats the attack for
phase_{i+1}, until all passwords for the amplitude vector on the node are
enumerated.

These passwords are then used to brute force attack the system. If one
password is extremely common in the SOM, that common password should be in the
resulting list.

------
nshepperd
> _For the few passwords they do need to memorize, you should focus on making
> them dictionary-attack resistant, not just strong from an information theory
> perspective._

Information theory is exactly how you measure attack resistance (dictionary-
and otherwise). The entropy measure in the XKCD comic already takes into
account dictionary attacks. That's the point.

------
bronbron
It seems like the major gripe is against passwords like "p@assword", not
against passwords like "correcthorsebatterystaple".

If you truly choose 4 words randomly, the number of possibilities is > 1e24
(at least 1 million words in english language, likely not including slang or
names).

~~~
dllthomas
You want the spaces. Leaving them out leads to collisions, which burn entropy.

~~~
aftbit
You could also use _ or CamelCase to be a bit more friendly towards stupid
password inputs.

My biggest problem with the passphrase system is how hard it is to use with
lots of services. Plenty of places still enforce stupid requirements like
maximum lengths, one of each type of character, or no spaces.

------
protonfish
I don't agree with everything in this article and he glosses over some complex
issues too quickly, but it is good to see such a reasonable discussion about
actual password security in contrast to the pants-on-head mouth-breathing
"security" standards of "enforce changing your password every 12 weeks" and
"your password must contain an upper and lower case letter, number, and
special character."

There are people that believe those practices have positive effects on
authentication security. Those people should be identified and prevented from
ever making a security-related decision again.

------
MarkMc
> What is there to prevent “letmeinfacebook” from being the new most common
> four word password for Facebook accounts?

This comment suggests the author doesn't really understand the XKCD password
scheme. The point is to choose four _random_ words, not the first four words
that pop into your head.

Also you cannot rely on an automatic-password-checker to tell the user their
candidate password is weak: If it flags 'password1' as a weak password the
user will just switch to 'password2' and _that_ will become a common (ie.
weak) password, at least until the password checker's database is updated.

~~~
malexw
I think the author did understand the comic, but his point is that we can't
enforce the "use four random common words" rule on users since _the users_
don't understand the XKCD password scheme. They'll pick "letmeinfacebook",
which is no better than using "password".

------
foxhill
whilst i concur with the premise that passwords should die, saying that xkcd-
passwords are hence incorrect would be like saying.. hi-dpi monitors are not
better than their low-dpi predecessors - we _should_ be using direct
computer/brain interfaces.

obviously, xkcd-passwords are an improvement, in many aspects, over the
passwords many people tend to pick. but until a reliable, secure, and proven
alternative shows up (which i'm hoping it will), there's no need to muddy the
what-makes-a-good-password waters.

------
dllthomas
On reflection, there's a way you can force users to use "something like a
password manager" \- don't accept a password; instead have them prove they
hold a specific private key (and allow multiple, so they can revoke specific
devices). This would seem to be a win on all counts over a password manager.
The only thing it breaks _hard_ is backwards compatibility, but if using
individual passwords per site is so broken then that's not something we really
want to permit anyway.

------
dangoor
I liked this article and largely agree with what it has to say, but I have a
question related to a bit at the end.

The article recommends using multifactor authentication everywhere, which
sounds great for keeping things extra secure. Recently, though, I got a new
phone and I'm thankful that I only had two services for which I was using
multifactor authentication because otherwise I would have had to remember to
set up even more than those two services on my new phone.

Is there any good solution to that problem?

~~~
shurcooL
Good point, it is a problem.

I'm aware of two options:

\- either you spend the time manually trying to going to all places where you
use multi factor auth and perform "transfer device" process, which is hard and
painful the more services you have,

\- or you save backups of the original source elsewhere, basically
invalidating the security advantage multi factor offers you.

~~~
aftbit
The second option isn't so bad as long as those backups are kept offline and
physically secure. For example, with smartcards, it's common advice to
generate keys on an offline machine and copy them (encrypted if you want) to a
USB stick as well as the smartcard. Then you stick the USB stick in your safe.
If your smartcard dies, you can load them onto another card.

------
techrat
This reads like something from someone with a product to sell.

~~~
cantankerous
The product appears to be his research. Presumably as a PhD candidate.

------
shurcooL
Good point and article.

I wish there was a de facto standard password manager/data format (open
source, free, works everywhere).

As it stands, there are many good ones, and it's hard to choose _one_ , even
though any choice is better than no choice.

~~~
dangoor
I've used both LastPass and 1Password and while they're not open source or
free, I have enjoyed using them both. I currently use 1Password and find it to
be a great experience.

~~~
techsupporter
I'd genuinely like to know (and I promise that I'm not going for a vi/emacs
discussion), why don't more people use KeePass? Specific to asking you, did
you know about KeePass and, if you did know, what turned you away from it? It
is both open source and free and, from what I've seen, has a good number of
clients.

Maybe I'm barking up the wrong tree and the marketing or brand awareness of
LastPass and 1Password is much higher than I suspect.

~~~
XorNot
KeePass needs better cross-platform support. The Mono/Winforms experience on
Linux is not a good one. Keepass2Android on the other hand is fantastic, and
I'd argue a bit better then the original (out of the box support for common
cloud services).

What we're really missing is out of the box support for something like
BitTorrent sync, so you don't need to centralize your store anywhere else.

------
kylequest
"Ultimately, passwords should die" \- that would be nice, but passwords are
like roaches... they'll outlive us all :-) it's the lowest common denominator.
can't ignore it or wish it goes away...

------
donniezazen
After reading that xkcd style password generation may not be as security proof
as it sounds I decided to use Bruce Schneier's method which is just mixing the
first letter of each word of a personal sentence with special characters and
number to make a password. Considering the quantity on information we leave on
internet I fear it might be too easy for someone to parse everything I have
written, every places I have been, and everything I have done to come close to
the words that I might use to compose a password worthy sentence.

------
lisper
Maybe this would be a good time to plug my proposed solution to this problem:

[http://dswi.net/](http://dswi.net/)

~~~
arnarbi
Could you give a short explanation of the differences to BrowserId?

Are the keys tied to origins? If so, how is that enforced? If not, how do you
address the privacy issue of origins tracking you through your key?

~~~
lisper
> Could you give a short explanation of the differences to BrowserId?

DSSID pre-dates BrowserID. The underlying protocols are essentially the same,
except that in BrowserID you have multiple keys and they are bound to email
addresses. In the current implementation of DSSID you only have one key
(though that could easily be changed) and it isn't bound to anything. You
establish the identity of your key simply by using it to sign things.

> Are the keys tied to origins?

No, but again, that could be changed.

> If so, how is that enforced?

That depends on what you mean by "enforced", but the answer is probably that
they keys would be stored in a dictionary whose keys are origins.

> If not, how do you address the privacy issue of origins tracking you through
> your key?

The current implementation is just a proof-of-concept prototype that I put out
there several years ago to see if there was any interest in it. There wasn't.
But since BrowserID hasn't really caught on I bring it up every now and again.
It's a plausible theory that BrowserID hasn't caught on because it's too
complicated to deploy, and that DSSID might turn out to be closer to the Right
Thing. Its pretty clear that passwords must die sooner or later, preferably
sooner.

------
ObviousScience
Linkbaity title from a PhD student with something to sell: the example cited
was entirely correct about password strength, and is something the article
author admits is important as it is the underpinning of using password
managers.

> Even if we entertained the XKCD comic and started training users to select
> four random words instead of a complex single-word password, I argue that it
> would not amount to a significant increase in security.

> People are not very creative and tend to think the same way when choosing
> passwords.

He also completely strawmans the XKCD example: it's not that you should pick
four words yourself, it's that you should use four randomly chosen words
(using an RNG/PRNG). In this sense, we're just picking fewer random symbols we
have an easier time remembering out of a larger symbol space, but this is
functionally equivalent to picking passwords of random characters. That was
the point of the XKCD comic - that a random chosen password is stronger than
your l33tspeak choice of a word or two.

> This means that we should stop blindly classifying password strength based
> on the number of bits of entropy3, and should consider first and foremost
> how dictionary-attack resistant the passwords is.

If you look at the right number of bits of entropy, then you get this
property: a lot of entropy in the password means that the subspace of
passwords it lives in is large, and that a dictionary probe of the space is
unlikely to find it quickly. Dictionary attacks are just a particular form of
brute force that prioritizes some kinds of passwords over others. In the case
you actually followed the XKCD example, you'd have good resistance to
dictionary attacks: your password is randomly placed in a large subfield of
possible passwords, and the randomness removes any benefit of guessing
particular words over words at random.

He's still sticking to the strawman version of the XKCD comic, and attacking a
much weaker idea than was actually presented.

> This means that instead of a password strength meter you should be ensuring
> that there is no skew in the distribution of passwords. If each password is
> guaranteed to be unique, the advantage of a statistical guessing attack is
> greatly reduced.

He even admits that the solution actually proposed by the XKCD comic would
mitigate the attacks he's talking about, and only his strawman version
doesn't.

The rest of the article is obvious security cliches about password managers
and 2FA.

I seriously suggest that this guy stop giving security advice that's wrong and
clearly just meant to market his own work.

~~~
logicuce
And may be Square should let him go as well?

~~~
ObviousScience
If he's working at Square as a security researcher and routinely did work of
this caliber, I would be surprised.

While this wasn't a good article about security, for what may be any of
several reasons that don't have anything to do with his work relationship with
Square or qualifications in general, I'm not childish enough to pretend that a
single bad article dictates even his merit as a security professional. We've
all been there and said something silly in public.

That being said, this read like a strawman of a popular comic to sell his
research/pet topic, and poor security articles like that should be called out
for what they are - poor articles on security.

~~~
logicuce
Agreed. Square would be in best position to take that call and he might be
very good at his work there. Hence my comment above was a question rather than
a suggestion.

That said, this article doesn't seem to be a tongue in cheek thing. He is the
_lead_ security researcher at a _payment processing company_. A critical
position I believe.

I am not sure if such a person can afford to have written that article where
people who are not security researcher can easily find conceptual flaws.

------
ianes
I'd be interested to know how common "correcthorsebatterystaple" has become as
a password now.

------
Sami_Lehtinen
It seems that the real hacker scenario was forgotten. If the attackers own the
system, they can do lot more than just steal password hashes. They can modify
the system to store plain text passwords when users login as well as steal the
information from the system(s), in many cases. Of course it's easy to forget
that there are sites with very different security levels. Others are just
running without any monitoring and others have very strict IDS/IPS, 24/7
security & intrusion monitoring staff & systems, version control,
configuration management, enforcement, monitoring systems, etc. I don't
actually even understand why people are so obsessed with this password topic.
I personally consider passwords as shared random blobs. So what if it leaks?
If I were the primary target of the attackers, they probably already stole the
required information from the system(s), even without the password(s).

2FA doesn't help either at all, if the system is completely compromised. The
attacker(s) can easily circumvent it, because they probably already have full
control of the system. Only way to get these things right, is tight layered
security, internal protocols, etc. Why does the 'site' anyway have full access
to password(s). Shouldn't there be secondary hardened authentication system,
and only tokens passed? Does the system(s) containing the data, properly
verify from authentication service if the user is allowed to access the data
etc? These are endless topics, when it's forgotten that there are systems with
completely separate security requirements. Is 2FA enough? No? Do you run
authentication client on smart phone? It's computer, it's hackable. There
should be hardware token. Does the hardware token give you monotonic 'non
action independent' codes? It does? Well, that's also fail. Because every
authentication code should be based on the action & content it's
authenticating. Otherwise you could authenticate something, you're not aware
about. Many systems fail on that scale too, completely. Of course there are
secure solutions, but those are expensive.

Password managers are also bad solution, because those run on your computer /
phone, and as we know, consumer devices / normal business systems aren't ever
secure. All are sitting ducks if attacker really wants to control those. Which
also means that they can access your password managers content at will.
Actually most important passwords in my password manager say something like,
"Do you really think I'm stupid enough to put the password here?"

Passwords / PINs are completely good part in multi factor authentication
scheme where you have to know something. I often wonder why people prefer to
disable passwords when using SSH key login? I personally think that key +
password is better than key only, in case of the keys are stolen. Just my
random blah thoughts about all this endless blah blah.

I've also seen many times, that the crackers have so many systems under their
control, that they don't even care to explore the content of the systems
they're owning. So they have missed the important stuff several times. Or
they're smart enough to let me to believe so. ;)

P.S. My bank doesn't allow stronger than six digits password. But does it
matter?

------
dgfv1
This article really disappointed me. It isn't about how cryptographically
"horse battery staple" is not correct, it's more that passwords in general are
the wrong paradigm for security.

------
LocalPCGuy
I'm watching the work done by Steve Gibson with interest into a password
replacement called SQRL. It's just a spec and he is developing the proof of
concept software, but as far as I know it is not a commercial venture at all.

[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

Abstract: The SQRL system (pronounced “squirrel”) revolutionizes web site
login and authentication. It eliminates many problems inherent in traditional
login techniques.

------
Ardeof
"we just can't memorize unique, strong passwords, for every single on-line
service out there"

... right. Apparently we don't speak in a language with an absurd amount of
subtle differences that need to be remembered (one example is punctuation, and
all the subtle rules with punctuation as well). We also apparently don't
memorize other things such as face recognition, navigation, mathematics,
physics, x amount of movies, actors, actresses, favourite foods.

Unfortunately, according to the article, we can't remember around 50 to 100
twenty digit passwords with pieces of singular information we already have
memorized.

The article looked promising, oh well.

Also, the article is supporting password managers. Which is the equivalent of
thinking that a smart idea would be to basically archive all of the password
information into one tiny little hackable program.

Yeah, great plan. Is this really coming from someone with these kind of
credentials?

[https://diogomonica.com/about/](https://diogomonica.com/about/)

