Обсуждение: password encryption

Поиск
Список
Период
Сортировка

password encryption

От
Stefan Fiel
Дата:
hi

i like to store passwords for a webapplication in my postgre database.

now i'm searching for a way to encrypt the passwords, something like the
function password() for mysql.

Does anyone know if there exists something for postgre ? if not, has anyone
another idea how i can store the password ?


thanks

STEFAN



Re: password encryption

От
Tim Ellis
Дата:
> i like to store passwords for a webapplication in my postgre database.
>
> now i'm searching for a way to encrypt the passwords, something like the
> function password() for mysql.

I always run my passwords through md5sum(), which is an open source
implementation, and thus seems to've been written in every language out
there.

--
Tim Ellis
Senior Database Architect
Gamet, Inc.

Re: password encryption

От
Klaus Sonnenleiter
Дата:
To protect your passwords effectively, you probably want them encrypted before
they go on the wire, so you will need to put the encryption capability in the
application, not in the database. This way you will only transmit and store
encrypted data. Take a look at cryptix.org for some pretty good Java and Perl
implementations.

On Wednesday 21 August 2002 05:36, Tim Ellis wrote:
> > i like to store passwords for a webapplication in my postgre database.
> >
> > now i'm searching for a way to encrypt the passwords, something like the
> > function password() for mysql.
>
> I always run my passwords through md5sum(), which is an open source
> implementation, and thus seems to've been written in every language out
> there.

Re: password encryption

От
"David F. Skoll"
Дата:
On Wed, 21 Aug 2002, Tim Ellis wrote:

> I always run my passwords through md5sum(), which is an open source
> implementation, and thus seems to've been written in every language out
> there.

But a straight md5sum leaves you open to a dictionary attack.  You want
to add some salt by doing something like this:

    salt = random_4_char_string;
    encrypted_password = salt + md5sum(salt + cleartext_password);

To verify, just extract the salt from the encrypted password and redo the
calculation.

A dictionary attack is now much less feasible because the same cleartext
password can encrypt to millions of different ciphertext passwords.

--
David.


Re: password encryption

От
Bruce Momjian
Дата:
See contrib/pg_crypto for encryption routines you can load into the
database.


---------------------------------------------------------------------------

Klaus Sonnenleiter wrote:
> To protect your passwords effectively, you probably want them encrypted before
> they go on the wire, so you will need to put the encryption capability in the
> application, not in the database. This way you will only transmit and store
> encrypted data. Take a look at cryptix.org for some pretty good Java and Perl
> implementations.
>
> On Wednesday 21 August 2002 05:36, Tim Ellis wrote:
> > > i like to store passwords for a webapplication in my postgre database.
> > >
> > > now i'm searching for a way to encrypt the passwords, something like the
> > > function password() for mysql.
> >
> > I always run my passwords through md5sum(), which is an open source
> > implementation, and thus seems to've been written in every language out
> > there.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: password encryption

От
Bruce Momjian
Дата:
Never mind what I just said.  I see the issue of encrypting before being
sent over the wire.  We do that for PostgreSQL password, but if you want
to do it for a value before it is sent over the wire, you can use an SSL
connection to the database, or some client-side encryption.

---------------------------------------------------------------------------

Klaus Sonnenleiter wrote:
> To protect your passwords effectively, you probably want them encrypted before
> they go on the wire, so you will need to put the encryption capability in the
> application, not in the database. This way you will only transmit and store
> encrypted data. Take a look at cryptix.org for some pretty good Java and Perl
> implementations.
>
> On Wednesday 21 August 2002 05:36, Tim Ellis wrote:
> > > i like to store passwords for a webapplication in my postgre database.
> > >
> > > now i'm searching for a way to encrypt the passwords, something like the
> > > function password() for mysql.
> >
> > I always run my passwords through md5sum(), which is an open source
> > implementation, and thus seems to've been written in every language out
> > there.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: OT: password encryption (salt theory)

От
Tim Ellis
Дата:
> But a straight md5sum leaves you open to a dictionary attack.

Of course. I argue everything does.

> You want
> to add some salt by doing something like this:
>
>     salt = random_4_char_string;
>     encrypted_password = salt + md5sum(salt + cleartext_password);

I've always wondered about this. It just means for a dictionary attack,
instead of:

if (encpass == md5sum (dictionaryword))

you do

if (encpass == substr(encpass,4)+md5sum(substr(encpass,4)+dictionaryword))

Which obviously is just linearly slower than the normal dictionary attack.

What is the purpose of the salt in this case? I can only assume the
standard documented of using a salt is wrong, because I've never seen an
implementation that I could see increased the security over plain
hashing.

The only way I could see a salt increasing security is thusly:

salt = SomeSuperSlowAlgorithm (password)
encpass = md5sum (salt + password)

But you'd achieve as much by saying encpass=SuperSlowAlgo(password).

No matter how you obfuscate it, unless you can somehow turn it into a
O(x^n) problem, you're prone to dictionary attacks.

This is why most modern password-prompting algorithms do a "dictionary
attack" on your password and worn you. Witness:

    Changing password for user postgres.
    New UNIX password: (I enter "greatone")
    BAD PASSWORD: it is based on a dictionary word

So basically, your only hope is to either obfuscate the argument you pass
to md5sum (or whatever hash algorithm), somehow protect your md5sum list
of passwords(note that the shadow password file on Unix systems isn't
world readable), or ensure that all passwords entered by all users are not
attackable by a dictionary attack.

Can anyone explain to me why a salt is really a good idea or if, as I
suspect, it was an idea with good intentions that really doesn't help
anything?

--
Tim Ellis
Senior Database Architect
Gamet, Inc.

Re: OT: password encryption (salt theory)

От
"David F. Skoll"
Дата:
On Wed, 21 Aug 2002, Tim Ellis wrote:

> Of course. I argue everything does.

Ah, here's what I meant by a dictionary attack:

You precompute (offline) encrypted versions of your dictionary.  This
can be very slow; doesn't matter.  You just burn a CD or DVD with a
database mapping encrypted -> cleartext.

It's this precomputation attack which a salt thwarts.  A salt makes
it impractical to build up a dictionary of encrypted -> cleartext
mappings, because a given cleartext has millions of encrypted
equivalents.

> No matter how you obfuscate it, unless you can somehow turn it into a
> O(x^n) problem, you're prone to dictionary attacks.

A dictionary attack as I understood it means the kind of precomputed
encrypted-to-cleartext lookup table I described above.  If you do your
mapping offline, you have the luxury of using an enormous set of
possible passwords with no computational penalty when you actually
carry out the attack.

--
David.


Re: OT: password encryption (salt theory)

От
Bruce Momjian
Дата:
We use salt in our MD5 implementation.  One is random and prevents
playback of packets.  The second is salt used for storage in pg_shadow.
As long as the salt is visible to the user just like the MD5 version of
the password, we don't see any advantage to a random salt.  We use the
username as our salt for storage just so that two people with the same
password don't show the same MD5 output in pg_shadow.

---------------------------------------------------------------------------

Tim Ellis wrote:
> > But a straight md5sum leaves you open to a dictionary attack.
>
> Of course. I argue everything does.
>
> > You want
> > to add some salt by doing something like this:
> >
> >     salt = random_4_char_string;
> >     encrypted_password = salt + md5sum(salt + cleartext_password);
>
> I've always wondered about this. It just means for a dictionary attack,
> instead of:
>
> if (encpass == md5sum (dictionaryword))
>
> you do
>
> if (encpass == substr(encpass,4)+md5sum(substr(encpass,4)+dictionaryword))
>
> Which obviously is just linearly slower than the normal dictionary attack.
>
> What is the purpose of the salt in this case? I can only assume the
> standard documented of using a salt is wrong, because I've never seen an
> implementation that I could see increased the security over plain
> hashing.
>
> The only way I could see a salt increasing security is thusly:
>
> salt = SomeSuperSlowAlgorithm (password)
> encpass = md5sum (salt + password)
>
> But you'd achieve as much by saying encpass=SuperSlowAlgo(password).
>
> No matter how you obfuscate it, unless you can somehow turn it into a
> O(x^n) problem, you're prone to dictionary attacks.
>
> This is why most modern password-prompting algorithms do a "dictionary
> attack" on your password and worn you. Witness:
>
>     Changing password for user postgres.
>     New UNIX password: (I enter "greatone")
>     BAD PASSWORD: it is based on a dictionary word
>
> So basically, your only hope is to either obfuscate the argument you pass
> to md5sum (or whatever hash algorithm), somehow protect your md5sum list
> of passwords(note that the shadow password file on Unix systems isn't
> world readable), or ensure that all passwords entered by all users are not
> attackable by a dictionary attack.
>
> Can anyone explain to me why a salt is really a good idea or if, as I
> suspect, it was an idea with good intentions that really doesn't help
> anything?
>
> --
> Tim Ellis
> Senior Database Architect
> Gamet, Inc.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: OT: password encryption (salt theory)

От
"David F. Skoll"
Дата:
On Wed, 21 Aug 2002, Bruce Momjian wrote:

> As long as the salt is visible to the user just like the MD5 version of
> the password, we don't see any advantage to a random salt.

The only advantage is that there are likely to be more possibilities for
random salts than for user names.  Again, if you're mounting an offline
dictionary attack, you could probably come up with user names likely
to appear (postgres?  httpd?  apache?) which would expand your dictionary
only by a factor of 5-10.  Random salts would totally thwart this approach.
Plus, they can mask the fact that two users with the same name but in
different PostgreSQL installations have the same password.

--
David.


Re: OT: password encryption (salt theory)

От
Tom Lane
Дата:
Tim Ellis <Tim.Ellis@gamet.com> writes:
> Can anyone explain to me why a salt is really a good idea or if, as I
> suspect, it was an idea with good intentions that really doesn't help
> anything?

I believe the original purpose was to make it less obvious whether two
Unix users had the same password.  (Alice reads /etc/passwd, notices
that her password entry is the same as Bob's, trivially logs into Bob's
account.)

The small range of salts in the original implementation was, well,
appropriate for machine resources of the day.  These days you want
a few more random bits in there.  But the idea is not wrong merely
because there are threats it doesn't guard against.

            regards, tom lane

Re: OT: password encryption (salt theory)

От
Tim Ellis
Дата:
> > Can anyone explain to me why a salt is really a good idea
>
> I believe the original purpose was to make it less obvious whether two
> Unix users had the same password.

Ah, plus, as was also pointed out, the attacker cannot precompute a
dictionary attack -- she must do a dictionary attack PER PASSWORD, not per
password file.

This all makes sense. Conclusion: Salt is good. Random salt is best. Any
salt is better than no salt. Thanks for clarifying it, everyone.

--
Tim Ellis
Senior Database Architect
Gamet, Inc.