Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by TjWallas | Hacker News Reader

Parent Full thread

TjWallas·

Some more details from the source:

Password is: "peanuts" Salt is: "saltysalt" Algorithm used: AES-128-CBC The number of KDF iterations is: 1

Edit: Indicate that no. of iterations is for the Key Derivation Function

View on HN

I don't care what anybody says. I still like salted peanuts.

There's no such thing as AES-CBC iterations, it's the number of iterations for PBKDF2-HMAC-SHA1.

I don't know too much about this so I'm a bit confused. What does a salt do if it's the same for everything?

Nothing, it's just that the field is required for the function that's being used for the obfuscation. There's a lot of confused people in this thread. There are no mistakes made in the code, people are simply surprised that there's a mode in which Chromium that only obfuscates the keystore. Adding to the confusion is the fact that they're using an encryption library to do the obfuscation, so people see it and expect there to be real encryption going on and then see the dummy values in the important fields.

Okay, I was wondering if something like that was the case.

Using a salt ensures that an attacker cannot use pre-generated rainbow tables to crack something. If there is no salt, it is very fast to use rainbow table lookups for cracking.

The salt doesn't really need to be secret, as it is only there to make an attacker work harder. However, the existence of a known, hardcoded salt means that an attacker can generate rainbow tables specifically for cracking these cookies, so the salt isn't really useful here.

Salts are almost never secret, in fact; typically the salt is stored in plaintext alongside the hashed password. As you note, that's because the salt is supposed to defeat pre-computed rainbow tables, not be a shared secret.

Reply on news.ycombinator.com