4 ms·
Since the whole system turns on having a hardened system which can distinguish honey from true passwords, it seems like you could get a significantly improved l
by cheald 14y ago
Since the whole system turns on having a hardened system which can distinguish honey from true passwords, it seems like you could get a significantly improved level of security by replacing it with a hardened system that hashes passwords with a secret, long pepper, which vastly increases the amount of time necessary to crack even trivial passwords.
The alarm trip is nice, but if you assume that you have a
hardened black box that you can put data into and get data out of, you could use that to increase the complexity of the given hashes to a degree that they would be uncrackable (offline) in the first place, and standard throttling (and alarming) makes online brute-force attempts trivially detectable and blockable.
Assume that you have a user whose password is "1234", and the salt is "5678". Let's assume the system is naive and uses SHA1 for hashing.
Given these two pieces of information, that password is trivially crackable. Not a problem. However, let's now assume that we take our password and feed it to our black box, which hashes it with a 1024-bit pepper, and feeds the resulting hash back to the web app. Assuming the pepper's secrecy is protected, the password's complexity is now so ridiculous that even with all the computing power in the world, you wouldn't be able to brute-force the hash for the password "1234" before our sun explodes.
Now your passwords are mathematically protected against breach, which is arguably more valuable, since it means that the attacker can't take my email address and my six honeywords + real password and plug them into various sites trying to get a hit - those other sites won't know which are the honeywords, and won't trip any alarms when the wrong ones are used, but given the tiny quantity of passwords to try, attackers are sure to get hits. Why not just prevent them from ever discovering a usable password in the first place?
Or, if you wanted the honeypot aspect to be preserved, make your black box take a password, perform some transformation on it, then hash it. For each user, we'll generate and store (in the black box) a one-time pad that we use to transform (/encrypt) their password, then hash it. Password complexity isn't affected, but without the pad, the original password is unobtainable. My bad user uses a 4-character password "abcd" which maps to "hvz5", which I then hash. An attacker who steals the hash list can brute-force "hvz5" easily, then attempt to log in with it, and my system can detect an that the attacker is attempting to log in with a transformed (and thereforce, obviously derived) password and raise the alarms. The system allows for detection of compromised logins without ever risking exposure of the user's actual password to an attacker.
- tptacek 14y agoArgh. The whole concept of "peppers" begs the question. If you can keep attackers from learning a "pepper", keep the attackers from learning the password hashes too. Problem solved. The reality is that attackers learn password hashes when they pop a database. They don't get them from XSS attacks an they don't get them from CSRF bugs. When attackers pull password hashes, they've got the database. When attackers get your database, they have your server. It's over. Stop pretending. Your database server has vulnerabilities, even in the (extraordinarily unlikely) event that you've configured it perfectly so that the ability to issue a SQL query doesn't hand over the filesystem to an attacker. But more importantly, your app server has a whole new class of vulnerabilities once it can't trust the database anymore. People who talk about relying on secret keys in their password hashing schemes are doing the world a disservice. Just use a strong adaptive hash and move on.
- marshray 14y ago> When attackers get your database, they have your server. Could you please link me to more info on this escalation vector?
- simcop2387 14y agoI don't have it in the context of an escalation, but if they can get the database to make a new stored procedure, http://www.mssqltips.com/sqlservertip/1263/accessing-the-windows-file-system-from-sql-server/ http://www.mssqltips.com/sqlservertip/1263/accessing-the-win... then they can usually do a very large amount of things
- cheald 14y agoI agree - I prefaced the whole thing with the assumption that we have a hardened black box that we want to split authentication responsibilities with and can trust to not be compromised, since that's a fundamental assumption of the honeywords concept. If the whole thing is compromised, it's game over, no matter how your auth scheme is split up.
- pbhjpbhj 14y ago