Password Security: Why the horse battery staple is not correct
diogomonica.com
diogomonica.com
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).
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.
CHBS is a method for generating passwords, not choosing them.
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.
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.
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.
But honestly, I mostly just thought the inconsistency between your two figures was amusing.
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.
https://www.schneier.com/blog/archives/2005/06/write_down_yo...
Still may or may not be acceptable, depending on context.
Based on what? I've seen absolutely no evidence that good password managers (1Passoword and its ilk) are insecure.
The article did stem from me reading blogposts where people were interpreting the XKCD comic into: just chose four words instead of one password.
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.
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.
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).
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.
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.
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 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.
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...)
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.
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.
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.
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.
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).
[2] https://www.schneier.com/blog/archives/2014/03/choosing_secu...
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?
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.
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.
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.
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).
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
Maybe I'm barking up the wrong tree and the marketing or brand awareness of LastPass and 1Password is much higher than I suspect.
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.
For example, the day iOS 8 came out, 1Password had an extension so that Mobile Safari could fill in my passwords.
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.
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?
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.
> 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.
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.
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.
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.
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?
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.
... 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?