Re: Reinventing the wheel (aka "Decoding Netscape Mail passwords")

[tim () RSTCORP COM (Tim Hollebeek)]

> I was bit confused with this link (
> http://www.rstcorp.com/news/bad-crypto-tech.html ), since I am not quite
> clear if these guys are just reinventing the wheel, or have found
> something new.

It turns out that the Windows algorithm used in conjunction with the
registry is subtly different from the one used for preference.js files,
which has been previously reported.  One of the things we were suprised to
find is that they are remarkably similar (we had not looked closely at the
details of the previous exploit at the time we did the reported analysis).
The Windows algorithm is slightly stronger, but still extremely weak.  We
are in the process of looking at the timing of various events and versions
to discover if the new algorithm is the result of a "band aid" solution to
the previously reported problem.  Previous exploit code like the one you
posted and others we have found on the web all only handle the older, weaker
version.

In addition, the consequences of this flaw in a Windows environment are
substantially different, due to the lack of access controls.  As we
discussed in the technical summary, while there is no perfect solution to
this problem, it would take very little work for Netscape to make future
exploits of this type much more difficult.  The current position of
Netscape, that these sorts of vulnerabilities need not be fixed, is in my
opinion rather irresponsible.  Software companies have a responsibility to
make exploiting their software as difficult as possible, _especially_ in
cases like this where the cost to do so is similar to, or less than, the
cost of using absurdly weak proprietary cryptography.  It is Netscape's
responsibility to put the bar at as high a level as is feasible and
economical.  As Avi Rubin, security expert at ATT Labs, pointed out, in this
case Netscape needs to run out and get a bar so they can raise it.

Tim Hollebeek
Reliable Software Technologies