4 ms·

> The web server is compromised. The attacker has the > source code, which includes the IP/host and login > credentials for the database server, since the w

> The web server is compromised. The attacker has the > source code, which includes the IP/host and login > credentials for the database server, since the website > code talks to the database to function. IMO, if internet-facing machine A is storing login credentials to machine B, then machine B should be considered internet-facing. There is no reason for a properly-designed system to be storing passwords or credit card numbers in the same database as the rest of the user's data. Such security-critical data should always be placed on a hardened machine, with the web server communicating via a small and easily-auditable interface.

deleted 14y ago
[deleted]
steveklabnik 14y ago
> communicating via a small and easily-auditable interface ... isn't that called 'a network'? This seems to contradict your earlier statement about 'machine B should be considered internet-facing.'
- jmillikin 14y ago
  It's not a contradiction, because 1) the webserver would not have login credentials to the hardened machine and 2) the interface would be much smaller than "everything in SQL". A typical example of such an interface would expose about four operations: // Return true if the given user/password pair is valid. bool PasswordValid(string user, string password) // Return true if the password was changed successfully. bool ChangePassword(string user, string old_password, string new_password) // Returns a reset token. string RequestPasswordReset(string user) // Returns true if the password was reset successfully. bool CompletePasswordReset(string user, string token, string new_password) With reasonable changes to support two-factor, if needed. Credit card data would have a similar interface -- add card, remove card, list user's cards without full cc#, charge card. The advantages of this over the sort of "hashed passwords in MySQL" design are obvious. Not only is sensitive data protected against "SELECT *", but it's now possible to apply security policies to password management. For example, the password service might enforce rate limiting on how often a particular user's password can be checked -- that way, even if the web server is compromised, the attacker will be unable to compromise passwords any faster than they could via the standard login screen. The password machine would typically be configured to have only the password service and SSH running, with SSH access limited to a key that's stored in a safe somewhere and used only for emergencies. If a developer doesn't feel comfortable building such a system themselves (reasonable), then there are many commercial products available. They're expensive for a home user or ramen-budget startup, but a company like Linode would be able to afford one easily.
  - steveklabnik 14y ago
    That'd still be 'internet-facing' though, by your definition. Yes, it might require one more round of cracking (the simple interface), but the machines are still connected.
    - jmillikin 14y ago
      No, it would not. Please read my post again. The webserver would not have login credentials for the password management machine. Additionally, I object to your implication that any network service can be trivially compromised with "one more round of cracking". This is a view of software security that is propagated by science-fiction movies, and is not grounded in real life. Vulnerabilities that permit remote code execution are relatively easy to prevent by taking appropriate precautions when designing and implementing a network service, and almost every such vulnerability has its root cause in doing something obviously insecure (e.g. writing in C/C++ or a language with eval(), passing user input into an OS procedure).

deleted 14y ago

[deleted]

steveklabnik 14y ago

> communicating via a small and easily-auditable interface ... isn't that called 'a network'? This seems to contradict your earlier statement about 'machine B should be considered internet-facing.'

jmillikin 14y ago
It's not a contradiction, because 1) the webserver would not have login credentials to the hardened machine and 2) the interface would be much smaller than "everything in SQL". A typical example of such an interface would expose about four operations: // Return true if the given user/password pair is valid. bool PasswordValid(string user, string password) // Return true if the password was changed successfully. bool ChangePassword(string user, string old_password, string new_password) // Returns a reset token. string RequestPasswordReset(string user) // Returns true if the password was reset successfully. bool CompletePasswordReset(string user, string token, string new_password) With reasonable changes to support two-factor, if needed. Credit card data would have a similar interface -- add card, remove card, list user's cards without full cc#, charge card. The advantages of this over the sort of "hashed passwords in MySQL" design are obvious. Not only is sensitive data protected against "SELECT *", but it's now possible to apply security policies to password management. For example, the password service might enforce rate limiting on how often a particular user's password can be checked -- that way, even if the web server is compromised, the attacker will be unable to compromise passwords any faster than they could via the standard login screen. The password machine would typically be configured to have only the password service and SSH running, with SSH access limited to a key that's stored in a safe somewhere and used only for emergencies. If a developer doesn't feel comfortable building such a system themselves (reasonable), then there are many commercial products available. They're expensive for a home user or ramen-budget startup, but a company like Linode would be able to afford one easily.
- steveklabnik 14y ago
  That'd still be 'internet-facing' though, by your definition. Yes, it might require one more round of cracking (the simple interface), but the machines are still connected.
  - jmillikin 14y ago
    No, it would not. Please read my post again. The webserver would not have login credentials for the password management machine. Additionally, I object to your implication that any network service can be trivially compromised with "one more round of cracking". This is a view of software security that is propagated by science-fiction movies, and is not grounded in real life. Vulnerabilities that permit remote code execution are relatively easy to prevent by taking appropriate precautions when designing and implementing a network service, and almost every such vulnerability has its root cause in doing something obviously insecure (e.g. writing in C/C++ or a language with eval(), passing user input into an OS procedure).