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.
Related
I was just about to write my hundredth login form when a thought crossed my mind: Why do I need a username?
A while ago my dad had to change his e-mail-address, and he still didn't figure out, why he can't log into various websites with his new address.
I'm also not a huge fan of individual per-site usernames. And wouldn't it be easier to remember only a password?
What are usernames good for? You obviously need some unique string to identify a user by. If you had just the password, that would work until a user picks a taken password and you would have to tell him “Sorry, 'GreatPassword123' already belongs to another user” — bad idea.
So part of the password needs to be unique. My idea: Predetermine the first three characters! You could choose from lower- and uppercase letters and digits, providing (26+26+10)^3 = 373,248 unique prefixes. At registration, the user would get a dialog, telling him that he only needs a password, and it starts with “N0i” for example, he has to pick the rest (“deaWhy” comes to mind). He can then log in with his password only, being “N0ideaWhy”, not knowing (or caring) that “N0i” actually is a unique username.
I see the following pros and cons:
Pros
independence from e-mail-addresses
user needs to remember just one string
might reduce password reuse
safe from leaked lists
faster login through fewer keystrokes
Cons
need to split the password-string and submit the first three characters unencrypted while hashing the rest
scalability comes to a dead stop at 373,248 users (or 26.8 million if you use four characters)
users might be skeptical / unexperienced / thrown off by not being able to reuse their standard password
I'm really wondering why nobody else did this so far? Are there any concerns that I missed?
By adding three random characters, you created a link between the password and the user, in other words a login. Beside the elements you mentionned, this login also has other problems:
it is much harder to remember (xhkr vs john.doe#example.com)
it cannot be unique across your services, even if you wanted to
you will need to request the email anyway in order to reset the password
What you are looking for has kinda been implemented already via social logins:
The idea is to use an independent service to handle your authentication. If every service owner would agree then you will end up with a unified login. It raises several concerns (lock-in, hack of the provider, personal data dissemination) but this is closest to what we came up with regarding centralized authentication (the grand father was OpenID): you just need to stay with one service (or a limited few).
If your site will be predominantly used by children of age group (5-15 yrs), would the password restrictions remain the same as it is enforced on a regular site.
(e.g. it should be at-least 6 characters in length and it should contain a mix of alphanumeric and some special characters. Regular sites used by adults usually have restrictions like this).
What kind of restrictions would you put on kids or do you let the parents do the login for their respective children. From my experience even a 5 yr old, seems quite protective of his password but they do unknowingly share it with others.
Suggestions on any good practices would help and our site is primarily intended for practicing homework assessments.
My first instinct would be not to create yet another password / login combination, but to use OpenID instead
I think you should think of it like this:
Password strength is not a question of the age of a user its question of how easy it is to crack a password. So as such you shouldn't risk the security of your accounts on that level.
What I think is that in most case it is the browser that will handle the login most of the time (sessions, auto fill of the fields...).
you are concerned that a 5 year old would be protective, but he is not going to register, its the parents for the kid and once you add a keep me logged in option then the parent set it up and the kid can use it without worry.
hope that can help you
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)
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.