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

Bill Moran <wmoran(at)potentialtech(dot)com> Thursday 09 of June 2011 14:44:31
> 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).

I think going with spirit of time SHA-256 should be considered. Personally I
use it sometimes insead of SHA-128. Only one problem may be availibility of
this for all drivers environments.

Regards,
Radek.