There has been some minor controversy about the importance and relevance of the RST cryptanalysis of the Netscape mail password in current versions of the software. Previous work on Netscape mail passwords (among other things) done by Dave Edis and posted to bugtraq exposed a weak password scrambling attack over a year ago. Though the algorithm we discovered is somewhat similar, old password crackers do not work on the existing system. Our algorithm is new. We acknowledge the previous discoveries and their relation to the one we found independently. 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. In any case, here is a scenario that makes a strong point for raising the bar. Consider the case of a Web-based Javascript attack that is able to steal a file remotely but not do any other file modification. Based on Richard Smith's work, we have a working Javascript attack against the latest MSIE that is capable of stealing files, including preferences files with the scrambled password. There are similar Javascript attacks against Netscape versions 4.0-4.05 (old). Descrambling the password using our discovery is trivial. Together, the two exploits allow an attacker to steal a password remotely without having to install a sniffer on a local LAN to snag the plaintext password as it goes by (at least with POP3...IMAP has better optional protection). That's why we think it is worth raising the bar. There is no perfect solution to this problem of wanting to make life easy for users by remembering their password on the client. But a good solution is a far cry better than a bad one. gem Gary McGraw, Ph.D gemat_private Vice President, Corporate Technology Reliable Software Technologies Dulles, VA <http://www.rstcorp.com/~gem> <http://www.securingjava.com>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:21:57 PDT