Why Password stealing is easier because of dialogs.

For more information about this you will need to read bug 51631, or use your imagination (depending on whether the bug is available to the public).

At the present, I have not read the regression bug, nor have I read the patch, in fact I'm not done reading the original bug, but so far what I've read has depressed me.

I'm told by someone who works on cookies and image blocking that the checking is depressing too.

So what happened?

In short a seasoned and respected Netscape manager explained that he like normal people can't keep passwords straight, and that no matter how a password prompt dialog looked, he was unlikely to read the text and would automatically assume that it wanted his mailnews password.

So where's the real problem?

The problem is, and this is a well known quantity to security people, that dialogs by their nature aren't directly associated to the object that they protect.

My executive summary of the confession of a Netscape manager is that it doesn't matter how different a password dialog looks, if it's a dialog and it's the same place that you'd enter a password, then you might enter it.

What other problems do our password dialogs have?

Frequently they're given bogus parents.

For example, try composing an email in mozilla and then sending it using an SMTP server which requires authentication. A dialog will appear, blocking your inbox asking for a password. It won't block your message composition, so you won't know why you got the dialog.

Worse, if you happen to have mozilla configured to save your sent messages to an IMAP server which also requires authentication you can get a dialog prompting for that password, but the dialogs don't explain what server/account/userinfo/protocol needs the password.

To make things even more exciting, it's unclear what will happen when you click cancel. If you click cancel to the wrong dialog (and the number of dialogs you get can be 0, 1 or 2 depending on which things you've already authenticated in your current session) your message might or might not be sent, and it won't be saved. Then what do you do when you want to keep a record of your sent message? If you send it again the recipient will think you're silly. If you don't send it again then in some cases you won't have sent it at all, and in other cases you just won't have a copy of what you sent. If you're clever, you could save a draft and then move the draft to the sent folder, but that's not really the same as the message you sent...

Password prompts while browsing with tabs.

Well, actually, it turns out that this is a problem with any prompt and tabbed browsing in general, but password prompts are the most important concern and they don't actually include things like an HTTPS indicator, or any way to view the certificate belonging to the HTTPS password prompt.

JavaScript can show a basic password prompt, I believe it's tagged as JavaScript Application, but that's not enough. Suppose that you use tabbed browsing and have two tabs, suppose your first tab is from your bank (your bank is good so it's HTTPS) and suppose the second is a friend's joke page. The bank tab is focussed, and you turn your head for a moment. When you turn back, you see a JavaScript password prompt. It must be from your bank, right? wrong :), it's from that other tab. There's no way to know that. You can't select a different tab while the dialog is open, and you can't control which tabs are allowed to run scripts while the dialog is open.

That's OK, you're a normal user, the active tab is your bank's, you look to the lock icon and see it's locked. you trust the page and decide that the application must be trustworthy, after all, your bank does use JavaScript.

If banks ever figure out that mozilla has this problem, they'll demand a way to prevent their pages from being viewed in tabbed windows. I guess I'll have to make sure this page is never read by any banks. :)