Cisco switches to weaker hashing scheme, passwords cracked wide open

Crypto technique requires little time and computing resources to crack.

Password cracking experts have reversed a secret cryptographic formula recently added to Cisco devices. Ironically, the encryption type 4 algorithm leaves users considerably more susceptible to password cracking than an older alternative, even though the new routine was intended to enhance protections already in place.

It turns out that Cisco's new method for converting passwords into one-way hashes uses a single iteration of the SHA256 function with no cryptographic salt. The revelation came as a shock to many security experts because the technique requires little time and computing resources. As a result, relatively inexpensive computers used by crackers can try a dizzying number of guesses when attempting to guess the corresponding plain-text password. For instance, a system outfitted with two AMD Radeon 6990 graphics cards that run a soon-to-be-released version of the Hashcat password cracking program can cycle through more than 2.8 billion candidate passwords each second.

By contrast, the type 5 algorithm the new scheme was intended to replace used 1,000 iterations of the MD5 hash function. The large number of repetitions forces cracking programs to work more slowly and makes the process more costly to attackers. Even more important, the older function added randomly generated cryptographic "salt" to each password, preventing crackers from tackling large numbers of hashes at once.

"In my eyes, for such an important company, this is a big fail," Jens Steube, the creator of ocl-Hashcat-plus said of the discovery he and beta tester Philipp Schmidt made last week. "Nowadays everyone in the security/crypto/hash scene knows that password hashes should be salted, at least. By not salting the hashes we can crack all the hashes at once with full speed."

Cisco officials acknowledged the password weakness in an advisory published Monday. The bulletin didn't specify the specific Cisco products that use the new algorithm except to say that they ran "Cisco IOS and Cisco IOS XE releases based on the Cisco IOS 15 code base." It warned that devices that support Type 4 passwords lose the capacity to create more secure Type 5 passwords. It also said "backward compatibility problems may arise when downgrading from a device running" the latest version.

"Due to an implementation issue, the Type 4 password algorithm does not use PBKDF2 and does not use a salt, but instead performs a single iteration of SHA256 over the user-provided plaintext password," the Cisco advisory stated. "This approach causes a Type 4 password to be less resilient to brute-force attacks than a Type 5 password of equivalent complexity."

The weakness threatens anyone whose router configuration data may be exposed in an online breach. Rather than store passwords in clear text, the algorithm is intended to store passwords as a one-way hash that can only be reversed by guessing the plaintext that generated it. The risk is exacerbated by the growing practice of including configuration data in online forums. Steube found the hash "luSeObEBqS7m7Ux97dU4qPfW4iArF8KZI2sQnuwGcoU" posted here and had little trouble cracking it. (Ars isn't publishing the password in case it's still being used to secure the Cisco gear.)

While Steube and Schmidt reversed the Type 4 scheme, word of the weakness they uncovered recently leaked into other password cracking forums. An e-mail posted on Saturday to a group dedicated to the John the Ripper password cracker, for instance, noted that the secret to the Type 4 password scheme "is it's base64 SHA256 with character set './0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'." Armed with this knowledge, crackers have everything they need to crack hundreds of thousands, or even millions, of hashes in a matter of hours.

It's hard to fathom an implementation error of this magnitude being discovered only after the new hashing mechanism went live. The good news is that Cisco is openly disclosing the weakness early in its life cycle. Ars strongly recommends that users consider the pros and cons before upgrading their Cisco gear.

Promoted Comments

The article states that "the older function added randomly generated cryptographic "salt" to each password, preventing crackers from tackling large numbers of hashes at once." Which I feel doesn't really get at the reason for adding salt. A salt value prevents "rainbow table"/dictionary like attacks. i.e. without a salt, you can hash common passwords beforehand and have them ready. "password" will always hash to the same value. With a salt two different users with the same password will have different hashes.

Rainbow table resistance is only a *minor* benefit of salt which protects the weakest users. It is easy to understand and it's what people remember, and in the case of Unix servers where the hashes are visible the need for this use case is obvious, but the *far more* critical use of salt in the era of GPU cracking is to prevent optimizations which permit mass parallel computation on readily available hardware.

Rainbow tables have practical limitations on size and these days you can actually get faster results with pure cracking than rainbow tables anyway.

Rainbow table resistance is only a *minor* benefit of salt which protects the weakest users. It is easy to understand and it's what people remember, and in the case of Unix servers where the hashes are visible the need for this use case is obvious, but the *far more* critical use of salt in the era of GPU cracking is to prevent optimizations which permit mass parallel computation on readily available hardware.

Rainbow tables have practical limitations on size and these days you can actually get faster results with pure cracking than rainbow tables anyway.

How do salts appreciably slow down brute force cracking a single password? You can hash many password guesses along with the salt in roughly the same time that you can hash many password guesses.

GPUs are really, really good at doing this: aaa, aab, aac, aad, aae... ... zzz. They can do it vastly faster than a conventional CPU because of their parallel operation design.

If you have a hundred thousand unsalted hashes to crack, you can just start at aaa and compare every calculated hash to the set of a hundred thousand.

If you have a hundred thousand salted hashes, each one has a large, unique prefix and will be the ONLY password to be found within the aaa ... zzz search space underneath that prefix. (If you take the aaa zzz thing literally I will beat you into a pulsating mass of sorrow with a cluebat. You know I mean the space of all possible passwords.) This slows down the parallelization because it must be redone for each hash. It's still faster than conventional CPU cracking but nowhere near as fast as unsalted gpu cracking.

It is nice if the attackers do not have the salt, but it's considered within the threat model that they probably do. They still work to slow down the process.

What is prenventing the use of custom hashing algorytms which aren't divulged to the public?. Couldn't they add a layer of obscurity that way. Like for example the SHA-256 times an arbitrary number. I'm probably missing something...

The usual problem, if history is any guide, is that cryptography is hard, so the additional security you get by forcing your opponent to reverse-engineer your algorithm is usually considerably less than the additional vulnerability you incur by having your in-house guy who is a pretty decent coder and took a class on cryptography his senior year in college roll his own crypto system(rather than a publicly known; but designed-and-peer-reviewed by a substantial number of the world's non-clandestine cryptography specialists, algorithm).

Even the ones designed by experts often end up having vulnerabilities of varying severity discovered later; but the world is littered with the corpses of pitifully weak in-house efforts.

What is prenventing the use of custom hashing algorytms which aren't divulged to the public?. Couldn't they add a layer of obscurity that way. Like for example the SHA-256 times an arbitrary number. I'm probably missing something...

Unless you really, really know what you are doing, any standard scheme is going to be better than anything you could think of. Many years ago when I worked at Digital, there was an internal news group dedicated to security. Many employees would propose security schemes - and the company experts would, usually no later than the next day, post the methods to break it.

More to the point, when evaluating products as a strategic planner, any company that would not divulge the cryptographic methods used in the products to me or my team was instantly removed from consideration for ALL future purchases. Security by obscurity = no security.

When working in cryptography, it is assumed that an attacker has full knowledge of the algorithms used and operating processes and procedures around the use of the algorithms - and has sample plain and cypher text. Only the key is unknown. If the system remains secure under those circumstances, then you have a good system. Only a wide, public review of a proposed system is sufficient to identify potential issues.

[...] The new one, despite using the superior SHA256, only uses one iteration of it and no salt.

in terms of password storage, sha256 is not superior to md5 -- they are equally bad.

the cryptographic weaknesses of md5 have nothing to do with why md5 is a poor choice for password storage. but the reason that md5 is a poor choice for password storage has everything to do with why sha256 is a poor choice for password storage.

The article states that "the older function added randomly generated cryptographic "salt" to each password, preventing crackers from tackling large numbers of hashes at once." Which I feel doesn't really get at the reason for adding salt. A salt value prevents "rainbow table"/dictionary like attacks. i.e. without a salt, you can hash common passwords beforehand and have them ready. "password" will always hash to the same value. With a salt two different users with the same password will have different hashes.

it's both, but much more so the former.

nobody uses rainbow tables anymore since they're large in size, limited in keyspace, severely limited in flexibility, and don't scale worth a crud. gpus have completely deprecated rainbow tables, so the old rainbow tables argument for salting doesn't hold much water today.

salts certainly do not prevent dictionary attacks. i don't know where this misconception originated, but i've seen it repeated way too many times.

today's primary reason for salting is exactly as the article states: to significantly slow down attacks against multiple hashes. you are correct in stating that the same password hashed with different salts will result in different hashes. but what this means from a massively-parallel perspective is that each plaintext candidate needs to be computed with each unique salt.

let's say we have 10 hashes of some algorithm, and we can compute that algorithm at 100 MH/s. without salting, we can crack at the full 100 MH/s, since each plaintext candidate only needs to be hashed once, then compared to all 10 hashes simultaneously. now let's say we have 10 hashes with 10 unique salts. because we have to hash each plaintext candidate with each unique salt and compare each hash individually, our effective rate becomes 10 MH/s -- exactly 10 times slower.

so you can see how with larger hash lists this can have a profound effect. let's say we now have 8 million unique salts, and we can tear through this algorithm on GPU at 15 billion guesses per second. because of the salting, the effective rate against all 8 million salts becomes a mere 1875 guesses per second.

but this is only an effective defense against multiple hashes. if we have a single hash that we are focusing on that belongs to a high-value target (admin/root account, famous person, whatever) then salting alone will not help us. thus, salting alone is insufficient, so we have to use salting in conjunction with some other technique to slow down the attacker. that's where multiple iterations, memory-hardness, anti-gpu techniques, etc come into play.

Speed of the hashing algorithm is not a weakness unless you have bad passwords.

The sheer amount of energy required to break something like a strong 16 char password, would consume the Milkway and a 20char password would consume the observable Universe. But that's assuming your have a 100% efficient computer.

When in doubt, scrypt.

sorry, certainly not true.

your observable universe scenario only applies to brute force. fast algorithms provide us the bandwidth necessary to run very complex and creative attacks, enabling us to crack perfectly reasonable passwords in a perfectly reasonable amount of time.

and let's be realistic here, there is such a thing as a perfectly reasonable password. just because your password isn't random doesn't mean it's a bad password. and due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

the only way you would force me to incrementally search for a 16 character password is if you used a 16 character random password, and nobody is using 16 character random passwords. you may /say/ that you do on the forums to increase your e-peen, but statistics clearly show that 91%+ of you are not.

and while we're on the subject of realism: scrypt is a great proof of concept, but it is not something your average developer can just up and implement. don't overthink it, crypt(3) is your friend. if you're developing on windows and desperately wish you knew what crypt(3) was, shoot for pbkdf2 instead -- keeping in mind today's lessons, please. and there's lots of good bcrypt implementations out there now, too. these are what you're stuck with until we come up with a standard via the Password Hashing Competition.

77 Reader Comments

What is prenventing the use of custom hashing algorytms which aren't divulged to the public?. Couldn't they add a layer of obscurity that way. Like for example the SHA-256 times an arbitrary number. I'm probably missing something...

The usual problem, if history is any guide, is that cryptography is hard, so the additional security you get by forcing your opponent to reverse-engineer your algorithm is usually considerably less than the additional vulnerability you incur by having your in-house guy who is a pretty decent coder and took a class on cryptography his senior year in college roll his own crypto system(rather than a publicly known; but designed-and-peer-reviewed by a substantial number of the world's non-clandestine cryptography specialists, algorithm).

Even the ones designed by experts often end up having vulnerabilities of varying severity discovered later; but the world is littered with the corpses of pitifully weak in-house efforts.

What is prenventing the use of custom hashing algorytms which aren't divulged to the public?. Couldn't they add a layer of obscurity that way. Like for example the SHA-256 times an arbitrary number. I'm probably missing something...

Unless you really, really know what you are doing, any standard scheme is going to be better than anything you could think of. Many years ago when I worked at Digital, there was an internal news group dedicated to security. Many employees would propose security schemes - and the company experts would, usually no later than the next day, post the methods to break it.

More to the point, when evaluating products as a strategic planner, any company that would not divulge the cryptographic methods used in the products to me or my team was instantly removed from consideration for ALL future purchases. Security by obscurity = no security.

When working in cryptography, it is assumed that an attacker has full knowledge of the algorithms used and operating processes and procedures around the use of the algorithms - and has sample plain and cypher text. Only the key is unknown. If the system remains secure under those circumstances, then you have a good system. Only a wide, public review of a proposed system is sufficient to identify potential issues.

Well, at least the issue is limited by the fact that people use TACACS or RADIUS for AAA anyway, and local passwords are only a fallback if the remote authorization server is unreachable.

Not to mention, the fact that you have to get the hash in the first place. Though, let's face it, if you can get the hash, there's other problems in the network.

I want to agree with you, but a lot of Cisco gear is deployed without the use of RADIUS or TACACS for AAA, if for no other reason than it's hard to diagnose a router when you cannot log into it because it can't reach the RADIUS server and validate your credentials. At the SMB level you can usually guarantee they're not using RADIUS, especially at the branch office level

Someone would need to read the config to crack these passwords (eg, by compromising your CMDB or NMS), and then attack a device that isn't using RADIUS or TACACS, which is probably quite a lot of devices. I don't think a drive-by attack would be viable, but a concerted attempt to compromise a network would certainly be possible, and it's still stupid on Cisco's part.

These passwords should not be used in production networks, anyways. Local authentication should only occur in the event that the authentication server is down or unreachable (which I acknowledge is an attack vector, but still). It would require several breaches and exploits to even get to use local authentication (some of which require being on the inside of the network), but then again there is no security without physical security, anyways..

You need a copy of the router configuration, and you need the router to use local authentication, if I understand the weakness correctly.

What is prenventing the use of custom hashing algorytms which aren't divulged to the public?. Couldn't they add a layer of obscurity that way. Like for example the SHA-256 times an arbitrary number. I'm probably missing something...

That was essentially what was done here, and it took all of a few days for someone to figure out what the "secret" hashing algorithm was. Depending on secret cyphers is Napoleon-era cryptography. If you attempt to do so today you will quickly find that your obscure algorithm isn't nearly as clever as you think it is, and it will be broken almost immediately. Real cryptography relies on algorithms that still keep your data secure even if your opponent knows exactly how the algorithm works.

GPUs are really, really good at doing this: aaa, aab, aac, aad, aae... ... zzz. They can do it vastly faster than a conventional CPU because of their parallel operation design.

If you have a hundred thousand unsalted hashes to crack, you can just start at aaa and compare every calculated hash to the set of a hundred thousand.

If you have a hundred thousand salted hashes, each one has a large, unique prefix and will be the ONLY password to be found within the aaa ... zzz search space underneath that prefix. (If you take the aaa zzz thing literally I will beat you into a pulsating mass of sorrow with a cluebat. You know I mean the space of all possible passwords.) This slows down the parallelization because it must be redone for each hash. It's still faster than conventional CPU cracking but nowhere near as fast as unsalted gpu cracking.

It is nice if the attackers do not have the salt, but it's considered within the threat model that they probably do. They still work to slow down the process.

Can you give a bit more detail on why GPUs are better at this sort of operation please? Using your analogy, You're saying that there's a performance boost for running H("aaa") and H("aab") in parallel on a GPU, (where H is the hash function, in this case SHA256).

Is this because a parallel GPU implementation would compute the operations for each bit in a given block, and then use those results for all of the inputs that contain the same input bit? Presumably GPUs allow efficient sharing of this sort of data between threads, as well. Do you know what sort of speedup can be gained from sharing work in this way?

One sort of due diligence that you should do is, as a test, encrypt the password "password," and then Google the resulting hash. If ANY hits come up, there is definitely something fundamentally wrong with the encryption algorithm being used.

For example, on this hardware, that would have returned something like 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 (hex) or XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg= (base64) - both of which come up in a Google search.

This doesn't guarantee safety or security, of course (and 'password' would of course be very quickly brute-forced by dictionary-based crackers), but it does at least rule out trivial unsalted hashing.

The article states that "the older function added randomly generated cryptographic "salt" to each password, preventing crackers from tackling large numbers of hashes at once." Which I feel doesn't really get at the reason for adding salt. A salt value prevents "rainbow table"/dictionary like attacks. i.e. without a salt, you can hash common passwords beforehand and have them ready. "password" will always hash to the same value. With a salt two different users with the same password will have different hashes.

it's both, but much more so the former.

nobody uses rainbow tables anymore since they're large in size, limited in keyspace, severely limited in flexibility, and don't scale worth a crud. gpus have completely deprecated rainbow tables, so the old rainbow tables argument for salting doesn't hold much water today.

salts certainly do not prevent dictionary attacks. i don't know where this misconception originated, but i've seen it repeated way too many times.

today's primary reason for salting is exactly as the article states: to significantly slow down attacks against multiple hashes. you are correct in stating that the same password hashed with different salts will result in different hashes. but what this means from a massively-parallel perspective is that each plaintext candidate needs to be computed with each unique salt.

let's say we have 10 hashes of some algorithm, and we can compute that algorithm at 100 MH/s. without salting, we can crack at the full 100 MH/s, since each plaintext candidate only needs to be hashed once, then compared to all 10 hashes simultaneously. now let's say we have 10 hashes with 10 unique salts. because we have to hash each plaintext candidate with each unique salt and compare each hash individually, our effective rate becomes 10 MH/s -- exactly 10 times slower.

so you can see how with larger hash lists this can have a profound effect. let's say we now have 8 million unique salts, and we can tear through this algorithm on GPU at 15 billion guesses per second. because of the salting, the effective rate against all 8 million salts becomes a mere 1875 guesses per second.

but this is only an effective defense against multiple hashes. if we have a single hash that we are focusing on that belongs to a high-value target (admin/root account, famous person, whatever) then salting alone will not help us. thus, salting alone is insufficient, so we have to use salting in conjunction with some other technique to slow down the attacker. that's where multiple iterations, memory-hardness, anti-gpu techniques, etc come into play.

Someone would need to read the config to crack these passwords (eg, by compromising your CMDB or NMS), and then attack a device that isn't using RADIUS or TACACS, which is probably quite a lot of devices. I don't think a drive-by attack would be viable, but a concerted attempt to compromise a network would certainly be possible, and it's still stupid on Cisco's part.

Sorry but if they aren't running radius/tacacs, the likelyhood of them even using a cmdb/nms is even lower. Not to mention, I bet they're using Type 7 passwords anyway. I mean, those are pretty awesome, aren't they?

[...] The new one, despite using the superior SHA256, only uses one iteration of it and no salt.

in terms of password storage, sha256 is not superior to md5 -- they are equally bad.

the cryptographic weaknesses of md5 have nothing to do with why md5 is a poor choice for password storage. but the reason that md5 is a poor choice for password storage has everything to do with why sha256 is a poor choice for password storage.

GPUs are really, really good at doing this: aaa, aab, aac, aad, aae... ... zzz. They can do it vastly faster than a conventional CPU because of their parallel operation design.

If you have a hundred thousand unsalted hashes to crack, you can just start at aaa and compare every calculated hash to the set of a hundred thousand.

If you have a hundred thousand salted hashes, each one has a large, unique prefix and will be the ONLY password to be found within the aaa ... zzz search space underneath that prefix. (If you take the aaa zzz thing literally I will beat you into a pulsating mass of sorrow with a cluebat. You know I mean the space of all possible passwords.) This slows down the parallelization because it must be redone for each hash. It's still faster than conventional CPU cracking but nowhere near as fast as unsalted gpu cracking.

It is nice if the attackers do not have the salt, but it's considered within the threat model that they probably do. They still work to slow down the process.

Can you give a bit more detail on why GPUs are better at this sort of operation please? Using your analogy, You're saying that there's a performance boost for running H("aaa") and H("aab") in parallel on a GPU, (where H is the hash function, in this case SHA256).

Is this because a parallel GPU implementation would compute the operations for each bit in a given block, and then use those results for all of the inputs that contain the same input bit? Presumably GPUs allow efficient sharing of this sort of data between threads, as well. Do you know what sort of speedup can be gained from sharing work in this way?

It's more so because the GPU can do H("aaa") at the same time as H("bbb") and H("ccc") and H("ddd") and.... (many, many more). GPUs are massively parallelable beasts, and work best when all their operations are entirely independent of each other (having to share state would slow things down... it can be worth it in some circumstances, but generally not).

I admit there are screw ups, then there are SCREW UPS. This ranking up there with the ALL CAPS RAGE variety. Makes me think of how generic passwords are set so they can be remembered/easily accessed, all the while basically setting a precedence of "You got pwned" series of stupidity all over the place, especially since Cisco is so prevalent.

That dent in my forehead is not that attractive anymore and my desk is out of warranty...

[...] The new one, despite using the superior SHA256, only uses one iteration of it and no salt.

in terms of password storage, sha256 is not superior to md5 -- they are equally bad.

the cryptographic weaknesses of md5 have nothing to do with why md5 is a poor choice for password storage. but the reason that md5 is a poor choice for password storage has everything to do with why sha256 is a poor choice for password storage.

it's all about speed.

Speed of the hashing algorithm is not a weakness unless you have bad passwords.

The sheer amount of energy required to break something like a strong 16 char password, would consume the Milkway and a 20char password would consume the observable Universe. But that's assuming your have a 100% efficient computer.

Speed of the hashing algorithm is not a weakness unless you have bad passwords.

The sheer amount of energy required to break something like a strong 16 char password, would consume the Milkway and a 20char password would consume the observable Universe. But that's assuming your have a 100% efficient computer.

When in doubt, scrypt.

sorry, certainly not true.

your observable universe scenario only applies to brute force. fast algorithms provide us the bandwidth necessary to run very complex and creative attacks, enabling us to crack perfectly reasonable passwords in a perfectly reasonable amount of time.

and let's be realistic here, there is such a thing as a perfectly reasonable password. just because your password isn't random doesn't mean it's a bad password. and due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

the only way you would force me to incrementally search for a 16 character password is if you used a 16 character random password, and nobody is using 16 character random passwords. you may /say/ that you do on the forums to increase your e-peen, but statistics clearly show that 91%+ of you are not.

and while we're on the subject of realism: scrypt is a great proof of concept, but it is not something your average developer can just up and implement. don't overthink it, crypt(3) is your friend. if you're developing on windows and desperately wish you knew what crypt(3) was, shoot for pbkdf2 instead -- keeping in mind today's lessons, please. and there's lots of good bcrypt implementations out there now, too. these are what you're stuck with until we come up with a standard via the Password Hashing Competition.

It's a pity the software industry doesn't have the safety-reinforcement of aviation, where accidents get a public post mortem so that everyone can learn how to do it better.

Coming from that background, I know what you mean. There is a bit of analogue in the FOSS community, though. Initiatives that have a vibrant community of expert contributers are usually quite responsive to security issues.

I wonder if some of the larger players in the industry are letting things slip a bit, becoming smug and complacent with their large enterprise contracts...

GPUs are really, really good at doing this: aaa, aab, aac, aad, aae... ... zzz. They can do it vastly faster than a conventional CPU because of their parallel operation design.

If you have a hundred thousand unsalted hashes to crack, you can just start at aaa and compare every calculated hash to the set of a hundred thousand.

If you have a hundred thousand salted hashes, each one has a large, unique prefix and will be the ONLY password to be found within the aaa ... zzz search space underneath that prefix. (If you take the aaa zzz thing literally I will beat you into a pulsating mass of sorrow with a cluebat. You know I mean the space of all possible passwords.) This slows down the parallelization because it must be redone for each hash. It's still faster than conventional CPU cracking but nowhere near as fast as unsalted gpu cracking.

It is nice if the attackers do not have the salt, but it's considered within the threat model that they probably do. They still work to slow down the process.

Can you give a bit more detail on why GPUs are better at this sort of operation please? Using your analogy, You're saying that there's a performance boost for running H("aaa") and H("aab") in parallel on a GPU, (where H is the hash function, in this case SHA256).

Is this because a parallel GPU implementation would compute the operations for each bit in a given block, and then use those results for all of the inputs that contain the same input bit? Presumably GPUs allow efficient sharing of this sort of data between threads, as well. Do you know what sort of speedup can be gained from sharing work in this way?

It's more so because the GPU can do H("aaa") at the same time as H("bbb") and H("ccc") and H("ddd") and.... (many, many more). GPUs are massively parallelable beasts, and work best when all their operations are entirely independent of each other (having to share state would slow things down... it can be worth it in some circumstances, but generally not).

I don't think that explains why salting makes a difference -- if there's no speedup on a GPU for doing H("aaa") at the same time as H("aab"), then it should be just as fast to do H("saltaaa") and H("saltaab").

It turns out that Cisco's new method for converting passwords into one-way hashes uses a single iteration of the SHA256 function with no cryptographic salt.

Ouch!

That is some seriously n00b move. Sounds like some new programmer has been tasked with improving the password security, they saw the old complex hashing code and "optimized" it away by replacing it with new "more secure" SHA256.

[...] The new one, despite using the superior SHA256, only uses one iteration of it and no salt.

in terms of password storage, sha256 is not superior to md5 -- they are equally bad.

the cryptographic weaknesses of md5 have nothing to do with why md5 is a poor choice for password storage. but the reason that md5 is a poor choice for password storage has everything to do with why sha256 is a poor choice for password storage.

it's all about speed.

sha256 is superior to md5 in terms of lower possibility of hash collisions and their exploitation.

If I am not mistaken, password strength is not only determined by the number and type of characters used -- most important thing is how many transformations of a password hash are done between the password entered and derivation of the final encryption key. The more transformations you have, the slower the brute force attack will be because you will have to run all those transformations on each password attempt before trying to decrypt data with the resulting key.

Therefore, what makes this sha256 hashed password weak is the number of iterations -- you can have 16 characters password but with one iteration of hashing you can test them insanely fast. On the other hand having 262,144 iterations od MD5 on 6 character password is going to take a lot of time.

I don't think that explains why salting makes a difference -- if there's no speedup on a GPU for doing H("aaa") at the same time as H("aab"), then it should be just as fast to do H("saltaaa") and H("saltaab").

Without the salt, all users exist within the same keyspace, ergo that single effort finds you the passwords for everyone. Salts are unique per user, ergo to find the password for user1 you have to do all of H("Salt1aaa"), aab, ..., and then more or less have to start from scratch for user2 since none of the previously found hashes do you any good due to the difference in salts.

I don't think that explains why salting makes a difference -- if there's no speedup on a GPU for doing H("aaa") at the same time as H("aab"), then it should be just as fast to do H("saltaaa") and H("saltaab").

Without the salt, all users exist within the same keyspace, ergo that single effort finds you the passwords for everyone. Salts are unique per user, ergo to find the password for user1 you have to do all of H("Salt1aaa"), aab, ..., and then more or less have to start from scratch for user2 since none of the previously found hashes do you any good due to the difference in salts.

Ah, balls -- misread the originally quoted post. I'm familiar with this justification for salting, but hadn't spotted that the speedup mentioned above was for cracking multiple passwords at once.

Speed of the hashing algorithm is not a weakness unless you have bad passwords.

The sheer amount of energy required to break something like a strong 16 char password, would consume the Milkway and a 20char password would consume the observable Universe. But that's assuming your have a 100% efficient computer.

When in doubt, scrypt.

sorry, certainly not true.

your observable universe scenario only applies to brute force. fast algorithms provide us the bandwidth necessary to run very complex and creative attacks, enabling us to crack perfectly reasonable passwords in a perfectly reasonable amount of time.

and let's be realistic here, there is such a thing as a perfectly reasonable password. just because your password isn't random doesn't mean it's a bad password. and due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

the only way you would force me to incrementally search for a 16 character password is if you used a 16 character random password, and nobody is using 16 character random passwords. you may /say/ that you do on the forums to increase your e-peen, but statistics clearly show that 91%+ of you are not.

and while we're on the subject of realism: scrypt is a great proof of concept, but it is not something your average developer can just up and implement. don't overthink it, crypt(3) is your friend. if you're developing on windows and desperately wish you knew what crypt(3) was, shoot for pbkdf2 instead -- keeping in mind today's lessons, please. and there's lots of good bcrypt implementations out there now, too. these are what you're stuck with until we come up with a standard via the Password Hashing Competition.

A "reasonable" passphrase will still exceed Earth bound processing. There are a few very simple and easy to remember tricks to make it almost as hard to break a passphrase as it is to just brute-force.

Non-comprehensive list:1) Use one char from each "Category" of characters2) Replace special chars for letters3) Break up words on non-word boundaries with special chars4) Use an uncommon word5) Have a length of 14 or more chars

Example passphrases: |Rt3][l3+eTH@}{o!r <-- first char is a pipeto be read as i r teh leet haxorpipe is an "i"the "H" in "teh" is just two bracketsI broke up "leet" with a plusReplaced "X" in "haxor" with two curly bracketsflipped the "!" with the "r" to break up the word "haxor" more.

Lots of fun ways to create easy to remember passphrases. Their only weakness is if someone ever sees one of them, they could target your patterns. But without knowing your patterns, they're actually better off brute-forcing.

Rule of thumb, you don't need to be the fastest, you just need to be faster than the slowest. Don't be a low hanging fruit.

How in the name of holiness can you have an "implementation issue" which completely omits the key requirement/point of the new feature? How can QA at a major vendor screw up that badly?

Well, given that cisco has a huge development branch in bangalore, and given my experiences with indian outsourcing, i can't say i'm surprised. Some architect in the U.S. designed the spec, threw it over the wall to india, some copy/paste programmer went to work on it and could only find example code for the sha256 part of the spec, and the result wasn't tested by someone who understood what the implementation was supposed to do.

The sad thing is that i'm pretty sure that this is exactly what happened.

sha256 is superior to md5 in terms of lower possibility of hash collisions and their exploitation.

which is irrelevant in terms of password storage. finding a collision with that few input bytes is extremely improbable. the shortest md5 collision found so far uses 64 bytes of input data. prior to that, the shortest collision found used 128 bytes.

Speed of the hashing algorithm is not a weakness unless you have bad passwords.

The sheer amount of energy required to break something like a strong 16 char password, would consume the Milkway and a 20char password would consume the observable Universe. But that's assuming your have a 100% efficient computer.

When in doubt, scrypt.

sorry, certainly not true.

your observable universe scenario only applies to brute force. fast algorithms provide us the bandwidth necessary to run very complex and creative attacks, enabling us to crack perfectly reasonable passwords in a perfectly reasonable amount of time.

and let's be realistic here, there is such a thing as a perfectly reasonable password. just because your password isn't random doesn't mean it's a bad password. and due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

the only way you would force me to incrementally search for a 16 character password is if you used a 16 character random password, and nobody is using 16 character random passwords. you may /say/ that you do on the forums to increase your e-peen, but statistics clearly show that 91%+ of you are not.

and while we're on the subject of realism: scrypt is a great proof of concept, but it is not something your average developer can just up and implement. don't overthink it, crypt(3) is your friend. if you're developing on windows and desperately wish you knew what crypt(3) was, shoot for pbkdf2 instead -- keeping in mind today's lessons, please. and there's lots of good bcrypt implementations out there now, too. these are what you're stuck with until we come up with a standard via the Password Hashing Competition.

due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

What do you mean by improper storage?

i was specifically referring to fast algorithms. any algorithm that can be computed in such a short amount of time that it grants us the ability to guess passwords at a rate of millions of guesses per second or more is not appropriate.

however, the use of any sort of reversible encryption is also not appropriate, and of course plain text storage is wildly inappropriate.

The one question that isn't being asked is whether this "implementation issue" was really an intentional decision. Would releasing routers with relatively insecure hashing algorithms benefit state cyber agents, e.g. Stuxnet vs. Iran?

How many cryptographic PHDs did you hang out with after class talking for hours about different subjects? Of which, said teacher asked if I wanted a recommendation to some friends in IBM Security Research.

How many Master's degree security professionals did you work with?

Does your degree include an emphasis in Network security and Server security?

Not that I care at all if anyone here agrees, but everything that I have heard in the past decade has talked about well implemented passphrases being strong as random passwords, assuming the attacker doesn't know your pattern. And by "strong as", I mean "no Earth bound computing could break it". You would have to boil the oceans and consume stars.

How many cryptographic PHDs did you hang out with after class talking for hours about different subjects? Of which, said teacher asked if I wanted a recommendation to some friends in IBM Security Research.

How many Master's degree security professionals did you work with?

Does your degree include an emphasis in Network security and Server security?

Not that I care at all if anyone here agrees, but everything that I have heard in the past decade has talked about well implemented passphrases being strong as random passwords, assuming the attacker doesn't know your pattern. And by "strong as", I mean "no Earth bound computing could break it". You would have to boil the oceans and consume stars.

I completely understand your point, but I don't think anyone in this thread is arguing that it isn't important to use *good* passwords. In the context of storing password hashes, the strength of any individual password is irrelevant though. The goal is to make any attempt to guess a password as computationally expensive as possible.

In a hypothetical world where EVERYONE uses completely random passwords, it would probably be OK to store simple a SHA-2 type hash - an attacker can't make any meaningful guesses and is stuck with brute force regardless. However, as epixoip pointed out, passwords are a compromise between easy-to-remember and hard-to-guess. Nobody wants to go digging around in a password safe at every login and the overwhelming majority of people use passwords with structure that makes them easier to remember. If you have structure, you become vulnerable to attack. This risk can be mitigated to various degrees by using good passwords (and you mention some good criteria for creating them, although personally, I find |Rt3][l3+eTH@}{o!r to be rather inscrutable. Not saying it is a bad password, just that easy to remember is subjective...and all those symbols hurt my eyes ) but can't be completely eliminated. The device storing the hashes *cannot* rely on strong user passwords in the event that the hashes are stolen.

Also, "boiling down oceans and consuming stars" is a huge exaggeration. It is reasonable to say that, with current resources, we cannot brute force that key space in a time-frame that is relevant to human beings. This limitation will most likely be overcome by advances in something like quantum computing, not by throwing massive amounts of energy at the problem. Although, it is fun to imagine a Death-Star-Supercomputer roaming the universe, consuming entire star systems to gather enough energy to hack my email

That's not an 'implementation issue' that's, 'LOL, didn't do anything I was supposed to do.'

The weird part is that Cisco doesn't seem to be really scrambling to fix it. They are just like, "Well, think about the fact that you may be hosed before you upgrade. Good luck!"

And the customer response should be:1. Take the new Cisco equipment offline.2. Revert to whatever equipment you were using before.3. Call Cisco for an RMA number since their new equipment is defective.

How many cryptographic PHDs did you hang out with after class talking for hours about different subjects? Of which, said teacher asked if I wanted a recommendation to some friends in IBM Security Research.

How many Master's degree security professionals did you work with?

Does your degree include an emphasis in Network security and Server security?

Not that I care at all if anyone here agrees, but everything that I have heard in the past decade has talked about well implemented passphrases being strong as random passwords, assuming the attacker doesn't know your pattern. And by "strong as", I mean "no Earth bound computing could break it". You would have to boil the oceans and consume stars.

It's not really that good. Assuming that the passphrase contains only English words and most users will use only words from the 2000 most frequently used words, a four word pass phrase has entropy of 44 bits. That's about the same as an 8 character random password.

salts certainly do not prevent dictionary attacks. i don't know where this misconception originated, but i've seen it repeated way too many times.

I believe in the context of this thread it would have come from mis-interpreting my comment where I said that "if you don't have the salt then it increases the search space for the password. It also makes the password immune to dictionary attacks."

My intention for the second sentence was to imply that the attacker didn't have the salt.

due to improper storage we crack plenty of perfectly reasonable and sufficiently long passwords that, if protected just a little bit better, would be impossible to find.

What do you mean by improper storage?

i was specifically referring to fast algorithms. any algorithm that can be computed in such a short amount of time that it grants us the ability to guess passwords at a rate of millions of guesses per second or more is not appropriate.

however, the use of any sort of reversible encryption is also not appropriate, and of course plain text storage is wildly inappropriate.