Gmail: Bad Request; Error 400

First time I've seen this: Tried to log in to gmail (via browser) and all I got was:

Bad Request
Error 400

I figured it was momentary, so went off to do other things. (So many other things to do...)

A few hours later, same thing. Next day, same thing.

This is unlike gmail. So tried a simple Google search... slow, but it did return.

Maybe Google is under a DoS attack? No news, and now Google is returning just fine, but still no gmail.

So I started searching around for anyone with a similar problem. Saw a few, though they were old.

Tried the gmail Google Group and went through what seemed to be the procedure to enter a new issue (after reviewing current open issues), but that did not give an opportunity, at the end, to open a new issue.

So, some more generic searching, using both Google and Yahoo, turned up the typical low-level support "decision tree" request to empty cache and delete cookies. Well, I'm certainly not going to delete all my cookies right away, however...

I tried a different browser and got right in - OK; we're on the right track.

I then saved my cookies (always have a backup) and looked for which cookies might be the culprit.

Got it in one: There were probably well over a hundred (!) separate cookies for the mail.google.com domain (both with and without a leading dot), that also used a path of "/mail". I deleted them, and gmail loaded right up on the next try!

Update 2009/03/20: Apparently there's a similar problem with Firefox.

Browser password managers leak like sieves

We're browsing away, maybe checking our bank account balance and up pops the requirement to type in the password to unlock the password manager. Ah, we think, another indication that we're safe - it required me to type the password AND I was so careful to make sure it was the right site, etc.

Unfortunately, that's a false sense of security - which is worse than no security at all.

Click through the link above to read the gory detail if you like; even if you don't understand it all, at least some will make sense.

Even better, try the test yourself - watching it pull passwords out of YOUR very own password manager will really drive the point home.

I know of no actual exploits yet, and they do seem to require a compromise of the site from which the attacker wants to steal your password - however, as we've seen, such compromises are not at all uncommon.

One other item of note: For Safari in particular, I note that the default, when creating a new entry, is to give Safari blanket permission (via Access Control). While convenient, it is far less safe - and it seems that the problems detailed in the CIS article, might well be avoided if Safari did not do this; at least the user would be required to type in the keychain password each time and thus get some warning.