It may not surprise you to discover that the Nevada governor doesn't send out his own weekly email updates. However, you should be alarmed that this task might not be limited to his trusted staff.
Declan McCullagh posted this news article about finding the governor's password in an Internet accessible Word document. The document contained step-by-step instructions for sending out email using the governor’s account. At the appropriate places, the account username and password for the governor were listed.
Whether anyone on the Internet could have logged in and sent mail as the governor is an interesting question, but I certainly assume that unauthorized folks within the state capital (possibly from opposition parties) could have. If a malicious email had been sent out, it would take more than a quick retraction to undo the damage.
The main lesson to take away from this incident is that your passwords should almost never be included in procedural documents. Instead, these appropriate steps should refer the reader to the appropriate secure password storage location (like an encrypted password safe) or to an employee who can properly limit password distribution to authorized personnel. Then your authentication system won't rely entirely on how well people protect an unencrypted electronic document.
Monday, July 30, 2007
Are passwords better than challenge questions?
Based on the negative ratings I assigned some challenge questions in this white paper, people have asked me if I believe challenge questions are worthless. No, they aren’t worthless. However, challenge questions have several inherent flaws that must be recognized and addressed for them to provide adequate authentication.
If we were to compare a typical challenge question answer with a typical password, we would find that the password is a better authenticator. A password has both more total and likely possibilities, which improves its uniqueness. It also has better integrity than a challenge question answer because it isn’t intentionally based on personal information.
Interestingly enough, the unstructured nature of passwords does actually present a risk that challenge questions avoid. Because asking for a password is the equivalent of asking "say anything", attackers don’t have to pay any attention to the question. A password guess of "llama" is just as acceptable as "redsox". With challenge questions, you would only expect to see "llama" as an answer to a question such as "what is your favorite animal". An answer of "redsox" for that same question doesn’t make sense and shouldn’t be guessed [1].
If a criminal wants to penetrate online identities using a brute force password guessing attack, they only need a single list of possible usernames and passwords. They may even do their research ahead of time and limit their list to the 100 or 1,000 most popular passwords. Then the attacker unleashes their password guessing software on the web application to find valid credential combinations.
When that same criminal wants to penetrate a challenge question authentication system using a brute force attack, they have more work to do. If the attacker uses the list of common passwords, they aren’t going to have much success, because challenge questions expect a specific type of answer. Instead, the attacker will have to come up with lists of the 100 most popular animals, 100 most popular authors, 100 most popular child names, etc. to fit the expected challenge question answers.
Once the attacker has done this initial groundwork (or just grabbed a list from someone else) they have to configure their software to match the right list of answers with the appropriate questions. This isn’t difficult, but does put another obstacle in their path.
Back to the original question, the real strength of challenge questions comes from the common practice of asking multiple questions to authenticate a user. An attacker can’t just run through 100 passwords and hope for a match. They have to find the right combination out of 100 animals, 100 authors, and 100 child names to penetrate a user account [2].
Since this approach is very time consuming (100 x 100 x 100 = 1 million total guesses) an attacker is likely to shorten their lists to the top 10 most popular answers for each type of question. Or they’ll choose a different challenge question authentication attack that requires less guesswork [3].
A single challenge question may not be better than a single password, but you don’t have to settle for that option. Address this flaw by choosing the right challenge questions and requiring users to correctly answer several of them during authentication.
1. Users don’t have to provide logical answer to challenge questions since there is no way for the system to check. Some people might purposely provide a nonsensical answer to a challenge question in an attempt to make it more password-like.
2. Depending on the particular application’s implementation of challenge question authentication, an attacker might have to guess both this combination and the user’s password.
3. See the white paper for descriptions of these alternative attacks against challenge question authentication systems.
If we were to compare a typical challenge question answer with a typical password, we would find that the password is a better authenticator. A password has both more total and likely possibilities, which improves its uniqueness. It also has better integrity than a challenge question answer because it isn’t intentionally based on personal information.
Interestingly enough, the unstructured nature of passwords does actually present a risk that challenge questions avoid. Because asking for a password is the equivalent of asking "say anything", attackers don’t have to pay any attention to the question. A password guess of "llama" is just as acceptable as "redsox". With challenge questions, you would only expect to see "llama" as an answer to a question such as "what is your favorite animal". An answer of "redsox" for that same question doesn’t make sense and shouldn’t be guessed [1].
If a criminal wants to penetrate online identities using a brute force password guessing attack, they only need a single list of possible usernames and passwords. They may even do their research ahead of time and limit their list to the 100 or 1,000 most popular passwords. Then the attacker unleashes their password guessing software on the web application to find valid credential combinations.
When that same criminal wants to penetrate a challenge question authentication system using a brute force attack, they have more work to do. If the attacker uses the list of common passwords, they aren’t going to have much success, because challenge questions expect a specific type of answer. Instead, the attacker will have to come up with lists of the 100 most popular animals, 100 most popular authors, 100 most popular child names, etc. to fit the expected challenge question answers.
Once the attacker has done this initial groundwork (or just grabbed a list from someone else) they have to configure their software to match the right list of answers with the appropriate questions. This isn’t difficult, but does put another obstacle in their path.
Back to the original question, the real strength of challenge questions comes from the common practice of asking multiple questions to authenticate a user. An attacker can’t just run through 100 passwords and hope for a match. They have to find the right combination out of 100 animals, 100 authors, and 100 child names to penetrate a user account [2].
Since this approach is very time consuming (100 x 100 x 100 = 1 million total guesses) an attacker is likely to shorten their lists to the top 10 most popular answers for each type of question. Or they’ll choose a different challenge question authentication attack that requires less guesswork [3].
A single challenge question may not be better than a single password, but you don’t have to settle for that option. Address this flaw by choosing the right challenge questions and requiring users to correctly answer several of them during authentication.
1. Users don’t have to provide logical answer to challenge questions since there is no way for the system to check. Some people might purposely provide a nonsensical answer to a challenge question in an attempt to make it more password-like.
2. Depending on the particular application’s implementation of challenge question authentication, an attacker might have to guess both this combination and the user’s password.
3. See the white paper for descriptions of these alternative attacks against challenge question authentication systems.
Wednesday, July 25, 2007
T1me 0ut for Fox News
An IT administrator neglected to turn off directory browsing on a portion of the Fox News web site, and this was all one curious hacker needed to penetrate a server. On Monday a blog post disclosed that the author had looked through files on the Fox News web server until they found a readable shell script. This script happened to contain a username and password ("T1me 0ut") used for FTP access to a server.
After the hacker successfully used the credentials to log in, he shared the news with anyone who happened to read his blog. When the blog entry was discussed on Slashdot, his audience grew substantially and the incident gained national attention.
Besides the obvious security oversight, Fox News may also be guilty of lying to the public. In this article posted by Fox News, they claim "this password, however, was long disabled." Unless the screenshots (originally appearing along with the blog entry) of FTP directory listing from their server were faked, the password was obviously still active.
Fox News goes on to state that no "user information [...] or other personal data were ever compromised." This claim has also been contested by hackers who report they were able to download files containing names, email addresses, and telephone numbers of over 1.5 million users.
Why Fox News would choose to make false claims about the incident is uncertain, especially if no truly sensitive personal information was disclosed. What is certain is that a few people in their organization do deserve a time out for bad behavior.
After the hacker successfully used the credentials to log in, he shared the news with anyone who happened to read his blog. When the blog entry was discussed on Slashdot, his audience grew substantially and the incident gained national attention.
Besides the obvious security oversight, Fox News may also be guilty of lying to the public. In this article posted by Fox News, they claim "this password, however, was long disabled." Unless the screenshots (originally appearing along with the blog entry) of FTP directory listing from their server were faked, the password was obviously still active.
Fox News goes on to state that no "user information [...] or other personal data were ever compromised." This claim has also been contested by hackers who report they were able to download files containing names, email addresses, and telephone numbers of over 1.5 million users.
Why Fox News would choose to make false claims about the incident is uncertain, especially if no truly sensitive personal information was disclosed. What is certain is that a few people in their organization do deserve a time out for bad behavior.
Circumventing password reset systems
A hacker who goes by the alias “pdp” recently posted information about Attacking Password Recovery Facilities on his blog. He reviews several approaches to gaining unauthorized access to user accounts by circumventing security in the password recovery function of a system rather than trying to guess a user’s password.
Since attackers will often follow the path of least resistance in penetrating a host, it is incredibly important to make sure that password recovery functionality is designed to resist attacks.
I described one of the attacks, determining the answers to a user’s challenge questions, in the white paper I mentioned in a past blog entry. Hopefully his post will help to convince more people that attackers are going to be a real threat to their challenge question authentication systems, whether used for password recovery or secondary authentication.
Since attackers will often follow the path of least resistance in penetrating a host, it is incredibly important to make sure that password recovery functionality is designed to resist attacks.
I described one of the attacks, determining the answers to a user’s challenge questions, in the white paper I mentioned in a past blog entry. Hopefully his post will help to convince more people that attackers are going to be a real threat to their challenge question authentication systems, whether used for password recovery or secondary authentication.
Friday, July 20, 2007
When is a password not a password?
I recently found myself making the statement that sometimes a password isn’t a password. Maybe it is a silly semantics argument better left to high priced lawyers, but I was feeling frustrated by a particular requirement of the Payment Card Industry (PCI) Data Security Standard (DSS). This is the standard with which some organizations that process and store credit cards must comply.
The focus of my frustration was requirement 8.4 of the PCI DSS, which says “Encrypt all passwords during transmission and storage on all system components.” I was asked whether the following scenario violated this requirement.
An application which falls under the scope of PCI required manual approval of new user account registrations. Once the account was approved the system would email the user a temporary password. The user was required to change the password upon their first login to the application. The email containing the temporary password did not include their username or even a link to the actual application.
On the surface this practice appears to violate the stated requirement. It doesn't violate the “at rest” part because the password isn't stored in cleartext on a system under your control. That leaves “transmission”, and I can’t deny that the application is transmitting a password. However, my belief is that the requirement did not apply in this situation.
Without a username, a password has little value. This is like an application transmitting the last 4 digits of a credit card number (which, incidentally, the PCI standard does allow you to store unencrypted). Using this logic, I argued that this scenario shouldn't constitute transmission of a “password” because the incomplete information rendered it unusable for authentication.
Regardless, the fact that this is only a temporary password further reduces risk. An attacker would have to read the email, determine the associated username, and find the login page all before the legitimate user first logged in. That is a pretty small window of opportunity.
If you just want to follow the letter of the requirement, send users a URL that includes a parameter containing their password. When they follow the link, prompt for their username (and preferably another piece of personal info). If the credentials match, log them into the application and prompt for a new password. Technically you didn't send them a password because it wasn't identified as such. I really don’t consider this different from a risk standpoint. Just because the PCI standard language may discourage the first approach I don't believe you can consider the second any better.
Whether you can convince the PCI council or a security examiner of this viewpoint is another matter.
Ultimately, I was rebelling against the rigidity of the PCI DSS requirement, not trying to add confusion about the term “password”. I would actually prefer that the user set up their own password during account registration, but this may not be possible given the design of this particular application. However, I was satisfied that the approach taken would reduce the risk associated with emailing a temporary password to a manageable level.
The focus of my frustration was requirement 8.4 of the PCI DSS, which says “Encrypt all passwords during transmission and storage on all system components.” I was asked whether the following scenario violated this requirement.
An application which falls under the scope of PCI required manual approval of new user account registrations. Once the account was approved the system would email the user a temporary password. The user was required to change the password upon their first login to the application. The email containing the temporary password did not include their username or even a link to the actual application.
On the surface this practice appears to violate the stated requirement. It doesn't violate the “at rest” part because the password isn't stored in cleartext on a system under your control. That leaves “transmission”, and I can’t deny that the application is transmitting a password. However, my belief is that the requirement did not apply in this situation.
Without a username, a password has little value. This is like an application transmitting the last 4 digits of a credit card number (which, incidentally, the PCI standard does allow you to store unencrypted). Using this logic, I argued that this scenario shouldn't constitute transmission of a “password” because the incomplete information rendered it unusable for authentication.
Regardless, the fact that this is only a temporary password further reduces risk. An attacker would have to read the email, determine the associated username, and find the login page all before the legitimate user first logged in. That is a pretty small window of opportunity.
If you just want to follow the letter of the requirement, send users a URL that includes a parameter containing their password. When they follow the link, prompt for their username (and preferably another piece of personal info). If the credentials match, log them into the application and prompt for a new password. Technically you didn't send them a password because it wasn't identified as such. I really don’t consider this different from a risk standpoint. Just because the PCI standard language may discourage the first approach I don't believe you can consider the second any better.
Whether you can convince the PCI council or a security examiner of this viewpoint is another matter.
Ultimately, I was rebelling against the rigidity of the PCI DSS requirement, not trying to add confusion about the term “password”. I would actually prefer that the user set up their own password during account registration, but this may not be possible given the design of this particular application. However, I was satisfied that the approach taken would reduce the risk associated with emailing a temporary password to a manageable level.
Tips for avoiding bad authentication challenge questions
I’m excited to share the news about a brand new white paper that I wrote for Security PS. The paper is called Tips for Avoiding Bad Authentication Challenge Questions. To be clear, a challenge question is a question used for authentication that asks you for personal information. Examples are “what is your mother’s maiden name” and “what is your pet’s name”. Financial institutions, including many of our clients, have implemented challenge questions in an effort to improve online authentication for higher risk applications.
My goal with this paper was to review how well these questions actually succeed in effectively authenticating users. I subjected challenge questions to a framework for evaluating authenticators that I developed several years ago. I also gathered a variety of examples from clients and public sources so I could illustrate the strengths and weaknesses of different questions. I think you may be surprised by our conclusions.
If your organization has implemented challenge question authentication or are simply interested in how much security they provide, I encourage you to give it a read. I’d love to get your feedback about the paper. Please enter your comments on this blog entry or send me an email directly. You’ll find my contact information at the end of the paper.
Paper link: http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf
My goal with this paper was to review how well these questions actually succeed in effectively authenticating users. I subjected challenge questions to a framework for evaluating authenticators that I developed several years ago. I also gathered a variety of examples from clients and public sources so I could illustrate the strengths and weaknesses of different questions. I think you may be surprised by our conclusions.
If your organization has implemented challenge question authentication or are simply interested in how much security they provide, I encourage you to give it a read. I’d love to get your feedback about the paper. Please enter your comments on this blog entry or send me an email directly. You’ll find my contact information at the end of the paper.
Paper link: http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf
Welcome to the PasswordResearch.com Blog
I have enjoyed sharing password and other authentication related information with you on PasswordResearch.com the last few years. But I found it challenging to fit some news within the existing structure of the site. Organization is great until it starts inhibiting collaboration.
Fortunately, this blog offers a less formal and structured alternative to creating new content on the main site. I am committed to posting here regularly as a supplement to the great PasswordResearch.com statistics, stories, and research. Subscribe or check back regularly here for interesting authentication updates.
Fortunately, this blog offers a less formal and structured alternative to creating new content on the main site. I am committed to posting here regularly as a supplement to the great PasswordResearch.com statistics, stories, and research. Subscribe or check back regularly here for interesting authentication updates.
Subscribe to:
Posts (Atom)
