4 ms·

It does add security, because now your attacker needs the source code as well, which is probably on a different machine, requiring different login credentials,

by sho 17y ago

It does add security, because now your attacker needs the source code as well, which is probably on a different machine, requiring different login credentials, etc. Every little bit helps and it's a trivial addition to the authentication code. Of course you would not depend upon it solely but it's called defence in depth.

tptacek 17y ago
You can say "defense in depth" about any idea, whether it works or it doesn't. My XOR idea --- which I am going to name "hippo", as in "your passwords should be salted, peppered, and hippoed", is also "defense in depth". To evaluate the efficacy of a "defense in depth" measurement, insert it into an incident disclosure. For instance: "We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because an attacker would also need to have access to our source code in order to learn the secret key needed to mount a dictionary attack against them." Compare to: "We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because the cryptographic algorithm used to create the hashes ensures that it would take over 100 years to complete a dictionary attack against a single password."
- sho 17y ago
  Right, this will be my last response on this, especially as I have already conceded defeat. You just like arguing, apparently. Firstly, even in the first "disclosure" message - the passwords are indeed safe. Because of that "useless" peppering, there is no way the attackers will be able to unmask the hashes. Secondly, if you have configured your database such that it is even possible to perform a select all on Users from the app server account, you are Doing It Wrong. However, you are broadly right. That said - my whole thesis here is that there are no magic bullets. Yes bcrypt is (much) better against this particular attack. But the DB server is not even web-facing and is unlikely to be compromised; the app servers are far more risky. They have access to the plaintext passwords flowing through them. When they are rooted, you're fucked no matter what hashing strategy you chose. And if you have a crooked insider - which as a security professional, you will know is by far the more likely risk - that's where they will strike as well, of course. Your precious passwords will be bcrypt hashed to the DB all right, but Mallory keeps his own plaintext backup, written by the comped bcrypt gem he snuck onto the system looking for a payday. Or whatever. There's a million ways to do it, all of them easier than brute forcing anything. You're focusing on this single scenario to the exclusion of any number of more likely attacks. Despite the hype, "steal-the-user-table" breaks are not common. Anyway. I was wrong, and I admitted it. Use bcrypt, everyone. EOF
  - tptacek 17y ago
    Most web applications will never be "rooted". Many web applications will have SQL Injection vulnerabilities, even in modern frameworks.

by sho 17y ago

tptacek 17y ago

You can say "defense in depth" about any idea, whether it works or it doesn't. My XOR idea --- which I am going to name "hippo", as in "your passwords should be salted, peppered, and hippoed", is also "defense in depth". To evaluate the efficacy of a "defense in depth" measurement, insert it into an incident disclosure. For instance: "We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because an attacker would also need to have access to our source code in order to learn the secret key needed to mount a dictionary attack against them." Compare to: "We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because the cryptographic algorithm used to create the hashes ensures that it would take over 100 years to complete a dictionary attack against a single password."

sho 17y ago
Right, this will be my last response on this, especially as I have already conceded defeat. You just like arguing, apparently. Firstly, even in the first "disclosure" message - the passwords are indeed safe. Because of that "useless" peppering, there is no way the attackers will be able to unmask the hashes. Secondly, if you have configured your database such that it is even possible to perform a select all on Users from the app server account, you are Doing It Wrong. However, you are broadly right. That said - my whole thesis here is that there are no magic bullets. Yes bcrypt is (much) better against this particular attack. But the DB server is not even web-facing and is unlikely to be compromised; the app servers are far more risky. They have access to the plaintext passwords flowing through them. When they are rooted, you're fucked no matter what hashing strategy you chose. And if you have a crooked insider - which as a security professional, you will know is by far the more likely risk - that's where they will strike as well, of course. Your precious passwords will be bcrypt hashed to the DB all right, but Mallory keeps his own plaintext backup, written by the comped bcrypt gem he snuck onto the system looking for a payday. Or whatever. There's a million ways to do it, all of them easier than brute forcing anything. You're focusing on this single scenario to the exclusion of any number of more likely attacks. Despite the hype, "steal-the-user-table" breaks are not common. Anyway. I was wrong, and I admitted it. Use bcrypt, everyone. EOF
- tptacek 17y ago
  Most web applications will never be "rooted". Many web applications will have SQL Injection vulnerabilities, even in modern frameworks.