Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I didn't do the math but it sounds right.

But suppose tomorrow it takes 10ms. Also, tomorrow, available spaces will increase, so the likelihood of a space vs time tradeoff (even partial) increases

WEP was considered "good enough" at first (even though it had obvious problems at first like key size), WAP was considered unbreakable at first, today it's feasible with cloud computing or GPUs.

And then we'll be complaining on HN that they didn't use xyzcrypt or something instead of bcrypt.

" it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario"

Yes. Salt is password storage 101!



The time bcrypt takes is configurable, so in the future you can adjust the amount of work per password -- this is literally a one-character change in your code -- and be alright again. Ditto for the rest of the decent password hashing schemes.


True, but you can't really bet on that

Sure, you can increase the work, but you'll still be limited by bcrypt size

Otherwise, you could just MD5 hash stuff X times and be done with it

Sure, bcrypt today is very safe, but I wouldn't be surprised if attacks are found today (even if they rely only on bruteforce)

And let's not forget implementation issues that may happen in specific bcrypt libraries


I think you are propagating the myth that a scheme can be secure forever.

It's ok if WAP is breakable with cloud computing, because the whole point was to secure it for the next X years so that it takes more than Y dollars to break it. You only need to protect million dollar data enough that it costs 10 million dollars to get it.

If the data is valuable enough and protected heavily enough with crypto, the cheapest way to get it is through a meatspace attack (break-in, abduction, etc).

> WEP was considered "good enough"

Not by security professionals once they saw the effective size of the key. It's the downgrading of what looked like a 64bit key into a 48bit key that was the biggest problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: