3 ms·

I wonder why password tables are readable at all. An application only needs to call a stored procedure that compares the computed hash value against the stored.

I wonder why password tables are readable at all. An application only needs to call a stored procedure that compares the computed hash value against the stored. This stored procedure needs the rights to read the data. No application, no administrator should to be able to read that data.

misnome 13y ago
I suspect it's a side-effect of the fact that web frameworks tend to encourage "pass the database login once and let the framework manage everything", so there is no protection if you manage to get into whatever is running the site.
- sk5t 13y ago
  The "one database login" rule (a.k.a. trusted platform design) doesn't necessitate reading the raw password hashes; the app account can be granted only permission to run a stored procedure that does the comparison yielding a yes/no answer, and denied 'select' on the views/tables/etc.
  - shabble 13y ago
    You should remember to use constant-time comparison when checking for equality in your stored procedure though; do databases typically provide functions/operators for that? It's something just as easy to get wrong in application code, but good frameworks already do, and abstract it away where you might not realise.
Drakim 13y ago
The issue is how you enforce this. Obviously if somebody has root on your server they can just disregard any rules for how the database should be accessed. Maybe by having the database on external hardware with an API, but I can imagine this is hard to scale. What if you need to sync it across several load balancing servers, or what if you want to make backups?
- ExpiredLink 13y ago
  > Obviously if somebody has root on your server ... ... then it's game over for you. But I guess intruders typically use either SQL-injection or somehow get the application password to access the password table. In both cases an unreadable table would thwart the intruder.
  - Drakim 13y ago
    But is it? If the only way your production server can check passwords is by sending hash(salt+pw+salt) and getting a true\false reply from a piece of external hardware...then even if an intruder got complete control though some exploit or injection, he wouldn't be able to dump the database for later cracking with rainbow tables.
    - shabble 13y ago
      You may have just re-invented the Hardware Security Module(HSM)[1] :-) See also [2] for a cute implementation using an Arduino to secure an AWS API key [1] https://en.wikipedia.org/wiki/Hardware_security_module https://en.wikipedia.org/wiki/Hardware_security_module [2] http://stefan.arentz.ca/signing-aws-requests-with-your-arduino.html http://stefan.arentz.ca/signing-aws-requests-with-your-ardui...
- ippisl 13y ago
  >> what if you want to make backups? One can design a special hardware, with a port for just comparing passwords and a port for copying. A Hacker would need physical access to copy the database. >> Load balancing Could be part of the design.Say card in a box, with internal physical connection inside the box for copying.
tptacek 13y ago
This isn't a bad idea at all, but if you lose control of your database, you need to assume you lost control of your app servers and your database server.
marquis 13y ago
postgres provides encryption functions but you still have to take care of your keys.

misnome 13y ago

I suspect it's a side-effect of the fact that web frameworks tend to encourage "pass the database login once and let the framework manage everything", so there is no protection if you manage to get into whatever is running the site.

sk5t 13y ago
The "one database login" rule (a.k.a. trusted platform design) doesn't necessitate reading the raw password hashes; the app account can be granted only permission to run a stored procedure that does the comparison yielding a yes/no answer, and denied 'select' on the views/tables/etc.
- shabble 13y ago
  You should remember to use constant-time comparison when checking for equality in your stored procedure though; do databases typically provide functions/operators for that? It's something just as easy to get wrong in application code, but good frameworks already do, and abstract it away where you might not realise.

Drakim 13y ago

The issue is how you enforce this. Obviously if somebody has root on your server they can just disregard any rules for how the database should be accessed. Maybe by having the database on external hardware with an API, but I can imagine this is hard to scale. What if you need to sync it across several load balancing servers, or what if you want to make backups?

ExpiredLink 13y ago
> Obviously if somebody has root on your server ... ... then it's game over for you. But I guess intruders typically use either SQL-injection or somehow get the application password to access the password table. In both cases an unreadable table would thwart the intruder.
- Drakim 13y ago
  But is it? If the only way your production server can check passwords is by sending hash(salt+pw+salt) and getting a true\false reply from a piece of external hardware...then even if an intruder got complete control though some exploit or injection, he wouldn't be able to dump the database for later cracking with rainbow tables.
  - shabble 13y ago
    You may have just re-invented the Hardware Security Module(HSM)[1] :-) See also [2] for a cute implementation using an Arduino to secure an AWS API key [1] https://en.wikipedia.org/wiki/Hardware_security_module https://en.wikipedia.org/wiki/Hardware_security_module [2] http://stefan.arentz.ca/signing-aws-requests-with-your-arduino.html http://stefan.arentz.ca/signing-aws-requests-with-your-ardui...
ippisl 13y ago
>> what if you want to make backups? One can design a special hardware, with a port for just comparing passwords and a port for copying. A Hacker would need physical access to copy the database. >> Load balancing Could be part of the design.Say card in a box, with internal physical connection inside the box for copying.

tptacek 13y ago

This isn't a bad idea at all, but if you lose control of your database, you need to assume you lost control of your app servers and your database server.

marquis 13y ago

postgres provides encryption functions but you still have to take care of your keys.