4 ms·
I'm curious what threat model this protects against that isn't also trivially covered by bcrypting hashes and then encrypting them with a symmetric key that has
by akerl_ 11y ago
I'm curious what threat model this protects against that isn't also trivially covered by bcrypting hashes and then encrypting them with a symmetric key that has to be provided to the system at boot time by a human or keywhiz or similar. It seems they're trying to protect against an attacker who has DB access but not RAM access, which is a very important vector to consider but this seems to be an overly complex way to handle that.
- deleted 11y ago[deleted]
- aidenn0 11y agoThe paper linked from the article mentions the threat model as disk access, may already know an arbitrary number of passwords, but cannot read RAM, and may need to be rebooted. The alternative solutions does not mention doing what you suggest, but reboots would be problematic. Of course you could do the same thing for bootstrapping as they do (leak a portion of the salted hash to disk and use that for verification), but that I'm pretty sure that allows probabalistic cracking of weak passwords (assuming most passwords are weak, the weakest password that matches is likely to be the password).
- TwoBit 11y agoWhy don't they encrypt entire databases like this, and thus avoid the problems from all these hacks?
- leni536 11y agoWhile I'm not a security expert, but I guess most of the attacks don't copy the database from the disk directly but use the SQL server for that through injection. If the SQL server can read your database (which is mandatory if it wants to work with it) then the underlying disk encryption doesn't help.
- leni536 11y ago> boot time by a human From the paper: > The server will restart periodically. All data kept in memory is lost at this point and the server must restart using only the data on disk – which is attacker visible. So I guess your solution is correct and trivial but the author's solution doesn't use data from outside, not even a user provided symmetric key.
- akerl_ 11y agoIt does use data provided from outside: you either need to provide enough valid passwords for it to recreate the secret, or leak data from the stored secrets, as described here: https://github.com/PolyPasswordHasher/PolyPasswordHasher#if-the-attacker-cant-check-individual-accounts-how-does-the-server-check-the-first-account-after-rebooting https://github.com/PolyPasswordHasher/PolyPasswordHasher#if-...
- leni536 11y agoThey leak data but their threat model involves that the attacker can get this leaked data too (they leak it to the hard disk?). >provide enough passwords Why don't they just store some dummy users' (with zero privileges) credentials directly on the hard drive? They simply can provide valid passwords from it after reboot and your attacker can have these passwords since they can't do anything with them. Maybe their leak strategy involves something like this?
- devit 11y agoIt seems this system uses your scheme, except that instead of getting the key from administrator input, it computes it from the first K passwords it gets using a secret sharing scheme. The advantage is that the administrator doesn't need to manually intervene, the disadvantage is that you can't verify passwords (in a way that is more secure than just verifying hashes) until you get at least K correct login attempts. If the goal is only to defend against SQL injection, a much simpler solution is to just put the key outside the database, for instance in the configuration or source of the application.
- petejansson 11y agoPlease don't ever put keys in the source of an application.