Re: [HACKERS] Updated TODO list

Bruce Momjian wrote:

> I disagree. Over the wire seems more important than protecting the
> passwords from the eyes of the database administrator, which in _most_
> cases is the system owner anyway.

No,

both are equally important. There is a good reason why even
root cannot see cleartext unix passwords. And there's a good
reason for doing something different over the net (why do we
use ssh when accessing hub.org?).

Well, the sysadmin could run some password cracker against
shadow files. But if I ever notice that Marc uses a brute
force method to crack my ones, I'll take a trip and break his
neck (after breaking every single finger, one by one, hour by
hour - you'll hear him over there).

Hosts I consider trusted ones are hosts where I trust the OS
and the admin. It's O.K. if an admin takes a look into some
files. And if he then finds some of my private xxx pics, so
be it - as long as he doesn't pin them onto the blackboard
under "Jan's private pics". But it's not O.K. if that look
means he'll see cleartext passwords without having to take
extra cracking steps.

To store really crypted passwords in the database, I think
it's required to send cleartext over the wire. So we have to
protect that at least until the authentication is done -
optionally until disconnect.

I haven't found much documentation yet how to use OpenSSL,
and I even don't know if it really is what we need. But it
has an Apache like license (free for private and commercial
use).

If it is what I think so far, it should be possible to enable
ssl during configure and then tell in the hba.conf if
password auth has to be ssl protected. Then we could easily
send cleartext passwords over a protected channel. Thus,
local traffic could be high speed while net traffic is
securely crypted. But the admin decides what "local" means,
so traffic on the backbone net (web-server->db-server) might
be considered secure.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #