&ldquo;thereisnofatebutwhatwemake&rdquo;—Turbo-charged cracking comes to long passwor

Generally, security measures are both social and technological systems, so most security can never rise to the level of being perfectly secure. Whenever I read articles like this, I worry for a moment, then I realize that there's nothing here on what kinds of systems are most likely threatened. I'm not about to go change my facebook password after reading this, but if I had a database with banking account numbers, I'd be freaking out a little bit.

Security through obscurity is the difference between having your laptop in the trunk of your car and having it on the front seat. Certainly not foolproof but greatly reduces the odds.

Yep. When I decided to tighten up my personal password policy a couple of years ago, the only institutions I had problems with was Capital One (credit cards), US Bank (mortgage), and Fidelity (investments). Guess which accounts were the ones I care most to have secured...

If I recall, Capital One doesn't allow special characters, US Bank has a low character limit (11 I think?), and Fidelity doesn't allow special characters. If that link above is true, then that means Fidelity also stores them plaintext somewhere.

And if you are uncomfortable using a password manager, you could also try visiting passwordcard.org. This is a site that lets you print up a credit card sized image of random characters. You can then just use this to create and remember your arbitrarily long, completely random passwords instead of using software. It is completely safe (the passwordcard.org site merely generates an image of random characters with no idea who you are and how you will use them - and anyone physically stealing your password card is in no position to use it themselves because you mentally "unlock" the card by knowing which pattern of characters to use for which site).

In some ways it is more annoying than a password manager because you have to type your passwords in by hand (and they can get long and weird). On the other hand, it can be less annoying than a password manager because there is no software to deal with. You merely carry around written down (but very very obfuscated) purely random character passwords in your wallet.

It is what I have been using for a while and it seems like a great solution for those who want strong passwords but don't want (or cannot use) a password manager.

How about if you could combine this with a QR reader? I would have a piece of paper in my wallet with a QR code. When I scan it with my phone, I thereby automatically log into the password manager on my phone, and the desktop client of the password manager is also automatically logged in, because my phone sends an activation code through the network. Then you have something like a wireless "key". The activation code could be a one-time code every time generated by the password manager: I don't need to see it. I only use the QR code. That could be nice, couldn't it?

Your QR code becomes the master key. This is much more convenient than writing down a 40-60 character password on a post-it note, while keeping a similar level of security.

You must assume that the connection between your phone and your desktop is secure, for that to happen you do not need to invent something new, private/public key pairs works perfectly fine and are mature enough for us to rely on.

The part of the key pair stored on your phone would be encrypted using the passphrase on your QR code, meaning that the only way for the phone to authenticate itself against your desktop would be to decrypt its own part.

As has been mentioned before: If you are not afraid of someone making a physical attempt at breaking your security solution but only tires to access your secrets from remote then this works fine.

I'm late to this thread... but it seems like the shotgun approach to passwords is currently the best way:

#1 Use a password manager application like keepass/1password to use a different and truly random passwords for every site.

#2 For a few key passwords (such as the 1password password), us a combination of memorable password methods and combine them together.

Random, but memorable word grouping: "piranhas and cats are best friends" combined with an acronym/character substitution "t1@fhq" for "this is a famous historical quote" combined with a second random word grouping with separators: "cheese-for-goats" Then smash all these passwords together with a random separator and your favorite number for good measure:

piranhasandcatsarebestfriends**cheese-for-goats**t1@fhq**42

Each individual piece of this password is easily memorable and could probably be easily defeated, but combined together I think they would challenge any of the cracking approaches detailed in recent articles... for now.

I know what you mean. It's completely absurd and a leftover, I think, from the days when everyone used the phone to manage their accounts. Converting passwords into numerical passwords (I.e. the letters a, b, and c all become "1", d, e, and f become "2" and so on) lets them have their clients just type a "password" on the keypad of their phones when in actuality they are just entering a pin.

I have no idea what methods fidelity uses to protect its passwords, but if they use a weak algorithm then it would be trivially easy to break even the longest password their system can support using middle of the road components. It is a contributing factor to why I left them (though vanguard may not be any better - I honestly haven't taken the time to investigate)

I know what you mean. It's completely absurd and a leftover, I think, from the days when everyone used the phone to manage their accounts. Converting passwords into numerical passwords (I.e. the letters a, b, and c all become "1", d, e, and f become "2" and so on) lets them have their clients just type a "password" on the keypad of their phones when in actuality they are just entering a pin.

I have no idea what methods fidelity uses to protect its passwords, but if they use a weak algorithm then it would be trivially easy to break even the longest password their system can support using middle of the road components. It is a contributing factor to why I left them (though vanguard may not be any better - I honestly haven't taken the time to investigate)

What's interesting to me is that people may decide to move from Fidelity to _____ because of Fidelity's password structure. But even if _______ has better seeming passwords, they could in fact have worse security. It's waaaay more complicated than just what password they let you enter. But, don't get me wrong, I've got no further insight than simply identifying the quandry.

I know what you mean. It's completely absurd and a leftover, I think, from the days when everyone used the phone to manage their accounts. Converting passwords into numerical passwords (I.e. the letters a, b, and c all become "1", d, e, and f become "2" and so on) lets them have their clients just type a "password" on the keypad of their phones when in actuality they are just entering a pin.

I have no idea what methods fidelity uses to protect its passwords, but if they use a weak algorithm then it would be trivially easy to break even the longest password their system can support using middle of the road components. It is a contributing factor to why I left them (though vanguard may not be any better - I honestly haven't taken the time to investigate)

What's interesting to me is that people may decide to move from Fidelity to _____ because of Fidelity's password structure. But even if _______ has better seeming passwords, they could in fact have worse security. It's waaaay more complicated than just what password they let you enter. But, don't get me wrong, I've got no further insight than simply identifying the quandry.

You are, of course, absolutely correct. I moved away from Fidelity for financial reasons unrelated to their security model (which I only really found out about as I was switching away). I have no idea if my new brokerage is any better or more secure (they might allow 200 character passwords but store them in plain text for example). But the takeaway for me is that Fidelity (along with many others I am sure) has what appears on the face of it a lousy password system.

Generally, security measures are both social and technological systems, so most security can never rise to the level of being perfectly secure. Whenever I read articles like this, I worry for a moment, then I realize that there's nothing here on what kinds of systems are most likely threatened. I'm not about to go change my facebook password after reading this, but if I had a database with banking account numbers, I'd be freaking out a little bit.

Security through obscurity is the difference between having your laptop in the trunk of your car and having it on the front seat. Certainly not foolproof but greatly reduces the odds.

Even that's a bit too simplistic; security through obscurity can be more like putting the laptop in the trunk and forgetting that your trunk doesn't actually lock, so anyone that tries your trunk could find it anyway.

This is exactly the kind of issue you face with security through obscurity; for example, if a web-site uses a single pass of MD5 to hash passwords. At a glance this looks just as secure as passwords hashed using MD5 10,000 times, but all it takes is for an attacker to try single-pass MD5 or find out that that's what is being used and that data is compromised.It's worth remembering as well that a lot of issues recently have been password hashes exposed to a wide audience, so these algorithms need to withstand multiple different efforts to break them; if your security relies only on someone not guessing a particular detail then it's doomed.

Of course in theory you could guess the key used for things like AES on your first try, but this isn't really a weakness with the algorithm, as the algorithm relies on the statistical improbability of this to protect your data. This known factor is also why AES is considered secure compared to unknown mechanisms that might be better; it's so well known how it works and it's been analysed by so many people, and still the fastest way to brute force a properly implemented AES system where you have no access to the key is to run through all possible keys. There are other attacks of course, but most of these rely on exposing the key from wherever it is being stored, or the password used to generate that key, or on non-standard implementation details of AES; a while ago several non-standard AES implementations used a lower number of rounds for speed, but ended up severely weakening the security it offered in the process.

And if you are uncomfortable using a password manager, you could also try visiting passwordcard.org. This is a site that lets you print up a credit card sized image of random characters. You can then just use this to create and remember your arbitrarily long, completely random passwords instead of using software. It is completely safe (the passwordcard.org site merely generates an image of random characters with no idea who you are and how you will use them - and anyone physically stealing your password card is in no position to use it themselves because you mentally "unlock" the card by knowing which pattern of characters to use for which site).

In some ways it is more annoying than a password manager because you have to type your passwords in by hand (and they can get long and weird). On the other hand, it can be less annoying than a password manager because there is no software to deal with. You merely carry around written down (but very very obfuscated) purely random character passwords in your wallet.

It is what I have been using for a while and it seems like a great solution for those who want strong passwords but don't want (or cannot use) a password manager.

How about if you could combine this with a QR reader? I would have a piece of paper in my wallet with a QR code. When I scan it with my phone, I thereby automatically log into the password manager on my phone, and the desktop client of the password manager is also automatically logged in, because my phone sends an activation code through the network. Then you have something like a wireless "key". The activation code could be a one-time code every time generated by the password manager: I don't need to see it. I only use the QR code. That could be nice, couldn't it?

Your QR code becomes the master key. This is much more convenient than writing down a 40-60 character password on a post-it note, while keeping a similar level of security.

You must assume that the connection between your phone and your desktop is secure, for that to happen you do not need to invent something new, private/public key pairs works perfectly fine and are mature enough for us to rely on.

The part of the key pair stored on your phone would be encrypted using the passphrase on your QR code, meaning that the only way for the phone to authenticate itself against your desktop would be to decrypt its own part.

As has been mentioned before: If you are not afraid of someone making a physical attempt at breaking your security solution but only tires to access your secrets from remote then this works fine.

Exactly. You could use a separate device instead of the phone and QR code. The device would send a one-time code to the password manager if you type in the correct, short pin code on the device.

After three failed attempts, it locks up for an hour and sends you an e-mail and a text message, "three failed attempts". The device would be made such that opening it destroys it: if its internal sensor detects that the vacuum inside its metal case has been breached (in as much as a vacuum can be "breached"...), it erases itself immediately.

As far as this specific change I'm not sure how it affects xkcd or correcthorsebatterystaple. There still isn't going to be anyone cracking that by brute force because it is still far to long for that to be computationally practical. The question is does hashcat now allow you to find that from combining 4 dictionary words together where it didn't before or was it already able to crack it from dictionaries because it only considered it 4 entries long. That I'm not sure of. If it wasn't able to before and is able to now then it would weaken the strength of these types of pass phrases.

The point of the many articles recently on this subject is that no one will ever need to brute force any variation on "correcthorsebatterystaple" because it's in the password hacking dictionary. Any pass phrase that is written down on the internet, whether xkcd comic, movie quote, or biblical passage, is inherently less secure than a random (even lightly pseudo-random) pass phrase of similar length.

That's not what was being asked. It was being asked that if you follow the advice of that xkcd article (use 4+ largeish words together that don't make sense going together like variablespeedcornmuffinwidowmaker) will the advances described in this article work on that method?

It was being asked that if you follow the advice of that xkcd article (use 4+ largeish words together that don't make sense going together like variablespeedcornmuffinwidowmaker) will the advances described in this article work on that method?

Even that is a bad idea, because brute-force programs are smart. They go through several steps to grab low-hanging fruit before doing normal brute forcing.

I'm sure someone already made up a nice hashtable of billions of combination of dictionary WORDS, regardless of whether they are part of a well-known quote or not; with spaces; without spaces; with dashes; with periods; with commas; with numbers at the ends; etc.

Its true that phrases made up of unrelated words would be practically impossible to just straight brute-force. But that's not what happens anymore. It becomes quite fast to match a hash if someone has thought of that phrase pattern/scheme and prepared a hashtable ahead of time.

Maybe you have some unique misspelling or character-substitution patterns thrown in that the person preparing the hashtables overlooked. But don't count on that. Everyone knows people substitute "3" for "e" and "@" for "a" etc. It's likely that many of those combinations will be in hashtables.

You know SETI@Home and Folding@Home? There are communities that do distributing rainbow-table generation too. Essentially "Hashing@Home", for lack of a better term...

It was being asked that if you follow the advice of that xkcd article (use 4+ largeish words together that don't make sense going together like variablespeedcornmuffinwidowmaker) will the advances described in this article work on that method?

Even that is a bad idea, because brute-force programs are smart. They go through several steps to grab low-hanging fruit before doing normal brute forcing.

I'm sure someone already made up a nice hashtable of billions of combination of dictionary WORDS, regardless of whether they are part of a well-known quote or not; with spaces; without spaces; with dashes; with periods; with commas; with numbers at the ends; etc.

Its true that phrases made up of unrelated words would be practically impossible to just straight brute-force. But that's not what happens anymore. It becomes quite fast to match a hash if someone has thought of that phrase pattern/scheme and prepared a hashtable ahead of time.

Maybe you have some unique misspelling or character-substitution patterns thrown in that the person preparing the hashtables overlooked. But don't count on that. Everyone knows people substitute "3" for "e" and "@" for "a" etc. It's likely that many of those combinations will be in hashtables.

You know SETI@Home and Folding@Home? There are communities that do distributing rainbow-table generation too. Essentially "Hashing@Home", for lack of a better term...

Let me be clear before I launch into this that I have no idea what I am talking about and that my math skills are seriously rusty. So I may be completely off here and would welcome anyone who can correct me to chime right in.

That said, let's look at the password: "variablespeedcornmuffinwidowmaker"

I immediately notice two things about this password. First, it appears to be a combination of three two-word pairs: variable-speed, corn-muffin, widow-maker. I also notice that, outside of these patterns, there is no other discernible pattern that one could make use of when building a cracking algorithm.

Ok, some math then. For this first pass, let's assume that the two word pairs don't matter and that each of the six words is completely randomly chosen vis-a-vis the others. Looking them up in a dictionary of the 5000 most used English words, I find that they come in at this frequency:

Let's assume that had we used a 5001 word dictionary that we would also have captured muffin. So, muffin = 5001.

Randomly selecting combinations from this dictionary (and somehow knowing in advance that the passphrase is six words long) I get the following from a brute force attack:

5001^6 possible combinations (or 1.564e+22 possible combinations)

Since we are randomly picking words, we should expect to land on the correct pattern about half way through on average. So that would be 7.8219e+21 attempts before the password is cracked (on average). Assuming a machine that can do 8 Billion attempts per second, we are looking at a little over 31,000 years before breaking the pass phrase (on average).

But if we use the frequency of each word to control how soon we test for it (and here is where my math starts to get REALLY fuzzy) I *think* we just multiply the ordinal positions of each word (ordinal as in its position in the above dictionary). That would give us:

1881 * 3605 * 2475 * 5001 * 4756 * 2369

or

9.4566e+20 possible combinations. We don't do the average this time because we are going in order. So the total time to crack this password under these conditions is a little over 3,700 years.

Ok, so now let's consider the fact that these really aren't six random words, but rather 3 random, two-word phrases. My math is just getting on shakier and shakier ground here but like a fool I'll just keep going on. Again, I am happy to be corrected so shout out if you wish.

Let's use the first word from each two word pair and see how long that would hold up. Using our dictionary ordinals we get:

1881 * 2475 * 4756

or just over 22 Billion combinations.

This next part is quite unscientific, but I googled each of these words: variable, corn, and widow. In each of the cases, once I entered the first letter of the second word (i.e. "s" for speed, "m" for muffin, and "m" for maker) the second word of the pair showed up anywhere between the first suggestion and the fifth suggestion. So let's be optimistic and say that once a machine checks "variable" it will also check "variablespeed" within 5 tries. The same for cornmuffin and widowmaker. So that means we need to multiply our 22 Billion by 5^3. (This is all getting very guessy on my part).

So we get about 2.8 Trillion possible combinations (or .097 hours).

So, conclusions:

If you have a very smart cracking algorithm that can test for common word combinations like "cornmuffin" and not just "corn" followed by a random "muffin" then you wind up with a fairly long passphrase that doesn't actually offer that much security. But this is because there are really on three random parts to this particular passphrase. If the original passphrase had been something like: "variablecheesecornsqualidwidowpaint" then things would have gotten much better. This phrase could be generated by using the Diceware method and then you would be looking at thousands of years to crack.

And specifically to your point that these phrases would be pre-computed and stored in a table somewhere (even distributed) is shown to be impractical. Even limiting yourself to the 5000 most commonly used english words AND assuming that you only store 6 word combinations, you would be storing: 15,625,000,000,000,000,000,000 combinations on disk (or disks)! And to little advantage. The time it would take to access the individual phrase would be much longer than to just calculate it on the fly and test it.

So it would seem to me (assuming that I haven't made some huge blunder) that atatassault (and XKCD) generally has it correct (if atatassault had stayed away from two-word combinations). Diceware - if the stupid website accepts it - works as long as it is truly random.

As you point out, you'd need to make it a bit more random than that for a computer. But as a side note, I took the variable speed cornmuffin part from a webcomic, Order of the Stick, because the phrase itself is random in human terms. Shifting the words around such that they aren't paired (variablecornwidowspeedmakermuffin) would be far harder.

You'd have to make hashtables that are impractically large to cover all passwords that are just X number of random words tossed together. The Merriam-Webster dictionary has 165,000 words; A hashtable of all the 6 word pairs would be 2.018 x 10^31 entries large (and then multiply that by the average word length); Brute forcing it would be easier (since I doubt you could muster 20 million trillion terabytes of storage), but easier in this case is still long: Each letter has about 1.76 bits of entropy, variablecornwidowspeedmakermuffin has 33 letters, so that's about 58 bits of entropy, or 2.88 x 10^17 different combinations.

As you point out, you'd need to make it a bit more random than that for a computer. But as a side note, I took the variable speed cornmuffin part from a webcomic, Order of the Stick, because the phrase itself is random in human terms. Shifting the words around such that they aren't paired (variablecornwidowspeedmakermuffin) would be far harder.

You'd have to make hashtables that are impractically large to cover all passwords that are just X number of random words tossed together. The Merriam-Webster dictionary has 165,000 words; A hashtable of all the 6 word pairs would be 2.018 x 10^31 entries large (and then multiply that by the average word length); Brute forcing it would be easier (since I doubt you could muster 20 million trillion terabytes of storage), but easier in this case is still long: Each letter has about 1.76 bits of entropy, variablecornwidowspeedmakermuffin has 33 letters, so that's about 58 bits of entropy, or 2.88 x 10^17 different combinations.

Huh. That's interesting. It never even occurred to me that it could be faster to brute force the letters than entire words. Of course that only applies if you use words that aren't covered in a smaller dictionary. But even if you stick to words in the top five thousand (like in your second example - not from the comic) you are still very secure. It goes to show how vital randomness is.

Yeah, all of this is only true as long as nobody is able to discover a secondary, inherent weakness in the crypto. Guessing the password, if it is a weak password, is the best way to break into an encrypted system these days (as far as I know). It's a bit like a safe with ten thousand foot thick walls. The only practical way to get into it is by attacking the combination lock (the password). But if one of those mathematicians at the NSA (or anywhere else) managed to discover an inherent flaw in the cryptographic algorithm itself then suddenly we find that the safe may have walls made of butter. Ten thousand foot thick butter walls would mean that password complexity suddenly becomes meaningless.

Can't we just invent a hashing algorithm that takes a relatively long time to crack so this method becomes very close to unusable? Or is the disparity between a public school grade computer and a hacker's supercomputer too large (at least a factor of 300)

Can't we just invent a hashing algorithm that takes a relatively long time to crack so this method becomes very close to unusable? Or is the disparity between a public school grade computer and a hacker's supercomputer too large (at least a factor of 300)

There are already hashing algorithms out there that are computationally more expensive and, as such, mean that you cannot process the 8 Billion or so hashes a second that the easiest ones allow. I think that some of these algorithms are so expensive that the best these high end cracking machines can manage is several hundred thousand guesses a second. That would mean that even a relatively weak password is inherently safe.

So the fact is that these algorithms already exist (and a few websites are wise enough to use them). The issue is that there are website administrators who are lazy (or uninformed) and do not use these algorithms.

Since we, as end users, have no control over what hashing algorithm these sites use, we have to assume the worst and take preventative measures.

1) Choose a relatively long random password so that even if the website uses a poor password hashing method it will still take impossibly long to crack your password.

2) Use unique passwords per site (or at least important sites) so that even if a website is bold enough to store your password in plain text, none of your other accounts are vulnerable if this site is hacked.

I am confused... Even at 8 billion guesses a second it would still take 1.7 x 10 ^ 58 HOURS to crack a 40 character alpha numeric string. That is secure as hell...

Manually hash your password. And use the hash as the password. Then the site will re-hash your hash and you have a huge alphanum password.

Nothing to be confused about. You are absolutely correct. A forty character password is extremely secure.

As long as it is sufficiently random.

If your forty characters are based on a quote or song lyric or made up of a permutation of the word "password" or use a common sentence with l33tsp3ak... or basically isn't random enough then the length doesn't necessarily protect you.

Manually hashing the password yourself, as long as you use a proper algorithm, could add some security. But if your original password is "password" (or some other weak password) then it is only marginally safer. Many cracking systems will try multiple hashes layered on top of each other. So if the web site had hashed your password fifteen times, and you do it once yourself, it has now been hashed sixteen times. If the cracking software tries a sixteen pass hash and your original password is so simple that it is one of the guesses that the software is designed to make, your password falls.

Also, as we have seen, there is no point to doing that. It is nearly impossible to remember the hashed characters and if the site can accept a password as long as a hash, you are better off (and as secure) using diceware.

Again, I want to point out that I am no expert on any of this. This is just what I have learned reading about this subject and, as such, might have some of the details wrong. Keep that in mind and feel free to correct me if I have made a mistake.

Manually hashing the password yourself, as long as you use a proper algorithm, could add some security. But if your original password is "password" (or some other weak password) then it is only marginally safer. Many cracking systems will try multiple hashes layered on top of each other. So if the web site had hashed your password fifteen times, and you do it once yourself, it has now been hashed sixteen times. If the cracking software tries a sixteen pass hash and your original password is so simple that it is one of the guesses that the software is designed to make, your password falls.

Also, as we have seen, there is no point to doing that. It is nearly impossible to remember the hashed characters and if the site can accept a password as long as a hash, you are better off (and as secure) using diceware.

Again, I want to point out that I am no expert on any of this. This is just what I have learned reading about this subject and, as such, might have some of the details wrong. Keep that in mind and feel free to correct me if I have made a mistake.

I think you are mostly right about manually hashing, at least in theory. In practice, however, if your password is not the first to be cracked, or if the hackers know the hashing algorithm that the password database uses, they will most probably not try another hash at your password, unless perhaps the database is tiny or they know there is an extremely valuable password in there. So in practice I think a manual hash is in most cases probably almost as good as a random string.

But still, I don't see the point in using a manual hash, because, as you say, a random string is just as hard/easy to remember and always more secure; even if it is no more secure in most common situations, it is certainly no *less* secure, and there is little advantage to using a manual hash. The only one I could think of is that you can reproduce the string resulting from the manual hash if you've lost it, by using a hashing program on your underlying password on some other computer; this is not possible with an arbitrary string. But that seems a fairly small advantage to me.

As far as this specific change I'm not sure how it affects xkcd or correcthorsebatterystaple. There still isn't going to be anyone cracking that by brute force because it is still far to long for that to be computationally practical. The question is does hashcat now allow you to find that from combining 4 dictionary words together where it didn't before or was it already able to crack it from dictionaries because it only considered it 4 entries long. That I'm not sure of. If it wasn't able to before and is able to now then it would weaken the strength of these types of pass phrases.

The point of the many articles recently on this subject is that no one will ever need to brute force any variation on "correcthorsebatterystaple" because it's in the password hacking dictionary. Any pass phrase that is written down on the internet, whether xkcd comic, movie quote, or biblical passage, is inherently less secure than a random (even lightly pseudo-random) pass phrase of similar length.

That's not what was being asked. It was being asked that if you follow the advice of that xkcd article (use 4+ largeish words together that don't make sense going together like variablespeedcornmuffinwidowmaker) will the advances described in this article work on that method?

Some excellent replies above, but since you responded to my post, I figured I'd do the same. Hacking password programs like hashcat are primarily useful to accelerate dictionary based cracks. The apparent progress made here is to allow longer dictionary entries. If your password cannot be derived from the dictionary being applied, then no, this advance does not help.

And you're also right, I didn't directly respond to the original poster's concern (though I don't think you got it exactly right either, I think you took it a step farther than he intended). He is asking specifically about correcthorsebatterystaple.

To answer his question directly, yes, it can now guess that password directly because the dictionary entry can be that long (and that will definitely be in the dictionary). However, I don't know if it could have guessed it easily from the 4 sub-words previous to this latest update. According to the article, guesses longer than 15 characters weren't even allowed, so that would mean that no, it could never have guessed correcthorsebatterystaple. In any case, I think that concern was addressed with the above discussion -- combining words opens a whole lot more options than combining letters per position (4 letter password has way fewer options than 4 words passwords) (obviously).

All of a sudden, fingerprint reading touch screen makes much more sense than just couple of months ago, Now let's wait for Apple keynote if it becomes reality

Please, everyone that reads this, never ever ever ever hint, imply, suggest, or otherwise encourage the use of biometrics (fingerprints) as an authentication factor. If you think it's hard to change your password everywhere when there's a breach, just imagine how much harder it would be to get your finger changed too.

...uh, by using a password manager... like several of us have been suggesting. Would've thought that'd be pretty obvious by now.

I suppose that would work but I have to wonder why, if you are using a password manager, you wouldn't just let it pick a purely random password of equal length for you. Sounds like doing this would yield a password that is less secure but still requires you to install and manage (and most likely pay for) additional software which you then basically circumvent its best feature.

...uh, by using a password manager... like several of us have been suggesting. Would've thought that'd be pretty obvious by now.

I suppose that would work but I have to wonder why, if you are using a password manager, you wouldn't just let it pick a purely random password of equal length for you. Sounds like doing this would yield a password that is less secure but still requires you to install and manage (and most likely pay for) additional software which you then basically circumvent its best feature.

Well obviously if you're using a password manager the preference is to let the password manager generate a random password for you. I was just answering the question of how one would remember a hashed password.

Salt is mostly a defense against rainbow tables not brute force hashing. Though in the later case it does mean each one has to be attacked individually instead of working on the whole list at the same time. While your scheme is better than storing the plaintext or omitting salt, it is still very weak. .

Honest question here: If you are hashing with a salt which is 15 characters, completely random and not found in any dictionary, how can this be cracked realistically with current compute power? I was under the impression a pure brute force attack could realistically do perhaps 10 characters. The you need rainbow tables, dictionary attacks, markov chains etc to get you beyond 10 characters or whatever is feasible now.I assumed salts are cracked where the salt is short and there is a very weak and short password to work with, for example one hash will be comprised of a password 123456 which is hashed with a short salt. What am I missing?

Salt is mostly a defense against rainbow tables not brute force hashing. Though in the later case it does mean each one has to be attacked individually instead of working on the whole list at the same time. While your scheme is better than storing the plaintext or omitting salt, it is still very weak. .

Honest question here: If you are hashing with a salt which is 15 characters, completely random and not found in any dictionary, how can this be cracked realistically with current compute power? I was under the impression a pure brute force attack could realistically do perhaps 10 characters. The you need rainbow tables, dictionary attacks, markov chains etc to get you beyond 10 characters or whatever is feasible now.I assumed salts are cracked where the salt is short and there is a very weak and short password to work with, for example one hash will be comprised of a password 123456 which is hashed with a short salt. What am I missing?

The hashes and the salts are stored together. So a cracker working on a hash table also has the salts.

If the cracker is trying 123456, all the salts do is stop him from computing hash(123456) once and comparing to all hashes in the table. Instead, the cracker has to compute hash(123456+salt1) and compare that against hash1, then compute hash(123456+salt2) and compare that against hash2.

Thanks for your reply Chuckstar. I'm guessing you are talking about people storing unencrypted salts with the hashes, surely no one does that?! Seems as you say largely useless. This really good article http://arstechnica.com/security/2013/05 ... sswords/2/ suggests salts are not typically stored in these hash tables and I think the post I originally queried was working on the assumption that this was not the case. You would create a single salt which is stored separately in your auth file or elsewhere. So if we did take a scenario where the hacker had the full tables of hashes computed on the combined password and salt but did not have the salt which was 15 genuinely random characters, could they crack any passwords?

Salt is generally stored with the hashes, as is not considered secret. What you are talking about -- a secret, global, hash parameter -- is not usually considered salt, but instead pepper. It isn't considered best practice to use pepper instead of salt. Among other reasons, because if the attacker gets the hash database, the prior on him compromising the 'secret' addition goes way up.

[quote="Faramir"][/quote]Thanks for the response and link Faramir, it's very helpful being able to freely ask questions especially if they turn out to be flawed, good way to learn. Glad to have the salt pepper difference pointed out. The article though is not especially compelling, if nothing else the pepper does offer protection from a partial compromise, i.e. the hash table is leaked but the OS remains secure. Well actually that is really what I'm trying to get to, assuming the pepper was not discovered, is it save to assume those hashes are realistically secure if the pepper is 15 random characters. So the answer might be yes, yes but, no...Also with that article and the use of encryption, if the server was compromised, would they not simply have access to the AES secret as apposed to the pepper? The second flaw it points out has me scratching my head, no idea how concatenating a salt and pepper to effectively get a longer salt affects the security of the algorithm.

The problem is that if the attacker gets access to the pepper all of the hashes become that much weaker. Whereas with salt, it is not secret at all. The security model assumes that the salt is stored with the hashes (and indeed it usually is).

What salt does is it makes each hash a completely separate problem to solve, whereas unhashed or hashed with known pepper, you can attack all the hashes at once. Indeed you will get the same hash from the same password, so you can uncover some passwords by simply looking for collisions (check out the adobe article[1] for a similar problem that occurred because adobe encrypted their passwords instead of hashing with unique salt).

It is true that a very weak password could be cracked even if it was salted and even if you used a good key derivation function. If your password is 'password' it may well be the first one they try! But on the other hand, protecting that isn't worth very much. They can always just try logging if the user has such a weak password.

Although I don't see how salt + pepper could directly weaken the security gurentee, I can certainly see how it would indirectly if it lead more people to roll their own. That's a disaster waiting to happen.

Thanks for the response and link Faramir, it's very helpful being able to freely ask questions especially if they turn out to be flawed, good way to learn. Glad to have the salt pepper difference pointed out. The article though is not especially compelling, if nothing else the pepper does offer protection from a partial compromise, i.e. the hash table is leaked but the OS remains secure. Well actually that is really what I'm trying to get to, assuming the pepper was not discovered, is it save to assume those hashes are realistically secure if the pepper is 15 random characters. So the answer might be yes, yes but, no...Also with that article and the use of encryption, if the server was compromised, would they not simply have access to the AES secret as apposed to the pepper? The second flaw it points out has me scratching my head, no idea how concatenating a salt and pepper to effectively get a longer salt affects the security of the algorithm.

The concept of a partial compromise of a system is not one that's generally considered important to protect against. Generally, if someone's in the system, they're in the system. The rule is to make the system as secure as possible/practical considering that someone getting the hashes will get every other piece of information they need. Certainly, you wouldn't want a system that relies on someone only getting partial information in order to be secure.

In other words, you could separate the hashes and the salts/pepper in the hope someone might not get both, but don't design the system to rely on someone not getting both. Then once you've decided it has to be secure even if they get everything, then maybe you can just make the system a whole lot simpler by getting rid of that separation. Simpler is a key security concept, as well, since complexity breeds unanticipated holes.

[quote="Chuckstar"][/quote]Guys, thanks for your replies. As I read more it's pretty clear that there is no one common view on these things. I see even an Ars Technica review of password management policy by industry experts offer a widely different approach between expert. For my part I agree with the defence in depth approach and keeping it simple. I tried to get some more info on breakdown of compromises and found this http://hackmageddon.com/2012-cyber-atta ... /#December, which would confirm my suspicion that injection attacks are a significant attack type, which I read as being someone getting just the DB rather than access to the server itself.So, if something is going to add another headache/hurdle for a hacker without exposing another attack vector either physical or through human error due to management overhead, then why not. In that regard either using hidden salts or a pepper (with clear salts) both seem like good options. The biggest issue I do see with a pepper is if you do need to change it then you have to get everyone to reset their passwords, so in this sense a hidden salt is better.