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

I'm developing a site right now in which I capture plaintext passwords on sign up within a separate table and then offload that data on an hourly basis to backup so that in case I ever need to change from BCrypt to some other encryption scheme, I have the plaintext passwords to easily make the switch. The passwords are never going back into the production db and someone would need to get physical access to my in house backup server to get these passwords.

From a customer service standpoint, I don't plan to ever let people know I am doing this because they will try to call me out on being evil about it.



You probably don't need to do this depending on why you think you might change encryption schemes. If the idea is just to upgrade to a stronger encryption scheme, you can do so by using BOTH going forward.

For example, if your passwords were stored in MD5 and you wanted to switch to SHA1, you could just make your new hashing scheme the SHA1 hash of an MD5 hash.


Why not just authenticate against the existing encryption scheme and then encrypt into the new scheme on the next log in?


I second this. Storing plaintext passwords seems like a huge liability, especially since you just announced it on a public forum ;)


Switching encryption schemes is rare. Why not just force a password reset on all users at that time?


Keeping something secret because it is evil does not dilute the evil.




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

Search: