Biz & IT —

Cisco switches to weaker hashing scheme, passwords cracked wide open

Crypto technique requires little time and computing resources to crack.

Dan Goodin - Mar 19, 2013 2:25 pm UTC

Cisco switches to weaker hashing scheme, passwords cracked wide open

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.

The advisory said that Type 4 protection was designed to use the Password-Based Key Derivation Function version 2 standard to SHA256 hash passwords 1,000 times. It was also designed to append a random 80-bit salt to each password.

"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

abadideaArs Praetorian
jump to post

kfitch42 wrote:
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.

483 posts | registered Apr 14, 2010
abadideaArs Praetorian
jump to post

Solomonoff's Secret wrote:
abadidea wrote:
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.

484 posts | registered Apr 14, 2010
fuzzyfuzzyfungusSmack-Fu Master, in training
jump to post

myst812 wrote:
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.

78 posts | registered Jul 2, 2012
dehildumWise, Aged Ars Veteran
jump to post

myst812 wrote:
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.

115 posts | registered Dec 2, 2010
epixoipSmack-Fu Master, in training
jump to post

Solidstate89 wrote:
[...] 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.

75 posts | registered Aug 21, 2012
epixoipSmack-Fu Master, in training
jump to post

kfitch42 wrote:
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.

hope that clears things up.

75 posts | registered Aug 21, 2012
epixoipSmack-Fu Master, in training
jump to post

Bengie25 wrote:
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.

76 posts | registered Aug 21, 2012

Promoted Comments

abadideaArs Praetorian
jump to post

kfitch42 wrote:
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.

483 posts | registered Apr 14, 2010
abadideaArs Praetorian
jump to post

Solomonoff's Secret wrote:
abadidea wrote:
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.

484 posts | registered Apr 14, 2010
fuzzyfuzzyfungusSmack-Fu Master, in training
jump to post

myst812 wrote:
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.

78 posts | registered Jul 2, 2012
dehildumWise, Aged Ars Veteran
jump to post

myst812 wrote:
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.

115 posts | registered Dec 2, 2010
epixoipSmack-Fu Master, in training
jump to post

Solidstate89 wrote:
[...] 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.

75 posts | registered Aug 21, 2012
epixoipSmack-Fu Master, in training
jump to post

kfitch42 wrote:
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.

hope that clears things up.

75 posts | registered Aug 21, 2012
epixoipSmack-Fu Master, in training
jump to post

Bengie25 wrote:
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.

76 posts | registered Aug 21, 2012

Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene.

Channel Ars Technica

← Previous story Next story →

Promoted Comments

Promoted Comments

reader comments

Channel Ars Technica