CSC 379 SUM2008:Week 3, Group 3
Costs and Benefits Password Regulations
“Best practices” sometimes seem to take on a life of their own, independent of any recent assessment of their costs and benefits. An example is password policies; maximum length, restrictions on characters that can be used, and password-change frequency. Evaluate these popular password regulations. Do they provide adequate benefits for costs incurred? What ethical considerations do poorly evaluated “best practices” raise? Do policy-makers have an ethical responsibility to evaluate “best practices” before adopted? A responsibility to re-evaluate existing practices?
Cite specific evidence in your cost/benefit analysis from quality sources (professional/academic journals preferred).
- http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1013839
- http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1588836
- http://portal.acm.org/citation.cfm?id=322796.322806
- http://portal.acm.org/citation.cfm?id=581370
- http://portal.acm.org/citation.cfm?id=986664
"Best Practices" Research
Policies
Password Length
The length of a password considers the minimum and/or maximum lengths characters comprising the password. The minimum required length varies, usually ranging from 6-8 characters, symbols or digits. Maximum length requirements are often not an issue since users tend to employ passwords that just meet the minimum length. Also, the maximum length of a password is in direct relation to the number possible passwords. As the maximum is decreased, the number of password combinations is also decreased. When it comes to security, most would agree that password length is more important than password complexity.
Password Complexity
Password Change Frequency
Policies for major corporations usually require that employees change their password after a certain period of time. Typically, this time frame may be from 90 days to 6 months. The requirement to change your password at certain time intervals limits the amount of time a hacker has to break your current password. In addition, if a hacker has retrieved your password, they only have a limited amount of time to access it before your password is changed. The later reason can be considered quite useless as it only takes a hacker minutes or, at the most, hours to retrieve the information they are looking for.
A major downside to the policy of requiring changing a password after a certain amount of time is the fact that most users will simply change it to the old address anyway, thus nullifying any benefit that could be gained from changing you password frequently. There are few studies on whether changing your password after a certain amount of time has actually increased security. Also, employees do not want to waste time changing their password frequently and must be reminded. This requires unnecessary resources devoted to a practice that the user probably won't follow anyhow.
There was no easily available evidence that any benefit has been gained from adopting this policy.
Password History Restriction
Some companies have begun to adopt what are called password history restrictions. With this policy, when a user is required to change their password after a certain amount of time; they are constricted from using a certain number of previous passwords. Typically, this may range from just one previous password, all the way to five. The goal of this policy is to prevent the use of the same password over and over that hackers have been trying to brute force hack. If a user is required to change their password over time intervals, there is no incentive for security improvements if the user just keeps putting down the same password.
A major downfall of this policy is that the more previous passwords the user can not use, the more inclined the user is to simply write that password down. Trying to remember what one to five passwords a user used for even just one account is overly tedious to the user and waste company resources for the user to keep track of making and remembering an updated password.
There are no easily available research to prove that there are any real security benefits from adopting this policy. In addition, there is also no research to prove how much users will write down passwords and to what password history restriction limit would drive them to write down passwords.
Password Retrieval
To help verify a user's identity in the case of a lost password, many Web applications use secret questions. By answering a pre-selected question, a user can demonstrate some personal knowledge of the account owner. A classic example is asking to provide a mother's maiden name.
Answering secret questions requires some knowledge of the user account, but secret questions break all the rules for strong passwords and have some significant weaknesses:
1. An attacker can sometimes discover the information with little research
2. The answer to the question is usually a fact that will never change
3. Users reuse the same secret questions and answers across multiple Web sites
4. Someone close to the individual could know the answers to many of the questions
5. People rarely change their secret questions
6. The answers are often case-insensitive and usually contain a limited character set
7. Some questions have a limited number of answers
8. With some questions, many people will have the same common answers
Secret questions usually ask for an obscure fact that hopefully only the account owner would know and supposedly would never forget. Many Web sites assume that the user providing the answer to the question is sufficient to identify the user. However, many secret questions ask for facts that anyone could discover with little research. To make things worse, if someone discovers this information, you cannot just change a fact from the past.
Alternate Security Measures
As a security measure, storing only hashes of passwords in your database will ensure that an attacker's job is made that much more difficult. Let's look at the steps they'll now take in an effort to compromise your system. Assuming that they've managed to access your user database and list of hashes, there's no way that they can then recover the original passwords to your system. Or is there?
The attacker will be able to look at your hashes and immediately know that any accounts with the same password hash must therefore also have the same password. Not such a problem if neither of the account passwords is known - or is it? A common technique employed to recover the original plain text from a hash is cracking, otherwise known as 'brute forcing'. Using this methodology an attacker will generate hashes for numerous potential passwords (either generated randomly or from a source of potential words, for example a dictionary attack). The hashes generated are compared with those in your user database and any matches will reveal the password for the user in question.
Modern computer hardware can generate MD5 and SHA-1 hashes very quickly - in some cases at rates of thousands per second. Hashes can be generated for every word in an entire dictionary (possibly including alpha-numeric variants) well in advance of an attack. Whilst strong passwords and longer pass phrases provide a reasonable level of protection against such attacks, you cannot always guarantee that your users will be well informed about such practices. It's also less than ideal that the same password used on multiple accounts (or multiple systems for that matter) will reveal itself with an identical hash.