Обсуждение: password encryption
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
> 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.
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.
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.
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
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
> 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.
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.
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
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.
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
> > 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.