Christopher Browne wrote:
It does not have to be locally on the system. If I wanted to secure such a system, I would have a private key for decrypting the files stored in a directory server (LDAP or something) in a user or group record. This would allow only authorized individuals to mount the drive. If it has to be highly available, you could also use a machine key to authenticate and obtain the key, which would then be stored in a temporary file. Granted if someone wanted to, they could impersonate the machine and get the key, but it would be a bit more work.Why do you think that's useful in limiting vulnerability?
In order for the system to mount the filesystem, the key has got to be there.
In general encrypted filesystems are better at limiting the ability to mount the drive than they are the ability to secure a highly available system against a determined attacker. Of course, security against the most determined and knowledgable attacker may be a pipe dream anyway....
When I started writing HERMES, I decided to use database native accounts to enforce permissions. As HERMES is web-based, the authentication must occur in every http request. This means that the login and password must be stored somewhere. I toyed with the idea of encrypting the information but decided not to for exactly the reasons that you mention. Indeed I decided that it was better to have the passwords cached in plain text so that the admin would decide to protect them rather than offer a false sense of security by encrypting with a key which an attacker could steal.
This is a big problem: You can't just apply cryptography onto things
like you would add peanut butter to a sandwich and expect to actually
get security. It is eminently easy for a cryptographic system to only
provide the _impression_ of security.
In the end, I decided that separation of data was a better strategy toward securing the application than encryption. In this case, the login is stored in a cookie, and the password in a PHP session variable. The idea was that the cookie could be read or the session variable, but putting them together would require reading both.
My strategies in web application security can be summed up in the following ideas:
1) Separate sensitive information so that it cannot be easily put together. (this is app level and not usually db level)
2) Push security enforcement back as far as possible. Let the database server maintain its security. If it can be exploted, you are toast anyway.
Best Wishes, Chris Travers Metatron Technology Consulting
begin:vcard fn:Chris Travers n:Travers;Chris email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
