Re: How passwords can be crypted in postgres? - Mailing list pgsql-general

From Gordan Bobic
Subject Re: How passwords can be crypted in postgres?
Date
Msg-id 008501c07566$06ed41a0$8000000a@localdomain
Whole thread Raw
In response to Re: How passwords can be crypted in postgres?  ("Gordan Bobic" <gordan@freeuk.com>)
List pgsql-general
> 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.

[snip]

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

I was referring to a different aspect of security. I was referring to
preventing more of a "man-in-the-middle" type of attack. If you have a
packet sniffer somewhere between the client and the server, then someone
could read your packet containing the encrypted password and use it to
authenticate to the server, without knowing or caring what the real
password is. If you can send the encrypted password to the server that
matches, you're in.

One way to secure this sort of setup is by using RSA-type algorythm where
both client and server get to share a secret without actually transmitting
any part of the actual key. This coupled with some form of authentication
that would eliminate the man-in-the-middle attack (which would make that
system voulnerable as well, because if someone is running a proxy in
between you, they would also potentially know the shared secret) should
bolt the system down completely. One obvious way to work around this all is
to use public key cryptography such as PGP, which would remain secure as
long as the private keys remain secure.

But, the level of security required largely depends on what you are doing,
and what sort of attack you want to protect yourself against...

Regards.

Gordan


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Testing for null value in arrays
Next
From: François LODIER
Date:
Subject: hotow cast text * in char * ?