From: | Marko Kreen <marko(at)l-t(dot)ee> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Mike Arace <mikearace(at)hotmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Encoding passwords |
Date: | 2001-09-28 12:31:57 |
Message-ID: | 20010928143156.A19731@l-t.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Sep 27, 2001 at 02:58:37PM -0400, Bruce Momjian wrote:
> > I personally use encoded password= hash( concat(salt,password)), and store
> > both the salt and the encoded password. Where hash = sha1 or md5.
> >
> > The DB columns are: salt, encoded password, encoding method.
> We have new code in 7.2 that will do MD5 encryption of passwords stored
> in pg_shadow. We add the salt to the front of the password before
> passing through MD5. You are suggesting putting the salt at the end.
>
> I guess the issue is that if you can get the salt part found out, you
> can use that to attack the password part. Also, consider that we use
> the username as the salt as stored in pg_shadow. We can easily put the
> salt in the back, but then there is the risk that a long password would
> not take into account the salt. My feeling that this is more a
> theoretical concern and we may be opening ourselves up to more problems
> if we make the change.
>
> Other ideas?
It does not matter. As you are using only one round of MD5/SHA1
which are quite fast, on very short data, it is very easy to
brute-force it anyway, salt or no salt. Only good solution for
storing short data hashed is to use very slow algorithm, like
crypt-md5 and crypt-blowfish are doing. On crypt-blowfish
you can even 'tune' the slowness by giving number of rounds
to run.
Another idea is stop storing hashes altogether and use protocol
like SRP which stores on server side on 'verificators'. I am
interested hacking PostgreSQL to use SRP, but have not had time
for it yet.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Holger Klawitter | 2001-09-28 13:17:23 | Re: PgSQL behind a firewall |
Previous Message | Nils Zonneveld | 2001-09-28 12:27:48 | Re: TEST DATA GENERATION |