Date:        12/19/99 21:57
Received:    12/19/99 22:04
From:        John Viega, John@list.org
To:          contact@hackernews.com

I believe that what HNN posted today about the Netscape thing is largely inaccurate. First, there are and have been two different ciphers in use in Netscape that are similar, but slightly different. The simpler one, which is a base 64 and an xor only (with potentially a pad), apparently made the rounds a year ago, and people did note that it looked similar on recent versions of windows. But it isn't the same right now. Maybe Netscape changed their cipher from last year, or perhaps it has been the same through the whole 4.0 series. I dunno, but at some point they did change it.

I looked at the 2.0 series, the 3.0 series, and 4.6 + 4.7 on Windows. The 4.6 and 4.7 cipher is substantially different from the 2/3 cipher. The 2/3 cipher is the same as current versions of Unix and Mac. Let's face it... user habits are different on Windows than on Unix. Few if any people use NS to read mail on a Mac. Plus, Windows has a lot more dumb users.

So we have defintely broken a different cipher. We didn't know that the older cipher was previously broken. When we talked to Netscape, they gave us no indication that it ever had been. In fact, they seemed to be indicating that they were crossing their fingers hoping that no one would target it. Also, the old attack wasn't very well publicized. Again, I suspect that NS new about the old attack, was glad it stayed low key, and quietly made the algorithm a bit harder on its flagship Windows version without making a real effort to fix the problem.

The new cipher still does a base 64 encode and an XOR with a fixed key. However, it also does some bit permutations, and reads the bytes in reverse order. If you look at the same 7 char password encoded with the old algorithm and the new algorithm, you will notice that they aren't the same. You'll notice the "=" pad is at the front in the new kind, and comes last in the old kind. The strings will also look similar, but aren't the same thing reversed, or anything like that.

It wasn't that much stronger, but they obviously hoped it would provide a bit more security. Funny, the MSDN developer's network talks about security, mentions that XOR is desirable, and suggests tricks like this to help improve the security of XOR. It's completely and utterly rediculous.

So, to summarize so far, the cipher is exactly as complex as we said it was, and not "simpler than first thought". There's been some unfortunate confusion between their old cipher and their new one. It definitely would have been nice if we'd run across info on the old one before we talked to Netscape, or if they'd have told us about it, but those things did not happen.

The next point I'd like to contend in today's HNN article is the quote "To Netscape's credit they are just conforming to the POP3 protocal which sends passwords in the clear anyway." First, the save password feature works w/ POP3 and IMAP. IMAP doesn't require you to send passwords in plaintext. If I recall correctly, there are a bunch of different authentication mechanisms. Of course, I don't know what NS uses or does not use. Second, I don't believe that just because a password is going to be sent in plaintext, you should make it even easier for people to get at it. Even if you can't raise the bar high enough that someone won't be able to jump it, you should raise the bar as high as you can. Why didn't Netscape just leave the password lying around in plaintext? Well, even really poor obfuscation is going to stop most computer illiterates from getting the password. They'll find it if it's in plaintext (though someone might have to tell them it's there). At many companies, it'd be that much easier to get your boss' mail password, etc. just because he left himself logged in.

So basic obfuscation raises the bar a bit. But script kiddies can download software to decrypt the old passwords (we haven't seen anyone post such software for the new algorithm yet). Also, it's not too hard to embed code to collect such passwords in email attachments that show dancing pigs. In some older versions of Netscape, the password could be extracted remotely via JavaScript. For people who run both IE and Netscape, there is a current IE bug that will let people extract the ciphertext Netscape uses (Thanks to Richard Smith for that). More such holes might (probably) exist elsewhere.

I think that the more difficult you make this, the better, even if the password is sent over the network in plaintext. Why? Because it raises the bar a bit more. I believe that fewer people have the skills to set up a sniffer, and mine the data it produces than can run code to email back encrypted passwords, and then run code to decrypt them. Plus, there are tools like antisniff that can make it harder to sniff. Plus, you have to wait around for the person to actually check his mailbox from that machine (which he or she might not even use anymore). It's not a much bigger bar, true, but I believe it's a bit bigger nonetheless.

I've heard people argue that it is pointless for Netscape to use real encryption such as Twofish or 3DES and hide a key, because the key could be obtained through reverse engineering. Well, it's true that you could obtain the key that way. Again, I think it is a matter of raising the bar as high as you can. If you hide the key well, few people will be willing to go through the hassle of reverse engineering the code. Sure, it may eventually happen, but Netscape should hope that "eventually" at least buys them a little bit of time where they can really offer some security to people saving their passwords. There have been plenty of products that have gone several years with embedded keys that no one bothered to reverse engineer (at least, so far as the public knows). For most people, reverse engineering can be a huge time sink, and may not be worth the effort, especially when really good obfuscation is performed. There's generally always more interesting, lower hanging fruit to be picked. I know that I sure wouldn't have bothered to reverse engineer Netscape's algorithm if we couldn't break it by other means, and I believe a lot of other people feel the same way.

Another sentiment I have heard a bit in the past couple of days is, "If you need access to run code on the machine for this exploit, who cares, since you've already compromised the machine?" Well, the primary response to this is that mail account info is often a quick gateway to other accounts on other machines. POP3 and IMAP accounts often check the same password file telnetd checks. Or, wu-ftpd, which you could use in conjunction w/ a recent buffer overflow to get a shell. Also, plenty of people use the same passwords for multiple accounts, PGP passphrases, whatever. They shouldn't, but they do anyway.