Re: When to encrypt

Christopher Browne wrote:

>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.
>
>
>
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.

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....

>
>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.
>
>
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.

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