[pLog-svn] New Security Features in Joomla

Matt Wood matt at woodzy.com
Mon Jul 30 09:30:10 EDT 2007


The salt ensures that you have to brute force every single password
individually (increasing the amount of computation required to find them
all) because you have to include the salts. So if you have 20 users, you
have to spend about 20 times more time computing hashes.

It isn't much more secure. In fact I'd say this does nothing, if an attacker
can retrieve the hashes, it is also likely he doesn't need them
(bypass/change).

-Matt

On 7/30/07, Reto Hugi <plog at hugi.to> wrote:
>
> Hi List
>
> I accidently read the release notes for the latest Joomla bugfix release
> and stumbled upon an interesting note:
>
> They changed the way they store user passwords to make them more secure
> (they probably want to adress md5 weaknesses with rainbow tables).
> As we had once a vulnerability where the md5 hash of the admin password
> was revealed due to an sql injection vulnerability I thought it would be
> interesting to know more about the measures the joomla team took.
>
> This is what they do:
>
> // salt is a random 16 char string, no hardcoded secret used
> $salt = mosMakePassword(16);
>
> $crypt = md5($passwd.$salt);
>
> // this will store the string in the database.
> $row->password = $crypt.':'.$salt;
>
>
> Does anybody see where this could improve security? It hardly can
> prevent attackers if an sql injection reveals the password because the
> secret is included in the string after the colon, right?
>
> Oh well, may one of you guys has an idea...
>
> cheers,
> reto
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://limedaley.com/pipermail/plog-svn/attachments/20070730/acee57d9/attachment.htm 


More information about the pLog-svn mailing list