Yeah, that's why I said "essentially" instead of "totally". Writing your own MAC is not a good idea, pretty much full-stop. tptacek has talked about this[1] before. In the sort of environment that necessitates stupid hashing, if your database is owned your app is owned anyway.
If bcrypt isn't an option, you straight-up need a better platform. It's inexcusable to refuse to protect your users--if you're not using bcrypt/scrypt/PKBDF2 you're mistreating your users.
I know at least one major security company (that deals with Fortune 500 companies) is recommending having an extra key inside the app server, distinct from the database, since there are situations where someone can get the a copy of the DB and not your server.
The fact that they're big doesn't mean they're right, of course. But I know I've seen a bunch of news stories about DB leaking and I haven't seem a bunch about the source code to the website leaking. (Obviously there is some confirmation bias there.)
For sure, and I've done similar myself in the past, but let's be real here--they actually have app/DB separation in those cases. They're definitely not running on Google App Engine, where it's much more likely that they're getting data through an exploit in your app than by getting ahold of the database.
For the 99% case, 'pepper's are illusory security.
And you should still be using bcrypt. (Or PKBDF2, or scrypt, whatever. Just not something where a "pepper" actually ends up mattering.)
> And you should still be using bcrypt. (Or PKBDF2, or scrypt, whatever. Just not something where a "pepper" actually ends up mattering.)
As I said, you can't use any of these on Google App Engine. They're not provided by the platform, and you can't upload them yourself because they use C.
Citation needed. There appears to be a case where it could prove to be an advantage: http://security.stackexchange.com/questions/3272/password-ha...
> And you should be using bcrypt anyway.
Yeah, except bcrypt isn't always an option. Eg: on Google App Engine.