Slashdot Mirror

← Back to Stories (view on slashdot.org)

Lexar JumpDrive Password Scheme Cracked

Posted by CmdrTaco on from the now-thats-just-funny dept.

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

4 of 565 comments (clear)

  1. Dupe? by ceeam · · Score: 0, Redundant

    "That's why I use ROT-13 for my encryption needs."

    I swear I've seen this somewhere around here lately.

  2. XOR? I can do better! by Caharin · · Score: 0, Redundant

    Bah, my encryption scheme is way better than that.

    I XOR all my data *TWICE*. Try and read that!

    --
    By reading this sig, you agree to be bound by all terms and conditions I choose.
  3. Re:Cue::Cat by Alsee · · Score: 0, Redundant

    This post is in ASCII encryption.

    -

    --
    - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
  4. So what is it XOR'd with by Performer+Guy · · Score: 0, Redundant

    Look, XORing is how a lot of encryption works, the deal is you need to make the sequence of bytes you XOR with unique, unknown and difficult to determine/guess. Hashing functions do this by producing the long XOR sequence from a smaller key.

    So what is it XOR'd with? If it is some common or repeating sequence then obviously this is about as pathetic as it gets. Unfortunately the advisory is completely devoid of details on he password storage other than saying it is XOR encrypted.

    The password may be XOR'd with it's own hash function output in which case this isn't as bad as it looks. Looking at the paper it seems that the real flaw is the software in memory decryption of this XOR'd password to reveal it plain text in memory, however again it is still not entirely clear how flawed this is.

    For it to decode that password it would have to know what the encryption key was in software so that would be a *huge* flaw, however plain text comparrisons could work if the password itself was used for the encryption/decryption.

    For example you could encrypt the password with the hash output then store it and decrypt it with the candidate hash output for any new password attempted. Only if it was the correct hash password would this produce a match and only with the correct password typed in in memory could you ever see a correct plaintext password in memory.

    It must be that the software has a fixed key in software which is used for the comparrison for this to be an issue. That would be spectacularly incompetent, either that or this advisory is spectacularly inept. It is actually difficult to tell from the info we have so don't jump to conclusions.

    If it is a bug a simple fix would be to use the password itself to encrypt the password on the disk instead of some fixed key, but I can't believe that this isn't done already.