5 ms·

..."they struck gold with an SQL injection attack on HBGary Federal's content management system. [...] They quickly grabbed and decrypted user passwords from th

• fleitz 16y ago
  From the information available it appears the passwords were hashed but not salted.
  • tomjen3 16y ago
    If that is true, then they must have used some really, really simple passwords for them to be cracked in such a short time.
    • Garbage 16y ago
      Hint: MD5 and Rainbow tables
    • fleitz 16y ago
      From the available info there were indeed simple passwords and password reuse between systems of different security levels. openssl speed md5 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 23895.04k 85345.30k 231322.03k 412608.40k 546306.56k If you look at the openssl numbers from my workstation, you'll find I can generate hashes for 1.5 million 16 byte passwords per second. The nice part about rainbow tables is that they are easy to compute in a distributed nature. Take a couple hundred EC2 boxes and you can generate HUGE tables, if you're smart with how you use S3 you can write the tables directly to S3. Cracking unsalted passwords is a very simple time/memory trade off. Given the issues with MD5 with a good math background you might even be able to reverse the password. (eg. create a known password that computes to the same hash) If you got creative with some FPGAs or GPUs you could do far better.
      • smanek 16y ago
        What do you mean by '16 byte passwords'? 16 bytes is only 1 or two character under most encoding schemes ...
        • com 16y ago
          Bytes are 8 bits - UTF-8 gets most of ASCII in 1 byte (8 bits) and many (most?) other language glyphs can be encoded in 2 bytes or so (16 bits). A 16 byte field can hold up to 16 ASCII characters, or perhaps 8 CJK glyphs that might encode a short kanji or hanzi password.
          • yuhong 16y ago
            "A 16 byte field can hold up to 16 ASCII characters, or perhaps 8 CJK glyphs that might encode a short kanji or hanzi password." Assuming that you are using legacy encodings, of course.
        • fleitz 16y ago
          I think you may be thinking bits not bytes. The typical ASCII/UTF-8 char is 8 bits. UTF-16 doesn't really get used outside of Windows, I'm unsure if Windows hashes on char or wchar. I don't think anything uses UTF-32 other than to make string searching simple in regard to texts containing characters outside the BMP. Please don't downvote the OP, it's a simple mistake. Regarding what I mean by 16 byte passwords, MD5 requires computation on a fixed block size. If your password is not a multiple of block size it needs to be padded before it can be hashed. IIRC, the usual thing to do for MD5 is a simple zero pad, because you never have to produce the plaintext so you'd never bother writing the algorithm to put number of padded bytes in the pad. IIRC the MD5 block size is 64 bits (8 bytes), so you usually have to do two invocations to compute the hash for a 16 byte password. From a hashing speed perspective an 0-16 byte passwords take roughly the same time to hash. It really depends on your cache line size as MD5 doesn't have any branches, and your hashing speed is dominated by memory access. If you look at the perfomance numbers you can see that as you increase block size your hashing speed increases drastically, but unfortunately passwords are short so you need a mechanism for generating passwords with out having to hit the L2 cache. Luckily, this is fairly easy to do so if you used something like jack the ripper to generate/hash passwords you'll see much better performance than openssl. @com, on a purely technical level UTF-8 gets all of ASCII in one byte, only extended ASCII requires multiple bytes. In practice ASCII is extended ASCII / ISO-8859-1, almost all of extended ascii fits into two bytes, but some require 3.
    • bigiain 16y ago
      There's some remarkably complete rainbow tables out there for MD5... Last time I heard any details, every 11char string and every combination of dictionary words including letter/number substitutions out to 16chars is now just a lookup away... Any password small enough to remember is probably vulnerable if stored as an unsalted MD5 hash.
      • stcredzero 16y ago
        Ugh. Time for me to go to all 32 character passwords.
        • yuhong 16y ago
          Or even better, don't use the same password on every site.
          • deleted 16y ago
            [deleted]
          • bigiain 16y ago
            That's the right answer. Find a password storage solution that, works for you, and use it everywhere. Use different random maximal character set passwords everywhere. I've chosen 12 char passwords with upper/lower case, at least 2 digits, and at least 2 punctuation chars, as a balance of "secure enough" and "short enough I can remember it while moving between the password safe and the login form". I've got a calendar reminder to revisit that decision every year, sometime in the next few years I may need to increase my password length. I'm using 1password it's dropbox sync feature, it gives me automatically synced access on my phone, iPad, MacBook, and desktop machines. If you're a Mac OSX/iOS user, I highly recommend it. If you're not, find something similar and use it instead. But these days it's _well_ past the time where you can afford to "trust" random websites to store credentials you use. Sharing credentials across sites was never a good idea, but these days it's a _really_ bad idea.
          • stcredzero 16y ago
            Why would I have plural "passwords" but only use one on every site?
  • iwwr 16y ago
    Salts won't give you that much greater security these days. Password-cracking GPGPU hardware is already well into the consumer domain. Using a pair of AMD's HD 5970, you can get cranking to just over 1bn SHA256 hashes/s.
    • MichaelGG 16y ago
      Doesn't salting and iterative hashing pretty much stop rainbow tables? Didn't they find the passwords via a rainbow table?
      • iwwr 16y ago
        Yes, they stop rainbow tables, but not GPGPU crunchers like the HD 5970. Moore's law is catching up rather fast at the moment.
        • stcredzero 16y ago
          You can still maximize the time and expense of an attack with salts and rainbow tables. (and bcrypt)
  • deleted 16y ago
    [deleted]