On more than one occasion I've been asked to implement rules for password selection for software I'm developing. Typical suggestions include things like:
Passwords must be at least N characters long;
Passwords must include lowercase, uppercase and numbers;
No reuse of the last M passwords (or passwords used within P days).
And so on.
Something has always bugged me about putting any restrictions on passwords though - by restricting the available passwords, you reduce the size of the space of all allowable passwords. Doesn't this make passwords easier to guess?
Equally, by making users create complex, frequently-changing passwords, the temptation to write them down increases, also reducing security.
Is there any quantitative evidence that password restriction rules make systems more secure?
If there is, what are the 'most secure' password restriction strategies to use?
Edit Ólafur Waage has kindly pointed out a Coding Horror article on dictionary attacks which has a lot of useful analysis in it, but it strikes me that dictionary attacks can be massively reduced (as Jeff suggests) by simply adding a delay following a failed authentication attempt.
With this in mind, what evidence is there that forced-complex passwords are more secure?
Something has always bugged me about
putting any restrictions on passwords
though - by restricting the available
passwords, you reduce the size of the
space of all allowable passwords.
Doesn't this make passwords easier to
guess?
In theory, yes. In practice, the "weak" passwords you disallow represent a tiny subset of all possible passwords that is disproportionately often chosen when there are no restrictions, and which attackers know to attack first.
Equally, by making users create
complex, frequently-changing
passwords, the temptation to write
them down increases, also reducing
security.
Correct. Forcing users to change passwords every month is a very, very bad idea, except perhaps in extreme high-security environments where everyone really understands the need for security.
Those kind of rules definitely help because it stops stupid users from using passwords like "mypassword", which unfortunately happens quite often.
So actually, you are forcing the users into an extremely large set of potential passwords. It doesn't matter that you are excluding the set of all passwords with only lowercase letters, because the remaining set is still orders of magnitude larger.
BUT my big pet peeves are password restrictions I've encountered on major sites, like
No special characters
Maximum length
Why would anyone do this? W.H.Y.????
A nice read up on this is Jeff's article on Dictionary Attacks.
Never prevent the user from doing what they really want, unless there is a technical limitation from doing so.
You may nag the hell out of the user for doing stupid things like using a dictionary word or a 3-character password, or only using numbers, but see #1 above.
There is no good technical reason to require only alphanumerics, or at least one capital letter, or at least one number; see #1 above.
I forget which website had this advice regarding passwords: "Pick a password that is very easy for you to remember, but very hard for someone else to guess." But then they proceeded to require at least one capital letter and one number.
The problem with passwords is that they are so ubiquitous that it is essentially impossible for any person without a photographic memory to actually remember them without writing them down, and therefore leaving a serious security hole should someone gain access to this list of written-down passwords.
The only way I am able to manage this for myself is to split most of my passwords -- and I just checked my list, I'm up to 130 so far! -- into two parts, one which is the same in all cases, and the other which is unique but simple. (I break this rule for sites requiring high-security like bank accounts.)
By requiring "complexity" as defined as multiple types of characters all present, is that it forces people into a disparate set of conventions for different sites, which makes it harder to remember the password in question.
The only reason I will acknowledge for sites limiting the set of allowable password characters, is that it needs to be typeable on a keyboard. If you have to assume the account needs to be accessed from multiple countries, then keyboards may not always support the same characters on the user's home keyboard.
One of these days I'll have to make a blog posting on the subject. :(
My old limit theorem:
As the security of the password approaches adequate, the probability that it will be on a sticky note attached to the computer or monitor approaches one.
One also might point out the recent fiasco over at twitter where one of their admin's password turned out to be "happiness", which fell to a dictionary attack.
For questions like this, I ask myself what Bruce Schneier would do - the linked article is about how to choose passwords which are hard to guess with typical attacks.
Also note that if you add a delay after a failed attempt, you might also want to add a delay after a successful attempt, otherwise the delay is simply a signal that the attack has failed an other attempt should be launched.
Whilst this does not directly answer your question, I personally find the most aggrevating rule I have encountered one whereby you could not reuse any password previously used. After working at the same place for a number of years, and having to change your password every 2/3 months, the ability to use a password I chose over a year ago would not seem to be particularly unsafe or unsecure. If I have used "safe" passwords in the past (Alphanumeric with changes in case), surely reusing them after a perios of say a year or 2 (depending on how regularly you have to change your password) would seem to be acceptable to me. It also means I am less likely to use "easier" passwords, which might happen if I can't think of anything easy to remember and difficult to guess!
First let me say that details such as minimum length, case sensitivity and required special characters should depend on who has access and what the password allows them to do. If it's a code to launch a nuclear missile, it should be more strict than a password to log in to play your paid online edition of Angry Birds.
But I've got a SPECIFIC beef with case sensitivity.
For starters, users hate it. The human brain thinks "A=a". Of course, developers brains' aren't usually typical. ;-) But developers are also inconvenienced by case sensitivity.
Second, the CapsLock key is too easy to hit by mistake. It's right between Tab and Shift keys, but it SHOULD be up above the Esc key. Its location was established long ago in the days of typewriters, which had no alternate font available. In those days it was useful to have it there.
All passwords have risk... You're balancing risk with ease-of-use, and yes, usability matters.
MY ARGUMENT:
Yes, case sensitivity is more secure for a given password length. But unless someone is making me do otherwise, I opt for a longer minimum password length. Even if we assume only letters and digits are allowed, each added character multiplies number of the possible passwords by 36.
Someone who's less lazy than me with math could tell you the difference in number of combinations between, say a minimum 8-character case-sensitive password, and a 12-character case-insensitive password. I think most users would prefer the latter.
Also, not all apps expose usernames to others, so there are potentially two fields the hacker may have to find.
I also prefer to allow spaces in passwords as long as the majority of the password isn't spaces.
In the project I'm developing now, my management screen allows the administrator to change password requirements, which apply to all future passwords. He can also force all users to update passwords (to new requirements) at any time after next logon. I do this because I feel my stuff doesn't need case-sensitivity, but the administrator (who probably paid me for the software) may disagree so I let that person decide.
The PIN for my bank card is only four digits. Since it's only numbers it's not case sensitive. And heck, it's my MONEY! If you consider nothing else, this sounds pretty insecure, were it not for the fact that the hacker has to steal my card to get my money. (And have his photo taken.)
One other beef: Developers who come onto StackOverflow and regurgitate hard-and-fast rules that they read in an article somewhere. "Never hard code anything." (As if that's possible.) "All queries must be parameterized" (not if the the user doesn't contribute to the query.) etc.
Please excuse the rant. ;-) I promise I respect disagreement.
Personally for this paticular problem I tend to give passwords a 'score' based on characteristics of the entered text, and refuse passwords that don't meet the score.
For example:
Contains Lower Case Letter +1
Contains different Lower Case Letter +1
Contains Upper Case Letter +1
Contains different Upper Case Letter +1
Contains Non-Alphanumeric character: +1
Contains different Non-Alphanumeric character: +1
Contains Number: +1
Contains Non Consecutive or repeated Second Number: +1
Length less than 8: -10
Length Greater than 12: +1
Contains Dictionary word: -4
Then only allowing passwords with a score greater than 4, (and providing the user feedback as they create their password via javascript)
Related
I was thinking of making a check to remember a user that their password is case sensitive in case they got their password right but forgot to use the uppercase characters in their password.
The first idea was to simply add a field with a lowercase password hash and check (when the password check failed) if the lowercase password inserted matched the lowercase
PseudoCode
if(getpasswordHash(password.toLower()) == databes_lower_hash){
writeMessage("Remember that your password is Case Sensitive")
}
Will this lower my password security ?
Should I use a different salt for the lowercase password and the normal password ?
Should I just not bother and just give the message about case sensitivity everytime someone get the password wrong ?
yes, it would lower your security.
you are trying to help user by changing the usual two-state (pass/fail) scenario to three-state (pass/fail-but-you-are-near/fail) scenario. this intermediate state that you are introducing will certainly lower your security.
here is how:
say a hacker gets some hint that my password is 4 characters. if he goes sheer brute-force way then the he has to try (26*2)^4 combinations. but once you implement this, then in just (26)^4 combinations he would get a ... Remember that your password is Case Sensitive ... message. from that point on, he has to try a maximum of 2^4 combinations for small/upper cases of each character. thus the brute-force barrier is significantly reduced.
you would now have to store two hashes in your database. even if you use different salts, which you must anyway, you are again reducing the brute force barrier by half. to crack a password, the hacker can now deploy two separate computers devoted to cracking one hash each. effectively reducing the time in half.
of course these are extreme scenarios. passwords are never allowed to be 4 characters long. there would be special chars as well. there is a lean chance of a military class hacker to target your application. you dont see how on earth someone can ever steal your password-table. but all of these can be debated against. there is social engineering, system vulnerabilities, and yes even your application can attract serious hackers. all it takes for your application is to attract crowd. and with crowd comes the bad guys.
so rule of thumb is:
with security, always follow the established norms. there are landmines everywhere else.
respect everyone's password with utmost care as it those are the passwords of the bank-vault itself.
1.) Yes of course. But to the same level like only allowing lowercase in the first place.
3.) Would be a cleaner solution.
Is it a good idea to ban users from choosing common passwords, it might be overkill for a small site, with a couple of thousand visitors a month... but if you sell a product or service where money exchanges hands, would you consider doing this?
I think it makes perfect sense to enforce some level of security on passwords.
Instead of banning a list of common passwords you should consider making your users aware of the security issues when they are choosing a weak password, and perhaps even require them to use a mix of different cases, numbers, symbols etc.
If it involves money or personal information you should force the user to have at least 6 characters of a mixture between numbers and letters (many say 8 but I like 6). You may want to store a table of common quick passwords that people should not use like 123456, etc.
You should also link an expiration date for each password (in my particular case users must change there password every 3 months). Keep track of previous passwords and warn users that they cannot use the same password (for at least a duration of time).
What you're talking about is a password strength policy, and is very common with financial institutions and academic websites. My university enforces a minimum of 6 characters, with at least one uppercase, lowercase and non-alphabetical character, for example. Policy compliance can be checked by a simple regular expression.
I think this website has the answer.
Passwords don’t have to be Long and Complex
Forcing complex passwords provides virtually no security. I know this won't be popular but it is. Here is why; as password requirements got more complex it has become more common for users to use the same password across multiple sites.
Since a password with 2 upper, 2 lower, 2 number, and 2 special characters likely meets the password complexity requirements for most websites it WILL be reused.
Far more effective method to breach a website especially one that uses email address as username is to attack another website and then match those emails against your usernames. Even better Even better is to offer some "free" service which requires a login (free mp3, free porn, free gift card, etc).
If I make a website and store username & passwords in plaintext the odds are good and increase with number of unique users that we share a user in common (email address) and given enough shared users the likelihood approaches 100% that at least one of those users has re-used the same password. I know username/password on my site thus I know the username/password on your site.
You should impose some minimum complexity requirements just to avoid common password & dictionary attack but don't burden your users with ultra strong password requirements. You create a lot of grief for little real security. Real security is often hard. If you want real security you likely need two factor authentication. My brokerage for example doesn't allow me to choose my own username (which often will be reshared) and requires a RSA token to login, along with my password. Something I have + something I know.
Even better would be 3 factor authentication; adding geolocation of login with further authentication from new/unknown location.
Many websites have password strength checking tool, which tells you how strong your password is
Lets say I have
st4cK0v3rFl0W
which is always considered super strong, but when I do
st4cK0v3rFl0Wst4cK0v3rFl0W
it is suddenly super weak. I've also heard that when password have just small repeating sequence, it is much weaker.
But how possibly can the second one be weaker than the first one, when it is twice as long?
Sounds like the password strength checker is flawed. It's not a big issue, I suppose, but a repeated strong password is not weaker than the original password.
My guess is that it's simply trivial to check for someone attacking your password. Trying each password doubled and tripled too is only double or triple the work. However, including more possibly characters in a password, such as punctuation marks, raises the complexity of brute-forcing your password much more.
However, in practice, nearly every non-obvious (read: impervious to dictionary attacks [yes, that includes 1337ifying a dictionary word]) password with 8 or more characters can be considered reasonably secure. It's usually much less work to social engineer it from you in some way or just use a keylogger.
I guess because you need to type your password two times by using the keyboard, so for that maybe if some one is in front of you can notice it.
The algorithm is broken.
Either uses a doublet detection and immediately writes it off as bad. Or calculates a strength that is in some way relative to the string length, and the repeated string is weaker than the comparable totally random string of equal length.
It might be a flaw by the password trength checker - it recognises a pattern... A pattern is not good for a password, but in this case it is a pattern on a complex string... Another reason can be the one pointed out by answer from Wael Dalloul : Someone can see the repeated text when you type it. Any spies have two chances of seeing what you type...
The best reason that I could think of, comes from the Electronic Authentication Guide, published by NIST. It gives a general thumb rule on how to estimate entropy in a password.
Length is just one criteria for entropy. There is the password character set that is also involved, but these are not the only criteria. If you read Shannon's research on user selected passwords closely, you'll notice that higher entropy is assigned to initial bits, and and lesser entropy to the latter, since it is quite possible to infer the next bits of the password from the previous.
This is not to say that longer passwords are bad, just that long passwords with a poor selection of characters are just as likely to be weak as shorter passwords.
My guess is it can generate a more "obvious" hash.
For example abba -> a737y4gs, but abbaabba -> 1y3k1y3k , granted this is a silly example, but the idea is that repeating patterns in key would make hash appear less "random".
Whilst in practice the longer one is probably stronger, I think there may be potential weaknesses when you get into the nitty gritty of how encryption and ciphers work... possibly...
Other than that, I'd echo the other responses that the strength-checker you're using isn't taking all aspects into account very accurately.
Just a thought...
There are many techniques to enforce strong passwords on website:
Requesting that passwords pass a regex of varying complexity
Setting the password autonomously, so that casual users have a strong password
Letting passwords expire
etc.
On the other hands there are drawbacks, because all of them make life less easy for the user, meaning less registrations.
So, what techniques do you use? Which provide the best protection vs. inconvenience ratio?
To clear things up, I am not referring to banking sites or sites that store credit cards. Think more in terms of popular (or not-so-popular) sites that still require registration.
I don't think it's possible to enforce strong passwords, but there are lots of things you can do to encourage them as much as possible.
Rate each password and give the user feedback in the form of a score or a graphical bar, etc.
Set a minimum password score to weed out the awful ones
Have a list of common words that are either banned, or tank the password score
One excellent trick I like to use is to have the password's expiry date tied to the password score. So stronger passwords don't need to be changed so often. This works particularly well if you can give users direct feedback about how long the password they've chosen will live for (and dynamically update it so they can see how adding characters affects the date).
Don't enforce anything ... if you are not protecting financial information or something equally important, then don't make the user choose a strong password.
I have the same weak password on a whole load of sites that require registration for forums, etc. I don't really care if someone guesses it and can post messages as me (and don't think there is much motivation for someone to do so). What I can't do is remember different strong passwords for a dozen sites and don't really want to use another piece of software to manage them for me.
The best compromise would be to show some kind of feedback to the user on how strong the password is (based on whether it is a dictionary word, number of different character types, length, etc).
Why enforce it?
I found that a "password strength meter" (a bar indicating password strength as you type) is usually a good non-intrusive measure. It makes those who care about security to have a guilty conscience about password weakness, yet does not frustrate those who do not care as much.
Also, there is an insightful essay on why periodic password change policy is a bad idea with today's threat model.
It's been my experience that it depends really on the type of site, as you said.
If you are creating a bank or financial website then users typically understand if you have a more secure password, since their personal data may be at risk.
However for sites that typically don't contain a lot of personal information a simpler password will be fine. They may be less prone to hack attempts, and wouldn't get anything worthwhile anyway.
I've also found that most people also seem to have a couple passwords they use often. One being complex, and another being simple. So requesting they use a complex password usually won't keep people from registering.
I've never found expiring passwords to work successfully. As I said before, many people already have a set couple of passwords they use often, so asking them to go outside of this just for your site may make them not want to come back.
The best way really depends on your site and what you are using. But the ideal way is to do as much on the client side as you can before they submit it. Using RegEx is a good way. If you can make them not have to submit the form again, that is ideal.
On letting passwords expire, there are two notable problems with the practice:
Users find it more difficult to remember their current passwords, and so they are more likely to do silly things like write them on a post-it stuck to their monitor.
Users don't generate a new, strong, unrelated password on each attempt. Most of the time they use some scheme to generate a password similar to their old one. Therefore, if an attacker gets an old password, it's still pretty easy for them to deduce a newer one.
EDIT: Which isn't to say I'm against the whole idea, but just that this needs to be considered along with other factors.
There's an Ajax tool, PasswordStrength, that will give the user an idea if their password is any good. I like it because it doesn't have to prohibit the creation of a password.
http://www.asp.net/AJAX/AjaxControlToolkit/Samples/PasswordStrength/PasswordStrength.aspx
I've never seen this done, but it seems like it would work wonderfully: the password creation page could have an expandable list of the,say, the 50 most common passwords, forcing the user to scroll down a bit before typing in their password. This, combined with Checkers' suggestion, would do much to prevent careless choices.
However, solving the problem of preventing password reuse... no clue.
I am a programmer at a financial institute. I have recently been told to enforce that all new user id's to have at least one alpha and one numeric. I immediately thought that this was a horrible idea and I would rather not implement it, as I believe this is an anti-feature and of poor user experience. The problem is that I don't have a good case for not implementing this requirement.
Do you think this is a good requirement?
Do you have any good reasons not to do it?
Do you know of any research that I could reference.
Edit: This is not in regards to the password. We already have similar requirements for that, which I am not opposed to.
One argument against this is that many usernames / ids in other areas do not require numeric components. It's more likely that users will be better able to remember user ids that they have used elsewhere -- and that is more likely if they do not need to include numerics.
Furthermore, depending on the system, the user ids may work well as defaults when connecting to external systems (ssh behaves this way under unix-like systems). In this case, it is clearly beneficial to have one ID that is shared between systems.
Using the same ID in multiple places improves consistency, which is a well-known aspect of good software interfaces. It's not too difficult to show that the way people interact with a system is a user-interface, and should adhere to (at least some) of the well-known interface guidelines. (Obviously ideas like keyboard shortcuts are meaningless if you're considering the interactions between multiple, possibly unknown, systems, but aspects such as consistency do apply.)
Edit: I'm assuming that this discussion is about usernames or publicly visible IDs, NOT something that pertains directly to security, such as passwords.
I would begin by asking them for their specific reasons behind this. Once you have a list of bullet points and the reasons why, it's easier to refute or provide alternatives.
As for general ideas:
This is opinion, but adding a numeral to a username won't necessarily increase security. People write down usernames on post it notes, most users will just add a '1' to the beginning or end of their username, making it easy to guess.
From a usability standpoint, this is bad as it breaks the norm. Forcing them to add a numeral to their username will just lead to the above point. They will simply add a '1' to the end or beginning of their username.
Remember, the more complex an authentication system is, the more likely a general user is to find ways to circumvent it and make their link in the chain weak.
UserIDs? Requiring passwords to be alphanumeric is generally a good idea, since it makes them more resistant to a dictionary attack. It doesn't really make any sense for usernames. The whole point of having a name/password combo is that the name part doesn't have to be kept secret.
If you're working at a financial institution, there are probably regulations about this sort of thing, so it's most likely out of your hands. But one thing you can do is make it clear to the user when he has entered an invalid ID. And don't wait until he clicks submit; show some kind of message right next to the field, and update it as he types.
A few of the answers above have a counter-argument: If the users pick the same username they use on the other sites, then they are also likely to pick the same or similar passwords for the financial site, lowering security.
A reason not to do it: If you impose more restrictions than they are used to on the users, they will start writing down the login information, and that's an obvious loss of security.
Both of the bank accounts I have require an alphanumeric username and two passwords for the online login. One of them also has a image I have to remember. The two passwords have to change once a month or so. Therefore, I have all the login information right here on a text file. (Even looking at it doesn't make any sense; I'll have to go down to the bank and reset my passwords again. That's a grand total of 7 password resets for 6 logins. Talk about security, not even I can access my account.)
it's good if it's in their password (as alas, financial companies like to deny you this security right [i'm talking to you american express]).
username, i say no, unless they want to.
A username will (presumably) need to be quoted on the phone when calling for support so it will be publicised unlike a password. Also, the username field won't be masked out in browsers like password fields are, so it will have much more exposure and get cached/logged in various places, so the 'benefit' of the added security will be undone in no time.
And the more difficult you make things, the more likely a user is to write it down somewhere which again undermines security (same applies for password policies actually, but that's another story!)
I also work at a financial institution and our usernames (both real people and production IDs) are all lowercase, alphabetical, up to 8 characters and I've never considered it a problem... avoids the confusion of 0 vs O, 1 vs I, and 8 vs B - unless you work for the same company as me and are about to implement a new policy...
Adding any feature adds costs. It will take time now to build and test it, and in the future to support it. No feature should be built without a really good reason.
This feature is pointless. Usernames are not supposed to be kept secret, so having strong usernames has no advantage. It is probably worth spending time making passwords (or other authentication factors) strong, but users should be able to communicate their username to other users without that being a security risk.
If your application imposes extra constraints on the choice of user ID then some of your users will have a different user ID for your application than for the other applications in your environment. Note: I'm assuming that this is an internal application (for use by employees) rather than in Internet-facing application.
Having inconsistent usernames adds a number of specific risks:
It will make the audit trail harder to follow (a serious security risk).
It may add cost if you later start using single sign on.
It will cause a bad user experience as users have to remember that this application uses a weird username.