Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Whenever I choose a password, they say get a strong one, or hackers will easily get access to it.
Why?
Previously I used to believe that hackers may make a robot/software that tries many many possible combinations of passwords per second and a hard password may make the process a bit lengthy and add an extra layer of security. But as I see now that popular sites don't allow more than five or ten login trials, also they do some verification if you are logging in from another place. Then what makes hackers to successfully get access to our password if it is a poor one (like only alphabet, or only numbers).
(Is this a wrong place to ask such questions?)
This question is rather off-topic for SO.
If your password is very easy to guess (eg "password" or "1234"), then even the online attack you describe is quite feasible. But the primary threat to weak passwords is an offline attack. This is where an attacker gains access to a password database. In this situation, attacks are limited only by the attacker's resources.
Let's say you choose a completely random password of length 8 characters taken from the standard 96 characters. Some people would say that's not even a weak password. So how long will it take a knowledgeable attacker to find that password with an offline attack. Less than 6 hours!
Computationally-intensive approaches such as PKDBF2, bycrypt, and scrypt can slow down these offline attacks by a considerable factor. But nothing will help you if your password really is weak (eg a dictionary word or two).
Having said all that, the vast majority of end-users quite rationally believe that:
The chance of their account being compromised by a direct online attack is low.
The chance of their account being compromised by a direct offline attack is very low.
The bank or other organisation will likely make good any financial losses resulting from a direct offline/online compromise.
Given the above three facts, you can argue that it doesn't make sense to spend much time choosing strong passwords.
You never know how safe a given web application is when you register. So you have to do everything you can to make you're account as safe as possible. Often, setting your password is the only thing you can do (but it's always a thing you can do) to increase the security. That's why you have to do it.
It's a good habit to choose strong passwords: it always increases the security of your account. Even when it's a tiny bit.
Hackers tried simple passwords first, such as 12345678.
So if you set a simple password, it is likely that hackers guess the correct password within trial limit.
It is also possible that hackers see the message packet sent to server, which could contains password's hash value (mostly, MD5).
With this MD5 value, hackers can use brute-force or hash-collision to get a working original password string to get access to user account.
For example, a user sets 12345678 as password, hackers can run a brute-force crack within 10^8 trials to get the password (10 digit, 8 bytes length), but for password like W~9cE_f8 it is a lot difficult to crack (it needs much more trials, approx 70^8 (26 characters, upper-case + lower-case, special symbols, digits, etc), this takes a lot of time, which makes the account less profitable to the hackers, therefore a stronger password may make account safer.
Above is just a brief explanation. Information Security related topic hardly has exact and clear answers. It is also impossible to ensure 100% safety.
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...
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.