Обсуждение: Encrypted column

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

Encrypted column

От
Ranieri Mazili
Дата:
Hello,

I need to store users and passwords on a table and I want to store it
encrypted, but I don't found documentation about it, how can I create a
table with columns "user" and "password" with column "password"
encrypted and how can I check if "user" and "password" are correct using
a sql query ?

I appreciate any help

Thanks

Ranieri Mazili

Re: Encrypted column

От
"Gary Chambers"
Дата:
> I need to store users and passwords on a table and I want to store it
> encrypted, but I don't found documentation about it, how can I create a

Take a look at the pgcrypto user-contributed module.

-- Gary Chambers

// Nothing fancy and nothing Microsoft!

Re: [GENERAL] Encrypted column

От
Joe Conway
Дата:
Marko Kreen wrote:
> On 6/5/07, Brian Mathis <brian.mathis@gmail.com> wrote:
>> pgcrypto also supports md5, so I'm not sure what you're referring to
>> here.
>
> digest(psw, 'md5') vs. crypt(psw, gen_salt('md5'))
>
>> As I already mentioned, *salting* before you hash is a very
>> important step.  I'm not sure if you saw that in my post.  Without a
>> salt, it's trivial to generate a list of all combinations of md5'd
>> strings and their results, up to reasonable lengths.  Then it would be
>> very simple to look up each hash and get the original text.  With a
>> salt, you need to generate all possible md5s for all possible salts --
>> a much harder task.
>
> I dont think its practical method tho'.  Rather, when doing
> dictionary-based or bruteforce attack, then if hashes do not
> have salts you attack them all at once.
>
> But if they have salts then for each word you try you need to
> hash it for each salt.  Which basically gives the effect that
> each hash needs to be attacked separately.
>
> In case of attacking one hash the salt does not matter,
> only the algorithm counts then.  In that case as i said,
> event salted md5 is weaker than des-crypt.

The best method as far as I understand it is HMAC
(http://www.faqs.org/rfcs/rfc2104.html).

It has some significant cryptanalysis behind it to ensure it does not
leak information that would compromise the password. Even MD5 and SHA1,
which have been shown to have certain weaknesses, are not at issue when
used with HMAC (see, for example, section 3.1.1 of
http://www.apps.ietf.org/rfc/rfc4835.html)

The way you would use HMAC is:
1. generate a random token, whatever length you want (the salt)
2. use HMAC (implemented with either md5 or sha1 or something newer) to
    hash the salt with the password
3. store the salt and the resulting HMAC hash
4. on login, calculate the HMAC of the token using the provide password,
    and compare to the stored hash

pgcrypto appears to support HMAC. It is also relatively easy to
implement on top of the built in md5 function if you'd rather not
install pgcrypto. And I'm sure there are HMAC functions available that
could be used in PL/Perl and/or PL/Python.

Joe