[Xk]

> The real solution is site security not password security.

That does not imply you don't worry about it though -- it's defense in depth. In the same way sometimes you'll need to go through two sets of doors locked with different keys to access a secured server room (or anything else, for that matter), it's worthwhile to protect everything you can as best you can.

> They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security.

Exactly my point. That's why you use bcrypt.

> For how long? 4-5 years? Who will be maintaining your site then?

First, the premise of that question is that bcrypt is going to be secure for only 4-5 years, which is entirely wrong. You can modify the work factor on bcrypt as time goes by. I could, for example, make it take twice as long to generate a hash every year. I could have the program do this automatically. As for you actual question, which isn't terribly relevant, either (1) me or (2) the next guy, who I hope will have knowledge about security as well, but if he doesn't, then I just have to hope he'd keep the workfactor increases in the code.

[derrickpetzold]

That is fair enough and all your points were very good. However despite the down votes and everything else I stand by what I said. As a user I doubt most devs are as competent as the ones here and I would never trust a site with a password that I depend on. Do that there would need to be third-party auditing to make sure that they adhere to the standards you described.

I guess what I am really trying to say is that the state of web/Internet security is very poor right now and I don't believe bcrypt is worthy pursuit (sorry I am really not trying to troll). Since Mt.Gox was just hacked my salted password is on pastebin and then someone attempted to break into my gmail account but that will never happen because I use two factor authentication.

Maybe that is the best solution to all of this.

[caf]

While it is certainly a good idea, as a user, to assume that the site developers have done things wrong (and therefore choose a strong, random, unique password), it is also a good idea, as a site developer, to assume that your users are doing things wrong (and therefore choose a strong password hashing method).

[derrickpetzold]

Security through obscurity is never a good idea because it leaves a false sense of security.

I know I am getting totally destroyed here by the down voting and I'll probably end up in negative karma for this but I standby all of it.

[caf]

I am not advocating security through obscurity.

I am saying that your advice is appropriate for users (who cannot control what the server does) but inappropriate for servers (who cannot control what the user does).