Hacker News Reader

Comment by drakaal | Hacker News Reader

A calculated value means you need source to figure it out. Only PHP and JS/Node scripters assume that their source isn't safe in an attack. The rest of us assume that our compiled code is safe.

(Over generalization, but if people can get your source code basically there is zero you can do to keep them out)

Storing data in more than one store is a best practice.

Your random 128 bits have to be stored somewhere. That means an attacker needs only the database, not the source. In any large scale environment you likely have multiple machines. When a machine gets taken out of service at your hosting provider your database might still be on it when it hits the dumpster. If your source code is on another machine it doesn't matter.

The same is true of the Private User Data and the passwords. two locations means you need two breaches to do anything.

View on HN

>A calculated value means you need source to figure it out.

As I mentioned in my other post, it really doesn't. Using a calculated value means that the entropy of your salt is only as high as the values used to calculate it.

>Only PHP and JS/Node scripters assume that their source isn't safe in an attack.

So, the vast majority of websites.

>The rest of us assume that our compiled code is safe.

Why would you assume that?

>if people can get your source code basically there is zero you can do to keep them out

If people have your source code, and your passwords are stored properly, they aren't going to have any easier of a time cracking them.

>Your random 128 bits have to be stored somewhere. That means an attacker needs only the database, not the source.

The whole point of a salt is that it doesn't have to be secret.

The cracking community, unlike the bulk of the mainstream programming community, has not lost the art of disassembling executable code. Hiding source code provides negligible additional security.

"Source" or "Execution". Your Database isn't on the machine executing the code.

A breach of your Data should not be a breach of your code.

It still confers a negligible advantage. If the attackers have gotten into your data server, why shouldn't they be able to get into your application server just as easily? All you're doing is slightly inconveniencing the attacker before they can derive your salt wholesale.

Always remember: a secure system is secure even if the attacker can see your source code. Any work you do based on assuming the opposite is a waste of time.

Really? How about because my database server could be something like DynamoDB that I don't own. Why would the execution and the Data server have the same vulnerabilities. The whole reason to have two servers is so that you can say. "The only thing that can talk to the database is a server on the 'Inside'", but injection attacks mean you could possibly exploit the data server with no access to the execution server.

Even so, you're proposing a very low entropy salt. If the attacker can crack one or two weak passwords, they can start limiting their search space immediately, and crack more passwords. As they gain more examples to work with, they will be able to work out how your salt is derived, and then they can start looking for salt collisions based only on the data that is stored in the clear.

At that point, your attacker has not only the ability to derive the salt and attack each password individually, but potentially the ability to generate rainbow tables for subsets of users with identical (or largely identical) derived salts.

The point is that at best, you're adding a term to the overall hardness of the attack. When you use something like bcrypt, you are multiplying the hardness of the attack. There is no comparison between what you've proposed with MD5 or SHA-1 and simply using bcrypt on a random salt, even if the latter has your source code in the latter but not the former.

Reply on news.ycombinator.com