[13025] in bugtraq
Re: Netscape password scrambling
daemon@ATHENA.MIT.EDU (Kenn Humborg)
Tue Dec 21 14:22:05 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <01BF4B0A.ADE0A4C0@beowulf.bluetree.ie>
Date: Mon, 20 Dec 1999 16:53:01 -0000
Reply-To: Kenn Humborg <kenn@BLUETREE.IE>
From: Kenn Humborg <kenn@BLUETREE.IE>
X-To: "BUGTRAQ@SECURITYFOCUS.COM" <BUGTRAQ@SECURITYFOCUS.COM>,
Gary McGraw <gem@RSTCORP.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
> More importantly, some people have claimed that the entire password
> saving issue is a red herring since there is no way to protect a secret
> on the host. This criticism is worth thinking about more carefully. We
> suggest that Netscape "raise the bar" by using triple-DES and hiding key
> material for the cipher throughout the code. But can't you just apply
> some clever SoftICE to find the key? Of course you can! Doing so
> requires much more sophistication than simply cracking a "magic decoder
> ring" scrambler, however.
Until the next decode-netscape-passwords.exe script kiddy tool
appears, that is.
The key material would be better if randomly generated at
installation time and spread over a various (large) files on the
client. That way you need to pull a lot more than just a small
prefs.js file, making your exploit much easier to notice.
Of course, if the exploit that grabs prefs.js is capable of
seeking in files, then this won't help much.
Surely there must be some way of making the encryption
key client-specific, rather than one key for everyone. It won't
be perfect, but should be better than nothing...
Later,
Kenn
