Don't get me wrong, I strongly believe in storing user data safely, and especially passwords, hence my original question. But as I mentioned, I'm basically trying to protect a customers email address at this point. So if the attack vector I'm defending against is someone having direct access to the DB, whether physical or dumped. Then they already have the email addresses I'm trying to protect. So I'm paying to protect a password that will be superfluous.
I do hear the message to plan ahead, but looking at bcrypt, it seems like I could scale the cost factor as and when data becomes more valuable, or when it becomes a killer app ;) It even has a method there to determine the cost from the previous hash which seems designed for that task? Since I'm guessing it's not been added to help determine brute force efforts :) and now that I know the 'x' stuff is internally developed I feel more comfortable using it. In the case of client side hashing, I'm worried about clear text passwords ending up in log files or some such, as just happened with fb last week. Since I have no control over the data between the clients, and the hosted execution environment. This may possibly be the weakest link, or a debug statement left in code that accidentally does the same... Thanks all for your feedback, Peter -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
