Re: Encoding passwords

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.

Note that apparently there are some cryptographic weaknesses with
concatenating the salt and the password with the salt in the front, the way
I did it unfortunately :). If I recall correctly, if the salt is short then
attackers only need to attack a subset of the full hash. The salt being a
known plaintext. So some say to concat with the salt at the back. I suspect
a long salt should make the attack far less feasible, or alternatively
XORed the salt with the password or maybe hash multiple times.
Unfortunately I can't seem to find the original article.

I haven't got around to changing my apps. It's not too bad since the fields
allow for different encoding methods - for this reason I suggest you have a
field to store the encoding method too.

So you can have 'NONE' or 'SHA1' or 'MD5' or 'SHA1B' and so on.

That said if hostile people get to the stage where they can read the
encoded passwords, you're probably screwed anyway - they're likely to be
able to do other things some even more undesirable. So it's not really a
big deal compared to other issues.

Cheerio,
Link.

At 08:42 AM 9/25/01 -0400, Mike Arace wrote:
>
>Hey everyone,
>
>Is there a function out there for pg which allows you to generate a random
>number given a seed value? I'm trying to create a users table which would
>require the storage of a password in a database field, and I'm hesitant to
>put it in there in plain text, despite the fact I plan to put very tight
>restrictions on that particular table. Ideally, I would encode each letter
>one by one, using the random number generator with the previous letter