On 12/6/2004 6:10 PM, Greg Stark wrote:
> Martijn van Oosterhout <kleptog@no-spam> writes:
>
>> Actually, hard disk encryption is useful for one thing: so if somebody
>> kills the power and takes the hard disk/computer, the data is safe.
>> While it's running it's vulnerable though...
>
> Where do you plan to keep the key?
>
I was wondering where he keeps his servers. Are they kept under a little
rain shelter on the parking lot, so that one who steels them at least
can't sue the company for hurting his back while carrying the racks outside?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@no-spam #
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@no-spam
x-mozilla-html:FALSE
version:2.1
end:vcard
[plaintext chris.vcf]
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html