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!
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.
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.
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.
>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!
Only he never says that weak passwords are OK. Instead he says that we should not let people decide them, and instead use a uniformly random distribution of passwords (i.e. generated automatically).
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.
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.
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.
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.
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.
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.
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.
One of the most common failure modes is screen captures which are often used for auditing. So there enabled even when everything is working correctly. For encrypted passwords that are sent directly to the clipboard you still get those files backed up which means you can brute force the password file without throwing up any red flags. Also, pasting passwords is disabled on many secure applications. For apps there stored on an unsecured device with a wide range of failure modes.
Exactly. Ironically it's good advice for master passwords too.
I use a password manager, but we should recognise there is one prominent issue with them, in that they create a single point of failure. The article suggests that the strength of algorithms like scrypt will keep you safe, but that doesn't stop low tech hacking methods (key loggers, shoulder surfing, etc...). We should be looking at using master passwords in conjunction with hardware dongles, if we really care about maximising security.
And possibly a handful of master passwords (and handful of dongles) of various levels of security. I'd rather not unlock my bank info every time I want to log into facebook.
This is a good point, and one I've wondered about since using LastPass. Having a segmented password safe would be nice for more secure accounts you use less often. I definitely wouldn't like to leave my password safe open in, say, a library.
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.
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.
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.
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).
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...))
Hows this for silly: my bank has a second PIN for telephone banking (three numbers) and uses identity verification if you call over the phone... but still requires 6 alpha-numeric characters for the online banking password. Absolutely silly.
Thankfully, the damage that can be done if someone was to access my account is mitigated somewhat by the 2FA that is present; whenever a "Pay Anyone" transaction is initiated, you have to confirm it with a code that is sent via SMS to your phone.
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.
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)
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.
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.
> 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.
> 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.
I use KeepassX on laptops and it's great, but the password manager use-case really falls apart on phones / tablets.
It is slow and awkward to enter a strong master password on a typical mobile device keyboard, having to shift to numeric and symbolic layouts every few characters. So slow in fact that sometimes I forgo logging-in to a service and wait until I'm back at a laptop.
I don't know what the solution is but that's one of the hurdles to wider adoption. Users just want their passwords to be available. Perhaps biometrics is part of the answer.
On the subject of length, why does seemingly every website enforce a maximum length? I tend to memorize entire sentences with punctuation and capitalization to use as passwords and it's effectively impossible for me to do this when everyone caps password length.
It kind of implies to me that whoever is storing the password has done something incredibly stupid.
Memorizing sentences means that I can just use a copy of The Bones or some other pocket reference as my password manager.
YES. Plus, this kind of integration would make it trivial to change a password, so that could literally be a one-click process in the case of a leak.
And as you say, password managers already have a fallback for sites that don't support the interface, so there would be backward compatibility as it gets adopted. (And likely it will take a long time before businesses like my bank, which requires a password of exactly 6 alphanumeric-only characters, catch on...)
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).
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?
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.
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.
>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.
Google Authenticator has TWICE gotten out of sync with my Authenticator apps, including Google's own accounts and my WordPress installs. I've had to turn it off and just resort to single-factor auth, or using stuff like Mailchimp's own app.
2FA is great in theory but it's failed twice for me and it's been a huge hassle.
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.
> 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.
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).
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.
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.
> 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.
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".
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.
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.
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.
If you can, export the secrets from the phone and import them on the new device. Of course, if the phone isn't rooted, that might be difficult.
Authy offers a cloud backup service, where they encrypt the secrets with a key derived from your password. They use PBKDF2 with only 1000 rounds, so pick a very high entropy password.
- 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.
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.
I would think that in an ideal world the old device would sign a statement indicating that the new device has full authority to act on its behalf in the future.
In a less-ideal world, it'd be nice if there were a way to sync devices without having to trust an eminently untrustworthy second party.
2-fac with Google Voice number. 2-fac Google account with normal number. Does that work? You'd have to compromise the Google account and for that you'd have to best the actual phone.
I don't actually use this but is there a good reason not to do this?
Apple's TouchID is a great example of a frictionless authentication mechanism that can be easily augmented with a password to achieve two different factors, but the reality is that isn't a lot of that out there yet.
The password safe format is quite close, it is open source, free, and works most everywhere. PasswordGorilla (https://github.com/zdia/gorilla/wiki) provides support for the format on the three major OS'es (Linux, MacOS, Windows) with the same tool, and there are several Android phone apps. that inter-operate with the format, so you could also have your passwords available on your phone as well.
Lastly, the file storage format was designed by Bruce Shiner, so there is some reasonable assurance that the design was done right due to that heritage.
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.
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.
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.
"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...
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.
> 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.
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.
I would be strongly relieved learning he failed his PhD in security: his article is a pure FUD.
Why secrets are needed? Because secrets are unpredictable and thus are the signature of a common knowledge that cannot be guessed when checked against randomness.
Every other solutions are scams especially biometry:
- measure can fail;
- if something can be measured it can be captured/duplicated.
Security market is based on fear.
I so wished security efficiency was audited based on the number of security holes they cause sometimes.
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.
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.
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?
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.
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.
Abstract:
The SQRL system (pronounced “squirrel”) revolutionizes
web site login and authentication. It eliminates many
problems inherent in traditional login techniques.
"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?
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!