Re: vulnerability/SSL - Mailing list pgsql-general

From Magnus Hagander
Subject Re: vulnerability/SSL
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C7632@algol.sollentuna.se
Whole thread Raw
In response to vulnerability/SSL  (dong changyu <dcy1_1999@yahoo.com>)
Responses Re: vulnerability/SSL
Re: vulnerability/SSL
List pgsql-general
> The EFS encryption as you described it adds nothing but a
> false sense of security (and the ability to use some more
> buzzwords). The level of protection is just the same of a
> Unix file with the right permissions.
> The key point here is that both the 'postgres' user and
> 'administrator'
> have _transparent_ access to the file contents. No password required.

While most of what you wrote is definitly correct, you missed a few
things about EFS.

1) Administrator does not necessarily have *transparent* access. It's
only the users access that is transparent.

2) It is quite possible to remove the administrator recovery key. This
can be used to protect *against* administrators reading the file. You do
*not* need to have *any* recovery key.

2b) It's even so that in Windows XP (and I think 2003), if it is *not* a
member of a domain, there *is* no default recovery key. In a domain,
it's the domain admins key, or whatever is configured in your domain
policy. In 2000, it's the local admin that first logs on to the box.

3) The recommended practice is to have the recovery key only available
off-line, locked into a separate building with half an army defending
it. Or something like that. At least put it in a smartcard that nobody
can access without going through lots and lots of safe checks on who
they are.

So it does offer a bit of extra security. "Just" to protect the key used
to set up the SSL sessions, I'm not sure it's worth it. Because again,
if they hack your admin account, they can get to your files *without*
going thruogh getting into the SSL stream.


//Magnus

pgsql-general by date:

Previous
From: "Ets ROLLAND"
Date:
Subject: Pb with linked tables on PG8
Next
From: Changyu Dong
Date:
Subject: Re: vulnerability/SSL