3 ms·

Anyone care to explain the DES misuse to laypeople? And why do some passwords have a salt(?) and some don't?

by sudhirj 13y ago

padwan 13y ago
That's not salt. "Since DES only encrypts in blocks of 64 bits (8 bytes) then encrypting and keeping the length of blocks means that you actually get a very good idea of the length of the password - that is, anything with only one block is a password length between 1 and 8 characters, with two blocks between 9 and 16 characters etc. In addition a password of "1234567812345678" would encrypt into two identical blocks." http://www.explainxkcd.com/wiki/index.php?title=1286 http://www.explainxkcd.com/wiki/index.php?title=1286
taejo 13y ago
The passwords don't have a salt: that extra block that some of them have is the second block of the password (each block of 8 bytes is encrypted separately).
bazzargh 13y ago
As I understand it, Adobe used ECB mode, which means the blocks are encrypted independently. You can look at the encrypted blocks and see that two different passwords share character sequences. This is I assume what Randall is referring to with the 'crossword' bit - as well as having clues in the hints, solving one password may give you part of another. The suffix may also contain only one or two characters (plus padding) which makes it more plausible to mount a brute force attack. ECB mode is just terrible. As well as these suffix problems, I've seen another example where a company used it to encrypt key-value pair cookies. Of course the keys are always the same...so prefixes were guessable too. And wikipedia has a fantastic example of why its stupid for images: http://en.wikipedia.org/wiki/ECB_mode#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/ECB_mode#Electronic_codebook_.2...
ohwp 13y ago
"why do some passwords have a salt(?) and some don't?" I'm not sure if this is the case, but sometimes this has to do with 'backwards compatibility'. I've seen databases where some passwords where MD5, some SHA1, some Bcrypt and so on. The login page then will do something like: if(checkBcrypt(password)) { login(); } else if(checkSha1(password) || checkMd5(password)) { updateDbPassword(password); login(); } else { loginError(); }
- nodata 13y ago
  I'd hope the password is marked along with the hashing type, like in /etc/shadow
JulianMorrison 13y ago
ECB mode encryption is like the kind of cereal box cyphers you probably played with as a kid. For any given key, a fixed block of data goes in, a fixed block of data comes out. It won't usually be the whole of the password, but maybe "password" comes out as "94a012e6de4f1f0e" always. And so if you can guess that, then you're halfway to guessing "password123" and "passwordQWERTY" and so on. In general, using any mode of encryption (rather than hashing) on passwords is dumb. But this is dumber than usual.

Anyone care to explain the DES misuse to laypeople? And why do some passwords have a salt(?) and some don't?

by sudhirj 13y ago

Anyone care to explain the DES misuse to laypeople? And why do some passwords have a salt(?) and some don't?

That's not salt. "Since DES only encrypts in blocks of 64 bits (8 bytes) then encrypting and keeping the length of blocks means that you actually get a very good idea of the length of the password - that is, anything with only one block is a password length between 1 and 8 characters, with two blocks between 9 and 16 characters etc. In addition a password of "1234567812345678" would encrypt into two identical blocks." http://www.explainxkcd.com/wiki/index.php?title=1286 http://www.explainxkcd.com/wiki/index.php?title=1286

taejo 13y ago

The passwords don't have a salt: that extra block that some of them have is the second block of the password (each block of 8 bytes is encrypted separately).

bazzargh 13y ago

As I understand it, Adobe used ECB mode, which means the blocks are encrypted independently. You can look at the encrypted blocks and see that two different passwords share character sequences. This is I assume what Randall is referring to with the 'crossword' bit - as well as having clues in the hints, solving one password may give you part of another. The suffix may also contain only one or two characters (plus padding) which makes it more plausible to mount a brute force attack. ECB mode is just terrible. As well as these suffix problems, I've seen another example where a company used it to encrypt key-value pair cookies. Of course the keys are always the same...so prefixes were guessable too. And wikipedia has a fantastic example of why its stupid for images: http://en.wikipedia.org/wiki/ECB_mode#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/ECB_mode#Electronic_codebook_.2...

ohwp 13y ago

"why do some passwords have a salt(?) and some don't?" I'm not sure if this is the case, but sometimes this has to do with 'backwards compatibility'. I've seen databases where some passwords where MD5, some SHA1, some Bcrypt and so on. The login page then will do something like: if(checkBcrypt(password)) { login(); } else if(checkSha1(password) || checkMd5(password)) { updateDbPassword(password); login(); } else { loginError(); }

nodata 13y ago
I'd hope the password is marked along with the hashing type, like in /etc/shadow

JulianMorrison 13y ago

ECB mode encryption is like the kind of cereal box cyphers you probably played with as a kid. For any given key, a fixed block of data goes in, a fixed block of data comes out. It won't usually be the whole of the password, but maybe "password" comes out as "94a012e6de4f1f0e" always. And so if you can guess that, then you're halfway to guessing "password123" and "passwordQWERTY" and so on. In general, using any mode of encryption (rather than hashing) on passwords is dumb. But this is dumber than usual.