The God Login

    var caps = null;
    passwordField.onkeypress = function(e) {
        if (caps !== false) {
            var s = String.fromCharCode(e.keyCode || e.which);
            caps = s.toUpperCase() == s && !e.shiftKey;
        }
    };
    loginForm.onsubmit = function(e) {
        if (caps) {
            passwordField.value = invertCase(passwordField.value);
        }
    };

For n character alphabetic values, it reduces the keyspace from 52^n to 26^n.

There is no need to store the password in plain text in any form.

Facebook, and any other company you'll log in to, requires a non-hashed password at some point to check against the hash. You need a cleartext password at some point, otherwise the user can't send anything to you.

The best practice for security is to not store passwords in cleartext. You can certainly perform extremely limited actions on passwords in cleartext (like hash checking), and you inevitably have to.

Which brings me to my overall point - as the Facebook security team has explained before on their whitehat page, you do not practically reduce security by allowing caps lock inversion to check a hash.

What you're saying about Facebook having an abnormal process also isn't true either - Facebook does one of two things, both of which are secure:

1. Stores two hashes for each password, one the real password and the other the case inverted, or

2. Checks a password against a hash, and inverts the case and checks again if it fails.

There is nothing about this which is different from normal password transmission in cleartext, and Facebook doesn't store the cleartext password you send them.

EDIT to your EDIT:

No, no no no no, no. Don't do clientside things like that. Allowing a user to directly manipulate something as major as whether or not their password is hashed before it is sent to you is bad. It doesn't even matter that it's just them hacking themselves; it's just bad form to put that in their browsers' hands. Plus, a stored cross-site scripting error that went viral on the login page pre-auth could screw your password database, leading to a layup for mass cleartext password compromise. Or in a worse scenario, you're giving a user direct write access (and then maybe reads) to the password database.

It's much safer to do the industry best practice of destroying cleartext sensitive information upon successful hash.

Say no to clientside security. There are arguments for hashing clientside, but they can all be summed up by "You shouldn't let people potentially sniff users' passwords" - if you implement TLS/SSL correctly, this won't be an issue and the cleartext password will exist briefly, then get destroyed.

The one other argument is that someone could compromise the server handling the hashing process and write a script watching all the passwords. But this isn't a valid concern - if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.

Finally, consider that a client-side hash of a password sent to a server becomes the effective password for that user, not the hash of the password. This means that, effectively, if no other action is done at the server, you're actually then storing the password in plaintext. If a user was MITM'd while sending the password, the hash can now be sent directly to the server in place of the user's password, because it is the de facto password.

The bottomline: client-side hashing offers no real addition to overall security posture under TLS/SSL, and removes most of the benefit of hashing.

If you insist on doing this, you can always invert it and hash it on the client side, and send both hashes. You still have access to it, just on the client's computer (running your own code).

No. If you are going to do something like this, do it properly with something like a zero-knowledge password proof.

As you describe it you are introducing a huge flaw: If your password database leaks, an attacker now has everything they need to log in to user accounts, no password hash attacking required.

I'm pretty sure at some point we'll have features which are worth protecting and at that time we'll need to offer an opt-in stronger method of account security.

EDIT: for some reason I can't reply to FreezerburnV's comment below, so I'll answer here: yes, I would be interested in talking further about this, drop me an email (in my profile)

The "not so weak but still crackable" intermediate level doesn't make sense. It's probably going to be reused (how many different 6-character random passwords are you going to remember), so it's just as easy to make it 8 or 12 characters to make it harder to crack when one of the sites inevitably has their password database stolen. If they're not hashing, of course, you're screwed no matter how long the password is.

If you're going to allow 6 character passwords, that indicates there's basically no cost to user account compromise, so why should there be any password testing at all? If a user wants to use the password "1" and gets hacked, that's their problem, they can create a new account after all. It also indicates that user's contributions to the site are probably of low value, since they don't expect to gain any social capital from their contributions that are worth protecting with a better password. If they think the post(s) have value but are going to abandon the account, they can just as easily use "1password" as their password instead of "123123".

It seems like an 8 character minimum and checking against a wordlist is a small price to pay for preventing naive internet users (there are a lot of them) from using horrible, not just bad, passwords.

At the other extreme, my father commenting on the news couldn't care less if his account is hacked. All he wants is a fast and easy way (using the same password he always uses) to post on the Internet, with a relatively secure way to identify himself to other users on the site.

You need to sit next to someone who doesn't live on the Internet to realize how simple measure, such are requiring a minimum password, can really piss them off.

"Oh, my account got hacked... I guess I'll make another."

"God FUCKING DAMNIT this stupid website won't accept my password!"

If you're just checking to see if it's a common password, wouldn't it be easier to just store a dictionary?

Now, I have new 'identities', too - facebook, twitter, linkedin, my phone, etc.

To me, it's a mess, but maybe I'm in the minority.