Re: How passwords can be crypted in postgres?

Gordan Bobic wrote:
>
> > >  [...]
> > > Isn't this just as bad? If you store the encrypted password, that
> doesn't
> > > help you in the slightest in this case, because if you can breach the
> list
> > > of encrypted passwords, you still know what you need to send as the
> > > "password" from the front end to let you into the database.
> > >  [...]
> >
> > If you encrypt the input from the frontend as well and compare the
> > encrypted strings it will not help you to look into the list of
> > encrypted passwords ... or am I wrong?
>
> What problem are you trying to defeat? If you are worried about "sniffing"
> passwords from the traveling packets, then regardless of whether the
> password field carries a plain text password or scrambled garbage, if you
> know where the password field is, you can sniff it. If you are simply using
> this for authentication, then it doesn't matter whether the password is
> encrypted or not. You are still, effectively, transmitting a "password
> string" that is used for authentication.
>
> The security of passwords, encrypted or otherwise is purely reliant on the
> security of your database server that stores the data.
>
> Does that make sense?

Here's a crypted password: 00xNyXeahk4NU.  I crypted it in perl as
crypt(<guessme>, salt).  So what is <guessme>?

The point of a one way hash is that it's, well, one way.  Pretty much
the only way you're going to figure out what password that encrypted
string corresponds to is to brute force it.  Considering that I crypted
a fairly long random string, that could take you a while.  A really long
while, unless you've got a budget orders of magnitude larger than most
people.

If you know the password, and you want to check whether it's correct,
you just crypt it and compare the strings.  Very simple.  There are
different one way hash functions you might use: md5, crypt, sha, etc.

Until the advent of shadow password files, which help defeat brute force
attacks of the type I just mentioned, the /etc/password file has been
readable by everyone.  It really doesn't matter that much if people know
the crypted string.  They still won't be able to authenticate themselves
until they know the real password.

So the problem you're trying to defeat by crypting your passwords is the
problem of someone reading your password file knowing all of your
passwords.

Now if you're dumb enough to send cleartext passwords unencrypted over a
public network, you need some schooling.  And of course any programs
doing authentication need to be secure.  But that's a different problem
altogether.

-Ron-