New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
i've never seen an actual implementation that will trim a passphrase. 72 bytes encoded is long on its own, let alone hashed.
no there isn't, its just running it 5000 or 10000 times instead of once. I find them all the time in rainbow tables, this isn't even a theoretical attack anymore, i'm doing it right now.
hahahahahah. wow. you are comparing SHA256 ASIC's and blowfish? hahaha. the former is everywhere, the later is in the realm of theory. i'm really surprised you are sticking to your guns here considering the depth of information there is on this topic on the internet. You haven't read the original bcrypt paper, have you, because it has an entire section on this very topic.
I don't think i've ever found myself arguing for bcrypt and scrypt over sha256, this is great.
From here: http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage
and here: http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt/1561245#1561245
You can also read the links I sent to BlueVM so that he could get a handle on the topic.
OWASP only mention SHA in the context of HMAC
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
"You are probably storing your passwords incorrectly"
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
talks about how hash(salt+password) is weak and why you should bcrypt
"SHA-512 has had in-depth reviews by NIST and others. It's good, but flaws have been recognized that, while not exploitable now, have led to the the SHA-3 competition for new hash algorithms." .. "Even though bcrypt as a whole hasn't had as much scrutiny as Blowfish itself, I believe that being based on a cipher with a well-understood structure gives it some inherent security that hash-based authentication lacks."
"No. Use Bcrypt. Always."
https://news.ycombinator.com/item?id=2004962
SHA256 is one of the fastest hash algorithms
http://www.cryptopp.com/benchmarks.html
you are making this up. if you do link to a 'security expert' who has said this then ill posit that they aren't a security expert - because that just demonstrates a complete lack of understanding of how bcrypt works. you realize that everything has a limit, right?
I'm trying to understand what perspective you are arguing from, because you seem to be arguing very strongly from your point of view. You can't be a security guy, because if you were you'd know that b/scrypt is the in vogue thing now and there has been plenty written about breaking and migrating from sha. So are you are admin/programmer that hangs out here and knows a little about security and has always been the resident expert but now you feel like your turf has been invaded because people who work in security have shown up? that must be it.
Being the resident security expert in the VPS hosting field is not something I would be proud of. This entire sub-culture is riddled with poor security practices. Now that I have found it, I don't think I can leave it until I do at least something to fix it. I've audited three pieces of popular software in the past three weeks, all three of them have very simple and exploitable bugs.
I hope you realize that as soon as someone makes a rainbow table for bcrypt, it will have the same flaws as any other algorithm/scheme mentioned here?
And I hope you realize that making a rainbow table for SHA256 with a global salt is difficult enough, let alone 50000 rounds of SHA256, let alone with a user-specific salt as well? Essentially you'd have to "make a rainbow table" for every single user (aka: bruteforce every single user) unless you HAPPEN to have a collision in your rainbow table of choice.
Blowfish is listed at 58MiB/s. (It doesn't list bcrypt as far as I see, but I assume they're similar.) That's 59392KiB/s.
SHA256 is listed at 111MiB/s. That's 113664KiB/s.
50000 rounds of SHA256 is therefore 2.27KiB/s. (Making some truly naive assumptions, but regardless).
Just because you can find links saying bcrypt/scrypt are awesome doesn't mean they are popular. Just because they are popular doesn't mean they are good.
Everything I've seen has been in reference to unsalted or single-run SHA. And yes, unsalted hashes are idiocy (with any hash). And yes, single-run hashes are idiocy (with any existing hash). Those will always be easy to bruteforce/rainbow.
tl;dr Unsalted single-run SHA != salted 50000 run SHA.
SCrypt does have options to make it "safer". It can be tuned and tweaked. Prefer SCrypt. It's slightly better than BCrypt for now.
nice interface @Bluevm..
Did you intentionally not read the links I posted in the last response? The title of the paper which created Bcrypt is A Future-Adaptable Password Scheme. Do you know what they are referring to as happening in the futre? Greater computing power and storage capacity that can be aimed at cracking passwords. Bcrypt was specifically designed to prevent this, and the paper explains in detail how, for eg.
and
and
Seriously, read it. It will answer your question (more accurately, correct your statement) about rainbow tables and bcrypt. You can't think of Bcrypt in the same way you think about SHA.
50,000 rounds slows down SHA, but it doesn't future proof it. It was only a few years ago that I thought 1,000 rounds of SHA was intimidating, now you can blow through it. That is the entire point here, if you started with SHA today and did 100,000 rounds it will slow down a cracker but when the database is hacked and dumped in 5-6 years time (or at the rates we are going, in 18 months) it doesn't stand a chance.
This is specifically what BCrypt was designed to prevent.
Hashing the SHA value again and again is a dirty way to attempt to introduce 'work' - something that BCrypt handles properly (by specifying a work factor, rather than a hard number of rounds).
There are two separate issues here that need to be distinguished - one is rainbow table based attacks and the other is GPU or brute-force based attacks. SHA is vulnerable to both, BCrypt is vulnerable to neither.
You only need one rainbow table. What is better and more adaptable is because SHA is so fast on modern GPU's or GPU clusters you can iterate tens of thousands of hashes per second.
Crypt is open to implementation errors that Bcrypt solves. For eg. picking a salt. Left up to the user errors can be made. I recently had a password database from a real-life commonly used web application that unintentionally trimmed the salt. When we setup the crack all we had to do was extract that global salt and then run the password dictionary and mutations against it - 60% penetration after 24 hours.
From what I see, it prevents it by changing implementation details. Which essentially means it's no better than SHA. "tunable" "adaptable"
What. Sure, if it contains a value for every possible hash. I have yet to see one that does so. This still applies to bcrypt by the way.
Sure. And the same thing is true with bcrypt: what if I did, say,
$cryptpass = bcrypt($pass); $db->insert($pass);? You do not fix user error by providing a new thing for the user to use. You fix errors by educating the user.http://pastebin.com/2Kyh8VXn
Now you have.
As I mentioned before, scrypt is pretty new and is currently lacking the intensive peer review that other hashing algorithms have had.
It's not a pissing match! Everybody has his own way of discussing certain things. Some people are more direct and black-and-white while having a discussion, others are fifty shades of grey, etc. It's nice to have a good discussion about this subject, let's not make it personal :-)
On-topic: I've seen a talk by Anthony Ferrara on PHPBenelux 2013 about passwords and PHP. Ever since I've been keeping track of him and he's got some interesting stuff. He wrote password-compat, which is a proper implementation of bcrypt in PHP (which is also in PHP 5.5). Today, after reading this discussion, I also found this: http://blog.ircmaxell.com/2012/12/seven-ways-to-screw-up-bcrypt.html. Thought it was interesting to share :-)
Actually that is off-topic as this is about @BlueVM's control panel, hehe
lol, true, you got me there ;-)
At the end of the day this is just about buying your users time to change their pass words in the event of a breach-imho.
And to be considerate of eventual changes in the progression of hardware. That is really the only reason I would opt for a cipher using a more arbitrary work factor vs hard set crypto/hashing. Hard set in the scope of your algo that is. I read an article a while ago that explained how mid grade hardware can hit I forget how many million SHA-1 computations per second. And that was years ago. We're well beyond that now and while I wouldn't proclaim to know nearly what you guys do on security related analytics I think Moore's Law is one of the reasons why bcrypt was designed to be slower-Scalabity.
When I first heard of bitcoin, how you earn by cracking hashes I thought it was some password cracking network, haha. And hell, if it was...
A massive +1 if you successfully bring this to market. Literally any competition to SVM is good for the market as a whole.
Wow, what a thread...
Let me start off by saying this: CRYPT_SHA256 is plenty fine, especially with 50k rounds as is implemented here. Jumping all over them for not using BCRYPT is rather like yelling at someone who made $495 million this year because they could have made $500 million. Sure, it's likely worth saying, but it's also missing the bigger picture.
Yes, BCRYPT is "stronger" than CRYPT_SHA256. Primarially because it's slightly more resilient to GPU based attacks today (note slightly). It's at best an order of magnitude stronger, which on the surface is significant, isn't really all that much in practice. It's INFINITELY better than just MD5() or SHA1(), so let's be realistic here.
As for those who say BCRYPT isn't the magic pill, it's not. It's absolutely not. It has issues (but all crypto does). But it's still measurably stronger for almost all cases than CRYPT_SHA256. If I was developing a new app, I would recommend BCRYPT. If you're already using CRYPT_SHA256 with a decent cost, there isn't that much incentive to switch.
As to the BS hype about "BCRYPT CUTS OFF AT 72 CHARS, AVOID AT ALL COSTS", it's definitely a design error. But it's not the massive hole that some here (and elsewhere) imply. Check this out: http://stackoverflow.com/questions/16594613/how-to-hash-long-passwords-72-characters-with-blowfish/16597402#16597402
And let's do some math here. At a low entropy password (like a passphrase), you're going to average about 2.3 bits of entropy per character. For the 72 character limit, that's about 165 bits of entropy.
To put that into context, that's 4.6e49 possible low entropy passwords. Not counting randomly generated ones. Just counting "passphrases" either picked by a human or from text. To brute force that at current bcrypt record breaking rates (against a cost of 5, 1/2 the recommended work factor) would take an enormous amount of time.
The fastest cluster today can attack bcrypt (5) at about 75000 hashes per second. At that rate, you're talking 4,394,089,519,757,680,194,535,384,806 times the age of the universe (1/2 that for a 50% chance)...
A better algorithm will definitely take into account the 73rd and further characters. But in practical terms this is still plenty strong enough.
So at the end of the day, I'd suggest tackling bigger issues. My recommendation would be to consider switching to bcrypt, but don't feel like you have to. CRYPT_SHA256 is still plenty strong...
Anthony
You say that about anything that'll make money for you in the long run.
I can't blame him if he were. I could have done the same if I were in his shoes :-)
>
I think that is the point exactly. Not using md5 and sha1 is already a huge leap forward. If you add a decent cost to either SHA256 or Blowfish, you'll definitely be fine for some years to come.
Even if you choose a certain cost now, you can always rehash the passwords later (for example, upon user login) with a higher cost. So using crypt with a decent algorithm (or password-compat) would be a real future-proof option.