Re: Best Practices - Securing an Enterprise application using JBOSS & Postgres

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Isak Hansen <isak(dot)hansen(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Best Practices - Securing an Enterprise application using JBOSS & Postgres
Date: 2011-06-09 12:44:31
Message-ID: 20110609084431.7244f2f7.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>:

> On 09/06/11 03:07, Isak Hansen wrote:
>
> > While MD5 is considered broken for certain applications, it's still
> > perfectly valid for auth purposes.
>
> MD5 rainbow tables can be calculated quickly using services easily
> available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> chars have been successfully used in demo and real attacks several times
> in the last year. It's looking pretty shakey.
>
> That said, _properly_ _salted_ md5 is still likely to be strong enough
> for most people's likely attack scenarios for quite some time to come.
> It's only unsalted md5 that's dangerously stupid to use now - and it was
> never exactly a good idea.
>
> If you do your own user/password storage with a "users" table in the
> database or whatever, make sure you salt the passwords for encryption.

Having recently researched this ...

If you're going to create your own password database, your best bet is
to use the system's supplied crypt() implementation to hash the passwords,
this avoids you having to know everything about safe salting and all that.

Once you've got access to a crypt() (or equivalent) implementation, however,
md5 looks kind of silly. I agree that it's probably strong enough still,
but why bother? Once you have access to crypt() you have a number of
hashing algorithms available, such as the obscenely powerful SHA512. At
that point, the only reasons I can think of to still use md5 would be
compatibility with other systems that can't be improved, or if you're
on extremely limited hardware (like a mobile device).

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vick Khera 2011-06-09 13:35:21 Re: Write performance on a large database
Previous Message Håvard Wahl Kongsgård 2011-06-09 12:15:26 Write performance on a large database