The author refers to "Handle common user mistakes" - by displaying a message "your caps lock is on".
Personally I love the Facebook approach. Facebook just accepts passwords with caps lock inverted, so you never have the problem in the first place. No need to display a message to the user.
Unless they changed their entire auth mechanism, it's definitely case insensitive.
IIRC, the client encrypts the password using some variant of SRP6 plus some additional magic, but the last time I dabbled in wow emulation was quite some time ago.
Why would they need to store the hash of both possibilities? They can simply invert the case of what the user types before hashing it - ie. compare both hash(enteredPassword) and hash(invertCase(enteredPassword)) to the hash in the database and see if either match.
They could also just ignore case: hash(upper(password)) so there is only ever one hash (that happens to map to multiple input passwords) instead of multiple hashes relating to a single password each.
But this is less secure than storing the properly hashed password. This would reduce the space of all passwords to upper case letters (plus whatever symbols and numbers are allowed) only.
Yeah, I'm being downvoted for pointing out the method some places use. It's terrible to have anything but a minimum length requirement IMHO. Making it password insensitive is nice for users, but does make the resultant search space much smaller (to the point that I don't think the convince for users trumps, especially given the UI can inform them if they have caps lock on to begin with).
Which is weird, too. I wrote an email once to Blizzard, asking why they also have a maxlength for the password. This doesn't mean anything, but it could be an indicator for password = VARCHAR(16). Makes no sense whatsoever to restrict the length of a password, especially in such a large network. Never got a reply though.
I suspect that Facebook still wants to know that some letters have a different case than other letters. If They just converted all letters to uppercase then that information would be lost.
Who says they can't check 3 times? Original, caps inverted and uppercase? This would make sense. You could even make it try neighboring keys on common key layouts. If the hash has enough bits of security then good passwords will still not break.
That's a good approach for usability but it does halve the keyspace for anyone attempting a brute force attack. It might not be appropriate everywhere.
The best way to handle this is not to modify the entered password, or to reject it, but rather to just display the message. If it stands out enough you should notice it and make the corrective action yourself. In your case no corrective action would be necessary.
It does "halve" the keyspace, by removing one bit of entropy from your password. This is assuming you only use letters in your password and not numbers or other symbols not affected by capslock.
Well, it's a bit tricky. Two inverted passwords still have different hashs. From that perspective, two inverted passwords are not equivalent and therefore the entropy is not decreased.
This is important because if you want to decode a hashed password using a rainbow table for example, you still have to hash the entire keyspace, not just half of it.
If you're doing an online attack, you can submit half as many passwords. I guess it's just as hard for an offline attack where you're cracking the database of hashes.
This "Facebook approach" almost certainly requires you to have, at least once, access to your users' non-hashed passwords.
Which is widely regarded as bad security practice because your users' passwords can be compromised by an attacker getting read-only access.
[EDIT] Well, good thing I used "almost", since I was wrong: of course, case-inverting the password and hashing the result could also be done client-side, silly me!
[EDIT'] Answers pointing out that you always have access to non-hashed passwords, and I believe this is wrong. When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.
> When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.
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.
You always have access to the user's unhashed passwords when they submit it. In authentication, hash the raw password and invert case and the hash that. Then compare the stored hash against both hashed passwords from the input.
There is no need to store the password in plain text in any form.
If you send a hash instead of a password, that hash _is_ your password. If I steal the hash but not the string it was derived from, I can pretend to be you and log in.
You do have access to their non-hashed password. When they type it into your form and press enter. You just invert the case and check it against the hash again.
A hashing algorithm specifically for passwords that would hash to the same thing based on inverted caps lock or other deterministic user errors (white space at the edges, maybe)? That sounds like a great idea.
You're right that it's bad to store non-hashed passwords, but your point about security is unfounded.
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.
> 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.
No, they really don't need that. C.f. SRP (http://srp.stanford.edu/) and similar protocols, where the end user performs a local calculation and the remote party is able to verify identity without ever knowing the password.
This could be the workflow:
1. User enters email address at site.
2. Site sends an email containing a URL with a 512-bit query parameter (yes, this means that user's ISP—and anyone else with access to the email—could sign in once). This parameter might be HMAC(secret, address), enabling the server to store no state for unverified users.
3. User visits URL, and sees a form for email address and password entry. There are hidden fields for the crypto parameters.
4. The user's browser takes the user's address and password, generates a random salt, and calculates a function of the crypto parameters and the local CSPRNG to get the salt a function of the address, password and crypto parameters to get the password verifier.
5. The user's browser POSTs (address, salt, verifier) to the server
Then whenever the user logs in, the browser and server engage in the SRP exchange.
The server never knows the client's password, ever. Nor is someone who knows the verifier able to forge the password.
The best practise is never to transmit sensitive data in the first place.
> 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.
If your hacker has a cleartext password and their login ID (email address), you've just given the hacker access to a bunch of their other accounts on non-compromised sites (for the significant % of your userbase that recycles passwords). I think the possible collateral damage creates a far more severe worst-case scenario.
If they have access to your server they can inline javascript that will do the same thing on the client. The client is not secure, ever. If the users are reusing passwords, it's not something you can same them from except not saving the cleartext password yourself. Database attacks are different from on line interception.
That's a fair point, though it doesn't outweigh the myriad other reasons not to do client-side hashing.
Security is always a battle of usability and tradeoffs. Client-side hashing simply doesn't make sense for security. It removes the fundamental point of the hash in the first place and introduces an avenue for possibly attacking or manipulating your database.
In fact, there's hardly ever a reason to do client-side security.
Yes, that's exactly what I mean. Treat all user-input (and by extension, client-side anything) as dangerous. A server putting a security protocol in the hands of the client when it is not unavoidable is usually bad.
Hashing client-side is not a good idea in practice — a leak of your password database leaks direct credentials for logging in. If you're going to go this route, something like the zero-knowledge SRP protocol is necessary.
Assuming that you run your own login service like Facebook does, you always have access to your user's passwords at least once because at some point you have to take the raw password and hash it. Facebook just creates two variations of the user's password and stores the hashes for all three of them.
I never noticed that. (I switched to Macs around 8 years ago.) Huh.
In that case I guess I have to wonder what the point is? Why store three hashes as opposed to just upper-casing the plain-text before hashing? You end up storing fewer variations, and it makes no functional security difference to the front-end (since any attacker would just .toUpperCase() their inputs anyways)?
> Answers pointing out that you always have access to non-hashed passwords, and I believe this is wrong. When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you.
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).
I never really understood the reasoning behind the whole "maybe your email or password is wrong - but we wont tell you which" message that websites love to give.
The reasoning tends to be along the lines of "prevent spammers getting emails" and "security by obfuscation".
But almost all these websites have a sign up page, and if the email address is already in use they will happily let you know that.
Therefore if a hacker/spammer/bad guy wants to brute force your application for emails - they can just use the 'sign up' page to get the emails instead of the 'forgot password' page.
I would argue that registration pages should not let someone know if an email is in use - if a duplicate email is used in registration then the site should just send a quick email notifying the user that this email is already in use (with sensible DOS protection and email opt-outs etc.)
Your use-cases miss out one type of hacker/spammer/bad guy - the one who is only looking for you, they know your email, they want to profile you specifically.
Over the top/exaggerated example (with many implicit caviats!)...
Mr Smith has Mrs Smiths email - he uses it to try to register with a Dating Website - but hold on, it's already registered!
Now there could be 3 reasons for this...
1. infidelity
2. It pre-dates the relationship
3. A third party trying to cause trouble by signing Mrs Smith up.
I don't believe a company has the right to decide what data they hold on you is visible to the outside world - without expressly asking you.
What happens on the front end in that case? Would it be an irritating "Please check your email to continue registration" kind of situation? Because people don't like that as of 2010 ish
What sp332 said - there wouldn't be any extra steps as you would have to go to your email to complete registration anyhow.
You could have an extra link in your email which lets you update your existing registration details with the ones you've just entered, but that's not going to significantly extend the amount of time you take to register.
There does exist a legitimate (though contrived) use case for not telling the user which of the fields is wrong: when a user misspells their username and that misspelled username belongs to another user. From the user's point of view the username would be wrong but the password would be right, whereas from the site's perspective this is reversed and would produce an incorrect error message. This particular case would be particularly insidious because it's impossible to review a password after typing it.
Like I said, contrived, but security-by-obfuscation isn't necessarily the sole motivation (though likely the commonest).
The code needed to track the error is slightly bigger if you need to know what causes the error. Stating what is wrong at login has no apparent added benefit and has a slight disadvantage.
Me too. Persona is great and has a very nice login flow, and is the best as a user in terms of what is/is not shared with an IdP... Just need to get more websites to use it. (I've written about setting it up in an ASP.NET website and it is really easy to do and work with.)
In a recent side-project ( nightchamber.com ) I experimented with the idea of something like a "God Login". A user account is automatically generated on first visit and keyed against a uuid, the id is then stuffed into the session, and used to make a link the user can bookmark to get back to their "account".
As long as that link/id remains secret, the user has a unique account to use with no effort on their part.
I'm still not sure this is a good idea, but it seems to work for nightchamber, where the account doesn't actually have much value, and there is no valuable information an attacker could gain by "compromising" the account.
Have you considered being able to convert between an automatically-generated link/id user, and a username/password user? That way someone could potentially make a more "permanent/secure" account from the easy one. This might require removing a generated account if someone logs into an existing account from a new browser though.
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)
Out of curiosity: Are you looking for any casual code contributors? The main ideas behind the site (automatic anonymous account, "slow" web kind of thing where you only see updates once a day, possibly seeing some interesting thought-provoking stuff each day) are actually pretty interesting, and I think I'd enjoy helping out with what you're working on. I have a job and my own side project(s), so I can't say I'd be really in the nitty-gritty of the project all the time, but maybe I could help out here and there.
I would understand completely if you don't want a random stranger on HN touching/seeing your code though :)
I don't see an email in your profile (by clicking on your username attached to the post). I just see submissions/comments. I can send an email to the one listed on the nightchamber about page, or you can check my profile where I just added an email address that I can be reached at. I should have put a contact email in my profile a while ago, my apologies for only having done so now.
I also have been experimenting with "hard to guess" links as the id.
I also am not sure it is a good idea, but one of the by products of this design choice is I had to think harder about what markets I target (I am ruled out of any where the data needs to be protected), how to detect and protect the data of the users in the face of vandals and how to allow for recovery of the data if the vandal countermeasures fail.
While doing this I realized that I should have been dealing with these things anyway and that I was lying to myself about the security of my systems anyway.
I also realized that the login-less user experience is so valuable that until I can replicate it in a truly secure fashion (via client side certificates or something?), I would rather give up on any feature that requires logins.
That little aside about "log in" vs "login" irritates me because there is a correct answer. "login" is a noun, while "log in" is a verb phrase. They are two separate things. The button to log a person into the system is a command (a verb), thus it should be "Log In", not "Login".
While what you say is true, what matters more is the UI experience. Some people will naturally conflate "login" and "log in", even if they shouldn't.
Also, there are other factors - fonts, monitor dpi, and other factors may make it more difficult to discern between "login" and "log in" on a button, for instance.
> So, with Discourse, rather than all that, I decided we'd default on a solid absolute minimum password length of 8 characters
8 characters is way too much for someone just 'poking around'. Sure, 6 characters is much less secure, but then again how secure do you need to be for a forum/commenting platform?
It's much better to let the user know his password is weak while letting him take it anyway.
Exactly my point, I hate to be restricted with my passwords for meaningless websites.
"Sorry, but your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin." (old joke)
But why? Your website is not important, do you know?
And if your website is that important (maybe it involves paid subscriptions or something). Then freakin' remind me of those restrictions when I'm trying to log in, so I don't have to think about all the character combinations I might have tried when signing up for your website.
Why does it matter how unimportant the site is? When you pick a password, either you pick something simple and totally insecure (password, 3jane, god), something not so weak but still easily crackable ("kLY8rT"), or you use a password manager.
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.
> When you pick a password, either you pick something simple and totally insecure (password, 3jane, god), something not so weak but still easily crackable ("kLY8rT"), or you use a password manager.
Why would you let someone use a password you know is going to get compromised? Don't you think they're going to get pissed off once their account is compromised? Do you think it's more likely they'll blame themselves for using a weak password than blame you for letting them use it?
Perhaps, but if that user is hacked due to their weak password, while it would technically be the user's fault, it would be the site owner who would take the blame for it in the user's eyes. It's better to protect the user from themselves.
And "just" a commenting platform doesn't quite cut it for me, people can take their online reputations very seriously. How would it affect the HN community on a whole if tpatec or michaelochurch (insert your own respected user here) were hacked and their profiles destroyed?
You are looking at this from your point of view. Someone who values his online identity and (probably) already takes the required steps to protect it.
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!"
I wish, also that a login page would tell me if I entered in a password that doesn't meet their password requirements and then show me what those requirements are again. Often, when I get the password wrong, I have to go to the signup page to see what random password requirements this site requires so I can remember what password I made up for it.
Do we even need a sign-up dialog? Couldn't we just log in, and if it doesn't exist yet, tell the user to verify via the incoming email?
I'll grant that there's likely some stuff that some sites want to do on first visit, and that if some do it, users will eventually expect all to be like it. And perhaps that's why we have two dialogs now. But is there any security/pain point related to it? (Assume there's some small snippet of text that makes it clear what's going on, I guess.)
I can see this causing some issues with users that have multiple email addresses. It may cause panic if they log in, see that it is successful, but do not see any of their normal account data. They may assume that their account has been deleted or their data lost.
I often think this is the right way to go. I think even if you type the wrong password, it should ask you then and there to reset your password to what you just typed in (confirming via email). This even has the added benefit of the user changing their password more than never.
The problem I have with using email for login, is I often don't know which email address I used to sign up for the given service. There is my Google Gmail address, my work email, and the primary one I use for my personal domain. On top of that, I use wildcard forwarding on my personal domain, so anything@example.com gets to me@example.com. The only way I can tell which ID i used when I signed up is to go through my email archive and try to find something from that site.
because the former is just an arbitrary string that you might be using in many places, and the latter is an arbitrary string PLUS a domain for one of your potentially many email addresses. Sure you see the difference...?
> ...and verify the password to make sure it is not one of the 10,000 most common known passwords by checking its hash
Am I missing something here?
1. I navigate to discourse
2. Select "try discourse"
3. "Sign Up"[0]
4. Dummy username/email
5. Password: 12345678
6. Wait, it succeeded? What did I just read?
Have they not implemented this yet? Maybe I'm the first person to test it? Definitely a common password[1]
> > ...and verify the password to make sure it is not one of the 10,000 most common known passwords by checking its hash
That bit confuses me - why the need to check the hash? You have the password plain and you have the list plain, just compare the strings directly.
If you have a hashed version of the list and are comparing hashed passwords to that, then you are hashing your passwords wrong: the parameters to your salt function should vary per-password so that people using the same password as each other (or someone using the same password for many accounts) are not obvious should your credentials store be compromised.
> I think a nice middle ground is to insert standard pauses of moderately increasing size after repeated sequential failures or repeated sequential forgot password requests from the same IP address. So that's what we do.
I like this. Captchas annoy the end-user and have been completely broken by foreign manual typers with an API (e.g. http://humancoder.com/). It seems to me pauses would solve the issue, at least an IP level, without any inconvenience to the end-user.
The 'email does not exist' decision they make here is debunked for one single reason: risk assessment. Is there a risk associated with implementing this use case that outweighs not implementing this use case? Here the use case is 'tell someone if their email is [not] registered', and the risk is 'identifying existing user accounts at login time'. So let's see which is appropriate.
In the best case, implementing this feature lets a user know which of their e-mail addresses are registered on your site, giving them an easier log-in. In the worst case, an attacker can immediately identify what users have accounts on this site, exposing the users to a violation of privacy.
Some counter that site registration will always provide this information when attempting to register an existing e-mail address. But this is easily mitigated: a captcha as well as holding off verification until the last step of registration puts the brakes on the attacker, making it more difficult to scan through potential accounts. By slowing down their attack methods you're helping to reduce risk.
And finally, do we really need to tell the user what e-mail they used? I'll wager that the great majority of users enable browser form-filling, and so their e-mail is sitting right there in the login box waiting for a password. And i'd also wager that most users with multiple e-mails will be cognizant of which they use for an account on a site like yours. So to avoid the few times a user doesn't save form fields and can't remember which e-mail they use for sites like yours, bad people get an easier way to do bad things.
For these reasons I think it's clear that the minor inconvenience in a very small number of cases is worth it to help slow down privacy violation en-masse.
---
Nit-pick: why would God call the field 'User' if they really meant 'Email'?
Maybe out of scope of the article, but for the section on rate-limiting he could maybe mention tptacek (and others') advice and recommend using bcrypt.
> Oops, the user entered their email as [email protected] instead of [email protected]? Or [email protected] instead of [email protected]?
...
> when presented with a login dialog, like to rapidly type
> [email protected], tab, p4$$w0rd, enter
...
So... Tell me. Considering that you don't block people finding out email addresses on Discourse in the interests of user-friendliness, why on earth are you blocking email addresses, and ones for the purpose of examples at that? An interesting juxtaposition there, and rather ironic, to put it mildly.
Also:
> I think a nice middle ground is to insert standard pauses of moderately increasing size after repeated sequential failures or repeated sequential forgot password requests from the same IP address. So that's what we do.
So what about NATs? There are countries with one public IP address.
I was actually surprised by how Snapchat handles it. When I tried creating an account, it told me my login is already taken(something that is super weird, since I have never found anyone else using it), so I assumed I already must have an account. I clicked on "forgot your password" , entered my email, and in fact - I have received a "password reset" email. Clicked on the link, typed in new password.....but then when I tried logging in it told me this account doesn't exist. So it allowed me to reset a password for an account that never existed - and that struck me as really interesting.
Yeah, I am sure they are sending the "password reset" email out intentionally even though they fully know this account doesn't exist, so an attacker wastes resetting a password for it.
Jeff was a big OpenID proponent while developing StackOverflow, and it looks like he still is. Even if he's recognized the necessity of offering a more common login approach.
Email is such a terrible way to associate identity. And, I think the industry is really misguided in not taking on the challenge of standardizing identity in a way that's not tied to email (or phone, or phone number, more recently). Sure, it's the quick way, the path of least resistance, but there are so many issues with email as identity, and it's really frustrating to me, as a user.
Like what? Email gives you a name and a domain, which gives you the ability to pick your name and your namespace. It's a pretty good system. In fact, I work for an ISP that will let you pick an email-looking identifier to log into HBO Go etc. even if we don't actually host your email.
Over the years, I've had to accumulate many different email addresses. I have all of my work addresses, and then I have all the multiples of gmail, hotmail, live mail, yahoo mail, icloud, etc. Each of these addresses is associated with different web accounts, and I can't consolidate or even associate different addresses to different accounts. Worse, I can't migrate to a new email provider (say, my own) without lots of work.
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.
On letting the user switch between register and login at any time, there is one small thing that tumblr does that I like.
If you go to tumblr.com it displays the registration page with email/password/username. If you just type in email+password on this page, it still works. So an incomplete registration form can be used to login.
I think email+password is still too confusing for "normal" people. Phone number + OTP is becoming very popular in apps, especially in developing countries where a lot of people don't even have/know what email is. I think this was mentioned in a recent a16z podcast as well.
People always need to feel superior in some way (picking apart spelling mistakes, ad hominems, etc.), and on the Internet, it's so low-cost to do so. Doesn't matter how "civil" the community may seem.
I suspect that many users when told their password is too common simply add a "1" or "123" suffix. Such behaviour would significantly weaken this method of using the top 10,000 password list as a filter.
As I see it, this problem will only be solved satisfactorily once we have technology (and security) to do away with frigging passwords completely. As the Internet plays a role in ever more aspects of society and industry, we need a concept of identity there that is usable by absolutely everyone without any mental effort.
The problem is, this goes totally against the idea of Internet privacy. I think it's either-or case. If you want to solve passwords, you'll have to drop any dream of anonymity.
Personally I love the Facebook approach. Facebook just accepts passwords with caps lock inverted, so you never have the problem in the first place. No need to display a message to the user.
Link: http://www.zdnet.com/article/facebook-passwords-are-not-case...