11 ms·
Cheap GPUs rendering strong passwords useless?
- pixeloution 15y agoGPUs are rendering MD5 and other weak hashing methods useless when a database is compromised. Using bcrypt [properly] can reduce the attempts the fast computer on the planet could make to a handful per second.
- thirsteh 15y agoYep. Don't store passwords using (non-password) fast hashes like MD5 or SHA-256. Use bcrypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- Joakal 15y agoHis recommendation of not using salts is very misleading and should not be quoted due to poor advice as Bcrypt is also useless against dictionary and brute force attacks. The aim of password storage security is to prevent pre-computed hashing reasonably enough. No amount of password hashing even if it takes 1000 years to hash a password if your users use '12345678' as a password. Salting protects against pre-computed hashes (rainbow tables [0]). Otherwise I can pre-compute many bcrypt hashes and then quickly look up the password. [0] https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_tables https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_table...
- tptacek 15y agoNo; you're incorrect. All secure password storage schemes are randomized. If you insist on using the word "salt", then just know that bcrypt, scrypt, and the PBKDFs build the salt in. You cannot "pre-compute many bcrypt hashes and quickly look up passwords". So: if you're using a scheme that requires you to think about salts, you are virtually certain to be using an insecure storage scheme. And, dictionary and brute force attacks are the entire problem bcrypt is designed to address. Go back to that article that you didn't really read, follow the first Usenix link, and read the Usenix paper it cites.
- Joakal 15y agoI'm concerned that you advocate ignorance of 'salt'. Some functions[0][1] seem to optionally allow the use of salt, are you saying that users should just use passwords as input with bcrypt hashing? In the article, it does not suggest only bcrypt as well [2]. [0] http://www.mindrot.org/projects/py-bcrypt/ http://www.mindrot.org/projects/py-bcrypt/ [1] http://au.php.net/crypt http://au.php.net/crypt [2] http://www.usenix.org/events/usenix99/provos/provos_html/node16.html#SECTION00070000000000000000 http://www.usenix.org/events/usenix99/provos/provos_html/nod...
- tptacek 15y agoBcrypt uses a 128 bit salt. The code I provided above didn't show it, because the library simply generated it for me. The bcrypt libraries that require users to explicitly provide a salt are themselves doing their users a (slight) disservice, by making it seem as if there was a reasonable option for salt generation other than simply using a CSPRNG.
- djmdjm 15y ago> The code I provided above didn't show it, because the library simply generated it for me. ... and this is another reason why people should use one of the bcrypt() implementations for their language* - the API makes doing the wrong thing difficult or impossible. * disclosure: I ported/wrote a couple of them
- bigiain 15y agoThe problem is, I can onlybchoose the password hashing algorithm when I control the server side code. 99.9% of the time I don't, and I don't even get to find out how the people controlling the server side code are storing by password. Quick quiz: how does HN store passwords? How about apple.com? Facebook? Twitter? Gawker? Sony Pictures? Perlmonks? A suitably paranoid person would assume any password you've given to somebody else's website is compromised. Do not reuse passwords ever. Don't even think "I'm just trying this new web service out, I'll use the same password I always use when trying new things out", 'cause you'll end up forgetting to upgrade that password when something gradually changes from "some new and maybe interesting website" to "somewhere that is an important part of my online reputation" or "somewhere I've given authority to charge my credit card". (and, even more importantly, don't ever fall into that trap when developing server side code "Oh, I'll just do a quick login method for testing that just stores cleartext passwords, I'll fix that bit up before we go live..." Because one day that code _might_ end up live...)
- Zak 15y agohow does HN store passwords? Unsalted SHA1. (def shash (str) (let fname (+ "/tmp/shash" (rand-string 10)) (w/outfile f fname (disp str f)) (let res (tostring (system (+ "openssl dgst -sha1 <" fname))) (do1 (cut res 0 (- (len res) 1)) (rmfile fname))))) ... (and user pw (aand (shash pw) (is it (hpasswords* user))))
- rimantas 15y agoIt may store it as plaintext as well, without HTTPS it does not really matter. I mean it is easier to obtain passwords with tools like firesheep instead of trying to break into DB. On the other hand, it is not like you have something secret there. The worst thing that could happen is someone pretending to be you. That said I'd love to have https option.
- bigiain 15y agoKind of proving my point. You'd hope somewhere that calls itself "hackernews" and which may as well have an echo-bot set up quoting that codahale article about bcrypt any time someone writes "password" - might be handling passwords "properly". SHA1 isn't really all that different from Gawkers MD5 password ballsup... Instead, all the top 25 passwords found in the recent Sony exposures from here: http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html http://www.troyhunt.com/2011/06/brief-sony-password-analysis... are found in that well known rainbow table, Google... iains-imac: bigiain$ echo -n 'bailey' | openssl sha1 b1f45ed147d6803ac1a2a91bdea1fab603f910a5 http://www.google.com/search?q=b1f45ed147d6803ac1a2a91bdea1fab603f910a5 http://www.google.com/search?q=b1f45ed147d6803ac1a2a91bdea1f... If HN ever gets 0wn3d, anybody with a (password) dictionary word or 8-9 char or less password will almost certainly be exposed. (even if the database doesn't get broken into, anybody who gets enough shell on the webserver to read /tmp/shash will be able to see cleartext passwords passing through...)
- drivebyacct2 15y agoNTLM passwords? Meh. An awful benchmark for evaluating modern passwords. Who uses NTLM besides Windows, honestly? (Apparently the person who seemed to have not liked this comment, very quickly, heh) I'd be curious about the timeliness of GPU cracking a 8 character, alphanumerical mixed case password hashed with SHA1?
- tptacek 15y agoLike MD5, SHA1 is designed to be fast. For that matter, so is SHA256, and all the SHA-3 candidate functions. The right way to think about this is that all the strong crypto hash functions are unsuitable for use by themselves as password hashes. Cryptographers have a mechanism for securely turning human-readable text into secret material: key derivation functions. All the modern KDFs are adaptive, meaning that they come with a "pain" dial that you can turn to force attackers to spend more time executing crypto code paths and less time comparing results. You can build decent KDFs out of functions like SHA1, but if hardware GPU cracking is the future, you're best off with something like Colin Percival's "scrypt", which was explicitly designed to be memory-hard (requiring lots of state to compute) and hard to parallelize: http://www.tarsnap.com/scrypt/scrypt-slides.pdf http://www.tarsnap.com/scrypt/scrypt-slides.pdf
- shaggyfrog 15y agoI know you're a domain expert and in this thread you've suggested both bcrypt and scrypt. Is there any advantage to one over the other? From my POV it seems that bcrypt has more implementations and seems better-known (in a good way).
- tptacek 15y agoscrypt is the sounder scheme, but bcrypt is far more widely available. Both are fine.
- caf 15y agoNTLM hashes are MD4, which is of a comparable speed to SHA1 for short input blocks, so the time would be around the same. At any rate, you can download ighashgpu and try it for yourself.
- bcl 15y agoThere are at least a few obvious solutions. One is to use long passphrases. Another is to stop trying to memorize your passwords, write them down on a postit, encrypted file, etc. The main threat to your security is not someone digging through the postits in your wallet, it is the hash being stolen from someone's insecure database.
- r00fus 15y agoThe bad part is that some sites (even banks!) force you to limit the number or type of characters. In one ridiculous case, I was forced to use an 8 character pwd with only lowercased letters. The solution is to use tools like KeePass or 1Password to allow maximum length passwords (randomly generated also) wherever possible.
- Joakal 15y agoIt's likely that they are storing passwords in plain text or encrypted. If my website can accept forum posts in UTF-8 of 256+ characters, then people can log in with UTF-8 256+ char passwords.
- code_duck 15y agoI recently signed up for the new payment system for my local water and gas company... you must use your phone number as your user name, and the password, to my suprise, can only be digits, up to 8 characters. Pretty horrible. I wonder what level of idiot designs these systems.
- cdr 15y agoThat "new payment system" is quite possibly interfacing with, say, mainframe code written in the 70s. That's often the source of banks' ridiculous account restrictions.
- code_duck 15y agoI can't see any legitimate technical reason to restrict passwords. In my example, they could put a sensible account system on the front end, and do whatever they need to in the back end to link it to my phone number and a random 8 digit number, if that's what they need. Same with banks. They can set up a real user name and password from you, store it in a modern system, and link it to the older system behind the scenes. Perhaps there's some arcane legislation that prevents this, but it seems unlikely.
- brianbreslin 15y agocan't you design your software to prevent brute force logins? i.e. lockout for x seconds if y unsuccessful login attempts are made?
- city41 15y agoThat doesn't matter if someone has a dump of the database. Which as Sony can tell you, is becoming more common.
- brianbreslin 15y agogood point. i'll have to read up on how sony's db got extracted first then.
- bonzoesc 15y agoSQL injection, social engineering a password, somebody's crappy "secret question," insecure PHP, and hundreds of other ways. Closing off known avenues of attack and still mitigating against a leak with peer-reviewed math is what you have to do.
- pragmatic 15y agoYes, but once you are in to the point where you have the db...what else are you going after? If you can dump the db then (most likely) you also have the credit cards, other information that is useful to you? This assumes a hacker has a financial motivation.
- city41 15y agoI would hope the db didn't store credit card info or at least encrypted it somehow. Granted that's a pretty big hope. But if you can crack the passwords in the db you have, chances are those passwords will work on other sites. People often use one password for everything.
- ceejayoz 15y ago> Yes, but once you are in to the point where you have the db...what else are you going after? There are many conceivable attacks that would result in a read-only dump of password hashes. An administrator's account would be useful in such an administration, turning your read-only access to read-write access.
- tptacek 15y agoNO THEY AREN'T. This is a great example of a bona fide awful trade press article: some guy with a column-inch quota sees a piece by another trade press hack who is in turn digesting a blog post by someone who is "allergic to command line utilities" writing up someone else's GPU password cracking tool. And so, strong passwords are useless! Except that this has nothing at all to do with why passwords are bad. The problem GPU crackers exploit was solved over a decade ago with adaptive hashing. GPU crackers cannot crack scrypted passwords of any real complexity in tenable amounts of time. Once again: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- Joakal 15y agoCodahale's article is misleading with salts. Bcrypt can't also protect against brute-forcing or dictionary attacks. Please don't spread that link as an example of good password storage security. Edit: Since I can't reply to poster. I don't see bcrypt using a unique salt for each password. It's the equivalent of exchanging a SHA256 + Same Salt for Bcyrpt + Built-in-Salt. Does bcrypt use a unique salt per account?
- tptacek 15y agoNo; you're incorrect. You can find the answers to your bcrypt questions at the Usenix paper which is the first link in the article you're advising people not to read.
- Joakal 15y agoI did, it uses a preset list of salts at the time. That doesn't seem unique per account salting raising the possibility of collisions to me.
- tptacek 15y agobcrypt uses 128 bit salts. Every bcrypt library I've seen will generate the salt for you. [8:48pm:~] RIDGELAND:tqbf [1:45]% irb -rrubygems -rbcrypt >> BCrypt::Password.create("test password") => "$2a$10$KyxzQ6ZlAAYdLWwpgCbyjuqo53.LzPbsaSK2BiTnzpYEpRVZOHAAy" >> BCrypt::Password.create("test password") => "$2a$10$d0uUieyk0NWsU7E9CmQNwOsveyznwKwplphsF73yILdEyStmoUGgG" Notice how they aren't the same hash? And, how I didn't have to go mine pink salts from the Himalayas? By spreading the notion that there is something wrong with Coda's article when you really aren't familiar with bcrypt, you're doing people a disservice. They are going to go use SHA1 with a big random salt instead, because they've heard of SHA1 before and it therefore sounds more secure. And they will thus be terribly vulnerable to brute-force attacks.
- fleitz 15y agoThis article is missing a bunch of facts, namely that NTLM passwords have been broken for 2 to 3 years long before the invention of cheap GPUs. Rainbow tables are a far more effective way to attack NTLM hashes. Cracking passwords is trivially parallelizable, if you let your hashes fall into the hands of the enemy then it's only a matter of money. The fundamental issue is that of salting combined with not disclosing your password database. If you're using Windows you should enable the options for SSHA and disable the NTLM / LM hashes. Instead of using a password use a passphrase. I use 3 levels of password and at the top level you're looking at ~22 characters which contains characters outside the normal ASCII range so an attack is looking at ~65536 combinations instead of ~256. I doubt many attackers include the snowman character. :) (and no that char isnt in my password) Running the math quickly yields a time to crack in excess of the lifetime of the universe, it would probably be easier to generate a hash collision than crack the password.
- flashingleds 15y agoSince this has attracted the attention of some very knowledgeable people, can anyone suggest a good textbook/site/paper discussing password security and encryption? Obviously I can google 'computer security' and find something, I just wondered if there was a well regarded standard reference (ala K&R or Art of Electronics). I don't understand the majority of the techniques being discussed here but would quite like to.
- tptacek 15y agoSorry, key derivation functions are kind of a back alley in crypto research. Your best bets are Colin's scrypt paper and the original bcrypt paper; the bcrypt paper is on the link at Coda Hale's "How To Store Passwords" article, which you can find plastered all over this thread, and Colin's paper is at: http://www.tarsnap.com/scrypt/scrypt.pdf http://www.tarsnap.com/scrypt/scrypt.pdf
- tedunangst 15y agohttp://tools.ietf.org/html/rfc2898 http://tools.ietf.org/html/rfc2898
- pragmatic 15y agoThis article uses NTLM passwords. Can anyone compare this to the actual MSFT recommended Kerberos security protocol? Also, how does one go about getting a list of NTLM passwords to work against? You steal the domain controller or somehow get access to it? http://en.wikipedia.org/wiki/NTLM http://en.wikipedia.org/wiki/NTLM MSFT does not recommend using NTML which is very old. http://msdn.microsoft.com/en-us/library/cc236715(v=PROT.10).aspx http://msdn.microsoft.com/en-us/library/cc236715(v=PROT.10).... Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in [RFC1320] and [FIPS46-2]. Therefore, applications are generally advised not to use NTLM.<68>