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."

5 of 565 comments (clear)

  1. Even worse... by Anonymous Coward · · Score: 5, Insightful

    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.

  2. An embarassment of security. by michael+path · · Score: 5, Insightful

    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.

    1. Re:An embarassment of security. by Alizarin+Erythrosin · · Score: 5, Insightful

      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?


      Aside from storing the password in XOR'd form, the software checking the password is flawed. It unencrypts the password first, then compared the password entered. Rather then encrypting the password entered and comparing it to the device?

      There may even be better ways than that. I'm not a cryptography person, but that's the first thing that comes to mind.

      --
      There are only 10 kinds of people in this world... those who understand binary and those who don't
  3. I'm fuzzy on something... by ALecs · · Score: 5, Insightful

    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?

  4. This shows once again... by piquadratCH · · Score: 5, Insightful

    ...that the best encryption algorithm is worth nothing if you fuck up the implementation...