In the recent Adobe passwords leak, presumably encrypted in 3DES ECB, second half of all 8-character passwords is identical: ioxG6CatHBw==

Source: http://pastebin.com/iDTFARwq (guesses based on obvious password hints)

L8qbAD3jl3jioxG6CatHBw== password
BB4e6X+b2xLioxG6CatHBw== adobe123
j9p+HwtWWT/ioxG6CatHBw== 12345678
rpkvF+oZzQvioxG6CatHBw== iloveyou
2dJY5hIJ4FHioxG6CatHBw== sunshine
Ttgs5+ZAZM7ioxG6CatHBw== princess
Dts8klglTQDioxG6CatHBw== computer
y7F6CyUyVM/ioxG6CatHBw== superman
2hD1nmJUmh3ioxG6CatHBw== asdfasdf
cSZM/nlchzzioxG6CatHBw== 1q2w3e4r
e+4n2zDarnvioxG6CatHBw== 1qaz2wsx
ueE89xIj8RTioxG6CatHBw== internet
ietF94QrMIbioxG6CatHBw== michelle
ecW6IyEemknioxG6CatHBw== football
lVwka/Mn8TPioxG6CatHBw== baseball
ghrvkwCcX4bioxG6CatHBw== jennifer
eOsrbcW/PeTioxG6CatHBw== abcd1234
Nz4/TI6o5RrioxG6CatHBw== trustno1
iMhaearHXjPioxG6CatHBw== whatever
OPQxDLW2L+DioxG6CatHBw== 11111111

Does it allow for guessing the keying option used or other 3DES encryption properties?


DES has a block size of 8 bytes. Two blocks therefore come to 16 bytes.

It looks like Adbobe were encrypting passwords using two blocks of 3-DES in ECB mode.

Because all these passwords are eight bytes long, the second block is empty and is just filled with zeros. The second block gets started at all because of the string-terminating NUL character at the position 9 of the password. The character that the rest of the block is padded with is also NUL. Because we're in ECB mode, this block encrypts to the same value each time.

That's why all these passwords have the same eight trailing bytes: ioxG6CatHBw==. This is just the sequence of bytes you get when you encrypt 64 zero bits using their key.

  • $\begingroup$ Is there a valid reason for encrypting 8 bytes using two blocks if the second block does not store any additional information? Is this standard procedure for 3DES or an Adobe-customized version? $\endgroup$ – Adam Nov 2 '13 at 21:26
  • 4
    $\begingroup$ @Adam, Adobe have completely screwed up. This is not the proper way to store passwords. While they used a strong cipher (3DES) they used it in the wrong context and worse, in the wrong mode. It's a screw up, pure and simple. $\endgroup$ – Simon Johnson Nov 2 '13 at 21:34
  • 2
    $\begingroup$ Is there any reason to believe that it's zero padding and not e.g. PKCS7? I'd expect most paddings to show the same behavior. $\endgroup$ – CodesInChaos Nov 6 '13 at 8:18

Note: I'll disregard the base64 encoding in the following text; the base64 encoding does not change the properties of the generated ciphertext.

What you are running into is padding together with ECB mode. This padding can be any static padding. Most common is PKCS#5 padding, but zero padding is also possible. It is not possible to test which padding is used, unless you get the program to encrypt a "password" that contains a block of 8 zeros or 8 bytes valued 08 for PKCS#5. In that case you would expect the same bytes to be generated.

The identical ciphertext block at the end is not an issue, and the key can certainly not be found (it never can be unless the block cipher fails, or if the key is guessable). The use of ECB is an issue however. Identical 8 character strings can be easily detected by binary comparison of blocks. It is well known that ECB encryption should not be used for strings.

It depends on the use of the passwords, but in general it is not safe nor required to store passwords - even with encryption - to log into a site. For that kind of purpose a Password Based Key Derivation Function (PBKDF2, bcrypt, scrypt) should be used. If required an additional, secret salt could be used if an additional layer of cryptography is required.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.