[WEB SECURITY] Faulty using of MD5 in web applications

Minoo Hamilton minoo at forkbolt.net
Mon Aug 23 16:04:44 EDT 2010


Perhaps, somebody from this list could mention this on the tomcat-dev list?
I've been thoroughly shot-down for suggesting that md5 should be replaced as
the default tomcat session token generation algorithm -- though I admittedly
gave up trying to make the case, when faced with such a warm response.  

Why are manager session tokens generated with MD5 by default? [Thu, 28 Aug
2008]
http://www.mail-archive.com/dev@tomcat.apache.org/msg27073.html

- Minoo

-----Original Message-----
From: James Manico [mailto:jim at manico.net] 
Sent: Wednesday, August 18, 2010 3:08 PM
To: MustLive; Jim Harris
Cc: websecurity at webappsec.org
Subject: RE: [WEB SECURITY] Faulty using of MD5 in web applications

If you ever recommend any use of md5 to your developers, then I withdrawal
your AppSec merit badge. It's a DEAD algorithm, and has been for some
time.

Further reading at:
http://www.win.tue.nl/hashclash/SoftIntCodeSign/
http://isc.sans.org/diary.html?storyid=5590
http://www.globalsign.com/support/md5.html
http://www.v3.co.uk/vnunet/news/2233256/verisign-addresses-ssl-flaw

"It's dead, Jim." - Bones
"Bury the dead, they stink up the place" - Coughlin's Law

- Jim


-----Original Message-----
From: MustLive [mailto:mustlive at websecurity.com.ua]
Sent: Wednesday, August 18, 2010 1:54 PM
To: Jim Harris; James Manico
Cc: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Faulty using of MD5 in web applications

Hello Jim and James!

I'll answer to both of you and latter to Michal and Andre.

I'm glad that many readers of WASC Mailing List drew attention to my last
article. But Michal, Jim and James incorrectly understood it. As I wrote
in
my first answer to Michal. Reading attentively my article and my answer to
Michal with detailed explanation of the topic of my article will help you
to
understand it. In my article I talked not about direct usage of md5 (for
generating of hashes), but about indirect usage (for creating of strings).

> The MD5 without salt is crackable. Everyone knows this.  Add salt and
your
> fine.

Jim. Yes, everyone knows this. And this is not subject of my article - not
about using md5 for creating hashes and cracking it and using salt to make
it harder to crack. I exclusively wrote not about using md5 for hashes -
it's known topic (especially in security community, but developers are
still
using md5 and often without salts), but I wrote about different usage of
md5
function (and hash-functions in the whole), which is less known topic.

My article is about indirect usage of md5 (for creating of strings). I.e.
I
wrote about of using md5 for generating random strings for security
purposes. And as it must be clear for all of you - using of salt will not
help you in this case (at indirect usage of md5). Because the alphabet
will
be the same - 16 chars - so it still will be easy to bruteforce. The same
with using of other hash-functions (with or without salts), as I'll write
below.

> There is no wise use of md5. It's a dead algorithm.

James, in my answer to Michal I showed few cases of wise use of md5 :-).

> Developers need to migrate to the 512 byte version of SHA-2, at least.

In cases which described in my article (small length strings) using of
SHA-2
or any other hash-functions (mentioned bellow) will not help. So using of
any of the mentioned hash-functions can be not wised (faulty).

Due to that you became talking about using of other hash-functions instead
of md5 (which can be correct in case of direct usage, but I'm talking
about
indirect usage), so I decided to look at other hash-functions in context
of
indirect usage of them. And today I conducted testing of different
hash-functions and added information about it to my article
(http://websecurity.com.ua/4459/).

As showed my researches of work of different hash-functions (in addition
to
md5), in result of work of such hash-functions as gost, lm, md4, mysql323,
mysql411, ntlm, ripemd128, ripemd160, ripemd256, ripemd320, sha1, sha224,
sha256, sha384, sha512, tiger128_3, tiger128_4, tiger160_3, tiger160_4,
tiger192_3, tiger192_4 and whirlpool the string results, which also is
hexadecimal number (as in md5). So this string also has alphabet from 16
chars. And so all warnings regarding the length of string in function md5
(at using this string for safety mechanisms) in equal degree concern to
these functions.

I.e. such vulnerabilities can be as with md5, as with any other from
above-mentioned hash-functions (with or without salts). So my article
concerns all hash-functions (particularly above-mentioned) which return
hexadecimal numbers which are using as strings for security purposes.

> Using a truncated version of a hash is almost always an anti-pattern.

But such things happen and in software used by millions of people at
millions of web sites (as I showed in my examples). And about truncated
hashes (strings with small length) is my article. And here all developers
need to be wise and always take into account this aspect.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message -----
From: "Jim Harris" <jharris at LAWTRAC.com>
To: "MustLive" <mustlive at websecurity.com.ua>
Cc: "Michal Zalewski" <lcamtuf at coredump.cx>; <websecurity at webappsec.org>
Sent: Monday, August 16, 2010 8:44 PM
Subject: Re: [WEB SECURITY] Faulty using of MD5 in web applications


The MD5 without salt is crackable. Everyone knows this.  Add salt and your
fine.



Sent via mobile device.

On Aug 16, 2010, at 1:28 PM, "MustLive" <mustlive at websecurity.com.ua>
wrote:

> Hello Michal!
>
> I'll give you more detailed explanation of issue with md5 to let you
> understand it better.
>
>> You seem to be confusing MD5 with hexadecimal numbers.
>
> No, I'm not confusing - I'm talking in my article about both MD5
algorithm
> and hexadecimal numbers. Because the result of many (especially widely
> used)
> functions which implement MD5 algorithm (such as md5() in PHP) is
32-digit
> hexadecimal number. And because it's hexadecimal number, the alphabet of
> it
> (of the string) is 16 chars, i.e. output alphabet of such md5 functions
is
> 16 chars. And herein lies the issue which I described in my article and
> showed two examples of vulnerabilities which I found in web applications
> with faulty using of md5.
>
> There are two main usage of MD5 algorithm, as I classified them: direct
> and
> indirect. The direct usage of this hash algorithm is to make hashes (of
> passwords, files or other data) and use them for later checking (e.g.
> checking hashes of passwords if they are equal, or checking checksums of
> files if there were no changes in files, etc.). MD5 is doing well with
> direct usage of it.
>
> Indirect usage - it's using md5 for generating strings (i.e. random
> strings)
> for security purposes. And here we have the issue which I described. In
> the
> article I wrote exactly about using of md5 for generating random strings
> for
> security purposes. And in most cases of indirect usage, the small part
of
> the md5-sting is used (abbreviated strings) - not 32 chars, but less, to
> make them easier to use (as in case of generating passwords from md5).
As
> I showed in my examples, small length of md5-string (less then 7 chars)
is
> very insecure, but I stated that using of large length of md5-string
(from
> 7
> till 32 chars) can give enough reliability.
>
> In my examples of incorrect usage of md5 (indirect usage) in web
> applications I showed such as using of md5-strings for creating of
> passwords
> and using of md5-strings as path to important resources. There are many
> other examples of using md5 for security purposes.
>
> Here are some examples of correct usage of md5. From WP 2.0.3 (in 2006)
> there are anti-CSRF tokens in WP and md5 is using for making random
> strings
> for tokens. The 10 chars md5-string is using, so it gives 16^10 of
> possible
> combinations (so it's reliable enough). In Drupal (as I checked in 6.x
> versions) the full length of md5 (32 chars) is using for anti-CSRF
tokens,
> which gives 16^32 of possible combinations (so it's indeed reliable).
Even
> in WordPress 2.0.x, when I disclosed that Weak Password vulnerability in
> WordPress (in April 2008), during my researches I found another case of
> using of md5 (besides generating password at installation, also password
> was
> generating at lost password procedure), and if in the first case
> developers
> used 6 chars length (16^6 of possible combinations), then in the second
> case - 7 chars length (16^7 of possible combinations, which is reliable
> enough). So all developers need to take into account as the length of
the
> string, as the alphabet, when using md5 (or any other function) for
> security
> purposes.
>
>> Or rather, the vulnerabilities discussed do not seem to have anything
>> to do with the use of MD5 specifically.
>
> As you can see from above-mentioned, it's indeed directly related to
MD5.
> To
> find out that these vulnerabilities are related to md5 function it's
> possible to look at the source code (and in one of advisories which was
> mentioned in examples I wrote a quote from source code of php-file,
where
> md5 function was using). But it can be found out even without looking at
> source code - in both cases (with WordPress and plugin WordPress
Database
> Backup) I found out that md5 function was used just during usage of the
> applications - just at looking at generated password at installation and
> at
> generated folder's name (and I can identify usage of md5 by looking not
> only
> at 32 chars, but even at just a few chars).
>
> Many developers don't know or forget about limited alphabet of md5
> function,
> so I'm reminding them about it. All developers need wisely use md5 or
> other
> hash functions for security purposes.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
>
--------------------------------------------------------------------------
--
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to
> the confirmation email
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to 
the confirmation email

Join WASC on LinkedIn 
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to 
the confirmation email

Join WASC on LinkedIn 
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates



More information about the websecurity mailing list