Slashdot Mirror
Lexar JumpDrive Password Scheme Cracked
Saint Aardvark writes "Lexar describes the
JumpDrive Secure as "loaded with software that lets you password-protect
your data. If lost or stolen, you can rest assured that what you've
saved there remains there with 256-bit AES encryption." @stake
has a different take: The password can be observed in memory or
read directly from the device, without evidence of tampering." And
best of all, the punch line: "[The password] is stored in an XOR
encrypted form and can be read directly from the device without any
authentication." That's why I use ROT-13 for my encryption needs."
Why go through all the trouble of attaching a debugger to the process when you can bribe the user to tell you the password with a chocolate bar! Best of all, this trick will still work long after Lexar fixes their security issue.
The password is in XOR'd form? Yeah. That's encryption.
Couldn't the software or driver have stored the password in a MD5 or SHA1 form, and still present a valid authentication mechanism for end users?
From the article:
Vendor Response:
08-05-2004 Vendor contacted via email to support@lexarmedia.com
No response.
08-12-2004 Vendor contacted again via email to support, sales
Public Relations, Investor Relations, and general
inquiry email addresses.
08-12-2004 Automated response from support received
09-13-2004 No further response from vendor, advisory released
Vendor has not acknowledged issue or produced a fix.
This is a pretty embarassing non-response.
The product is only about 5 or 6 months old, and the password was just sitting there. AES is a perfectly fine standard for encryption, but this is an embarassing implementation. Thankfully, I don't know anyone who owns this.
EVERYTHING violates the DMCA. Everything. Even talking about violating the DMCA violates the DMCA.
"I'm just here to regulate funkiness."
It allows those who forget their passwords to quickly access the 'lostpaswd?' file, saving on support calls.
The number one rule of talking about the DMCA and archiving the results, encrypted, on a Lexar JumpDrive.
You do NOT talk about DMCA and archive the results, encrypted, on a Lexar Jumpdrive!
That's why I use DriveCrypt. I got my version years ago and it's pretty antiquated but it supports up to 1024 bit encryption (granted it makes things relatively slow).
Why does the password need to be 'stored' anyway? Isn't that kinda the point?
Is this some sort of 'encrypted session key' thing where one long, secure password decrypts another shorted one that's used to do the dirty work? Is it stored for key recovery by tech support droids?
Why store the password? Is this just the worst implementation in the whole world or am I missing something?
I was always forgetting important things, like the meaning of the word "redundant." But thanks to the Joe Johnson memory system, I can now remember things like the meaning of the word "redundant." Thanks, Jack!
Copyright 2004, Jake Johannson Memory systems.
"I'm just here to regulate funkiness."
...that the best encryption algorithm is worth nothing if you fuck up the implementation...
I use ROT-26.
-
that, and their password was "PASSWORD"
XOR means "exclusive or". A regular "or": if one of the inputs is 1, return 1. An "exclusive or": if one of the inputs is 1, but not both, return 1.
OR:
0101
0011
----
0111
XOR:
0101
0011
----
0110
AND:
0101
0011
----
0001
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
MD5 *does* have something to do with cryptography (why else would Schneier devote the whole 14th chapter of Applied Cryptography to "One-way hash functions"), and the reason is simple: it is used to encrypt your *password*, not your data (Lexar was claiming that they use 256-bit AES encryption for the data itself).
For authentication you do not store the password in plaintext, only its MD5 hash, when user enters the password, MD5 of that is computed and compared to the stored MD5 string, if they match -- your user is authenticated. Of course XOR with a "magic number" could be used for the same purposes, but it would be much weaker. Thus, I think that the GP was not a troll and made a valid point: use MD5 to hash your passwords, and preferrable add some salt value to prevent against dictionary attack.
The other questiuon is why did Lexar had to store passwords on the drive at all, one does not need to authenticate users in their scenario (the drive itself is not a self-cointained computer to which a user needs to gain access) -- they could've just asked for the password, convert it to the key used in AES algorithm, decode the data and give the result: if password is incorrect, the decoded data is garbage.
Paul B.
Because of this, hashing is irreversable, and therefor only an idiot would use it for encryption. It's proper purpose is for checksuming.
Try telling that to Daniel Bernstein. His "Snuffle" code converts any hash into a cipher. To put it shorter: sampling the output of a well-designed hashing algorithm after every n bytes produces a suitably random bitstream; XORing that against the message produces a stream cipher.
After being put on hold for over twenty minutes, I finally spoke with a man named Henry who said that he has never heard that JumpDrive had a security problem (even after I confronted him with the advisory from @Stake), and did not know that @Stake was trying to contact them for over a month. He was quite shocked but promised to check out /. and @Stake to verify the claim.
The ostrich finally wakes up.
Um...
If A XOR B = C , then A XOR C = B and B XOR C = A.
So if MYPASSWD XOR SECRET = ENCRYPTEDCODE, and I know both MYPASSWD and ENCRYPTEDCODE, then I can find SECRET.
I don't know if all of the drives have the same SECRET or not, but, having determined what SECRET is on my drive, I can give the drive to you, or I can try my SECRET on another drive and see if it works.
--hymie!