Hacker News new | past | comments | ask | show | jobs | submit login

Basically, encryption allows you to expose data to the public without disclosing its contents by keeping another, usually much smaller, piece of data private (the key).

In this case, your passwords should be private to begin with. If they are accidentally exposed, it's likely that the key is also exposed, so you gain little. You can't hide the key because you need to use it to e.g. authenticate people logging in.

It's a bit like a business keeping all of their cash in a safe to protect it, but because they have so many people who need to access the safe, they basically have to write the combination on the door.

Hashing passwords is like a sealed black box where you can go up to it and say, "Bob is here and claims his password is X, is that right?" and the box will give you a yes or no, but it's extremely difficult to crack it open and get at the actual passwords. Much more secure than the safe, which really does little in this case.




Since they key is almost definitely not stored in the db and is very likely stored fairly securely, why does it follow that "if [passwords] are accidentally exposed, it's likely the key is also exposed"?

I understand that passwords are better hashed I just don't nderstand why encrypted is no better than plain text (according to some).


How do you store the key more securely than the database while still allowing your web apps to access the key whenever they need to verify or change someone's password?


Well, it's common to have db but not file system or codebase access. And it's easy to make a directory readable by only the app.




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

Search: