Embassy password hacker reveals his technique

A Swedish hacker calling himself "DEranged" attracted media attention over the past couple weeks by posting a list of 100 government email usernames and passwords. His list included email accounts used by embassy officials from India, Russia, Iran, Hong Kong, and others. A few journalists verified that these credentials could indeed be used to access private email.

At the time of his original disclosure DEranged (his real name is Dan Egerstad) withheld details on how he came into possession of the passwords, instead writing that "there is no exploit to publish, no vendor to contact". Today he posted an entry on his blog describing how he used newer software to exploit an older problem.

Egerstad established several computers as nodes in the Tor network. As a part of this network, these computers would act as intermediary routers in the delivery of Internet traffic. By routing this traffic Egerstad also gained the capacity to capture and analyze any unencrypted packets sent through his systems. He then used this access to collect thousands of usernames and passwords transmitted to email servers in the clear.

I will not praise Egerstad due to his poor ethics in disclosing passwords in the manner that he did, but ultimately he is right in pointing out the serious shortcomings of protocols that still transmit unencrypted passwords.

There have been secure alternatives to POP3, such as POP3 over SSL, for some time. However, many companies and service providers fail to offer them, let alone make them the default setting. Organizations can only justify this continued practice because of the difficulty in detecting password capturing attacks. IT personnel can avoid responsibility by dismissing password thefts as a user problem resulting from phishing attacks or software trojans. This is an unacceptable response.

With the growing number of mobile users and wireless networks, the opportunities for password capture attacks will increase. If you are using POP3, Telnet, HTTP, FTP, or any other unencrypted protocol for transmitting passwords, look into alternatives today. People with more dangerous agendas than Egerstad will be watching to see if you do.

My advice to users on storing written passwords

Giving blanket advice on creating, using, and securing passwords is always a worry of mine. Life has taught me that advice is sometimes interpreted or adapted in such a way that it is, at best, rendered less useful or, at worse, made downright dangerous. This is more likely to happen as the subject knowledge gap expands between the advice giver and advice receiver.

So, it was with some hesitancy that I shared my advice on writing down passwords with a reporter a few weeks ago. To his credit, the quote he included in his article was intact and hadn't fallen victim to creative rephrasing. However, I knew that some of his readers would be absorbing my advice from a non-technical perspective and I worried about their interpretation. I would like to use this blog post to explain this advice beyond the few lines available to me in his column.

Let's start with the quote: "This is controversial advice in some circles, but I advise people to write down their passwords. If it is a password you are going to use every day, keep it on a slip of paper in your wallet. Don't write anything else down on the paper that could identify where you are using the password or your username."

I believe this is sound advice, although I want to emphasize the importance of writing passwords on a blank piece of paper with no other identifying information. Once during an introduction I was handed a business card which included a string of characters written on the back. The string struck me as particularly password-like. I can only assume the person had written it down and forgotten that this particular card wasn't meant to be given away.

What didn't make it into the article was my subsequent comment that a password in your wallet should serve only as a temporary memory aid. Within a week or two of use, a password should be committed to long term memory, reducing the likelihood of it being forgotten. This is when the wallet copy should be destroyed and the password archived in a more secure location.

I will avoid getting into specific password storage software in this post. There are good open source and commercial alternatives available. There are also Trojans horses posing as password managers that would love nothing more than to capture your secrets and relay them back across the Internet to their criminal masters. Take time to check out the reputation of any password software before installing it.

I recommend writing down passwords to improve their usability and affordability by reducing the number of times a forgotten password results in an IT support call. However, the biggest benefit is the chance to encourage better password selection.

One of the major factors that impede good password choices is a user's fear that they won't remember a well constructed password. Nobody wants to be stuck staring at a password prompt and cursing their decision to finally come up with a good password. Even worse is the feeling of stupidity they experience when they have to call someone and admit to forgetting their password.

When a person has a reliable written record of a password it takes away a lot of this fear by letting them serve as their own first line of support.

If you are willing to publicly support this practice in your organization, I encourage you to associate this freedom with a requirement for stronger password security. Educate users on how to construct hard-to-guess passwords. Implement technical controls that force new passwords to meet minimum requirements. Make sure that passwords are changed on a regular basis. Finally, emphasize that these written or stored passwords must be very well protected.

Does this practice seem practical for the people you work with, or am I only encouraging a new generation of people to sticky-note passwords by their computers?

How password policy requirements impact possible password choices

A recent discussion on a SecurityFocus.com mailing list raised a concern about password policies that I hadn't previously given much thought to. The post author commented that he wanted to enforce a policy that required passwords to have lowercase, uppercase, number, and symbol characters. By this he meant every password must have at least one character from each of these characters sets. One reader responded that by requiring the use of all four character sets he would reduce the total number of possible passwords, causing a negative impact on password security.

Instinctively I knew the claim about reducing password possibilities was right, but I dismissed the security impacts as insignificant. After all, with 95 standard characters within that character pool to choose from, the total number of password possibilities is massive. Unfortunately "massive" doesn't really provide much perspective on how negative the impact could be. To quantify the impact I decided to calculate the actual effects on password possibilities.

I started with a set password length of 7 characters, giving us 95^7 (or 6.98 x 10^13) total possible passwords that users can create without any specific character requirements. This gave me the unrestricted total. I then needed to figure out how many of these passwords would meet the restricted requirements of having lowercase, uppercase, number, and symbol characters within them.

Following some different approaches at number crunching I found that there may not be an easy formula for calculating the quantity of restricted password possibilities. The easiest approach seemed to be counting the number of passwords not meeting the criteria and then subtracting them from the unrestricted total. While not math intensive, this approach does take some fancy spreadsheet formulas. If you have a burning desire to see the numbers yourself, you can check out the resulting Excel spreadsheet I created.

When I compared the restricted and unrestricted password possibilities I was in for a bit of a shock. It turns out that for 7 character passwords the restricted requirements would eliminate about 63% (or 4.4 x 10^13) of the total password possibilities! So much for an insignificant impact.

I applied this technique for several different lengths of passwords to see how the length changed the results. The longer the password became, the more the percentage of eliminated passwords shrunk. The restriction eliminated 54% of 8 character passwords. With 10 and 12 character passwords only 41% and 31%, respectively, were eliminated. These losses still amount to sizeable chunks.

This led me to evaluate the impacts of the normal Microsoft Windows password complexity requirements. Enabling this security policy forces users to choose a password made up from only three of the four character types. For a 7 character password this still amounted to a 9% reduction in possible passwords.

So, numerically we've established the impacts of different password policies, but how should these numbers affect our decisions to enforce such policies?

If we consider password cracking our biggest threat then we must consider how knowledge of the password policy might save an attacker time avoiding unacceptable passwords. Fortunately, real-time brute force cracking isn't terribly compatible with this approach. In the time it takes for cracking software to evaluate whether a password guess meets the policy it could have just tried the password. So no effort is eliminated in this scenario.

However, a rainbows tables cracking approach can benefit from policy knowledge. An attacker could create a rainbow table consisting of only the passwords that meet a particular password policy. As a matter of fact, attackers do that today by generating and sharing rainbow tables consisting of the most common password character sets.

While bad guys could technically implement this attack for complex passwords, it would be one of last resorts. So few environments require passwords containing the four different character sets that attackers have little reason to generate the rainbow tables. It is still much more rewarding for them to focus on cracking passwords like "muffins" instead of "b@n4Na5".

More importantly, creating just the rainbow tables needed for our restricted password pool of 7 character passwords would require hundreds of terabytes of disk space. Yes, I did the math. Few attackers have this level of resources available to them.

We have always made sacrifices like this when instituting password policies. By establishing a minimum password length we, by definition, eliminate all possible passwords of a shorter length. Nonetheless, we know we are making a general improvement in overall password security by removing the shorter, and thus easier to crack, passwords.

When it comes to password complexity we have to consider the attack significance along with the mathematical significance. In reality, there are situations where enforcing specific password restrictions is a very bad idea. However, this is the exception rather than the rule.

I don't believe that enforcing either normal Windows password complexity policy or the even more restrictive 4 character set composition requirement should worry you when paired with a minimum password length of 7 characters. The loss of possible passwords in these cases are greatly outweighed by the benefits of eliminating a large number of poor password choices. From my perspective, those changes have a positive impact on security.

We know about password attacks in Kansas

I was making a dent in a sink full of dishes tonight and half listening to the TV when a show caught my interest. Dateline NBC was airing a segment on the disappearance of John Elwin during a business trip. Apparently his girlfriend, Kirsten Flood, wasn't initially having luck interesting authorities in a search for clues about the whereabouts of Mr. Elwin. Frustrated, she engaged a friend, Denise Tripoli, with "experience in Internet security" to help.

The following excerpt comes from the show's transcript:

   If only she could hack into Elwin's e-mail account, they might discover where he was.

   The two women wracked their brains trying to guess at a pass code that would give them access.

   FLOOD: [We tried] his birthday, his social security number. And I just kept going down the list until I hit it.

   FLOOD: And lo and behold, we got into it.

   BOB MORRISON: What did you find there?

   TRIPOLI: We broke into his account at eleven o'clock at night, and I was up till three in the morning, looking through every e-mail. And I was very disturbed by what I saw.

I certainly won't pretend that I would avoid this temptation if one of my friends or family members went missing and I had exhausted other options. Nonetheless, I was a little disturbed by the casual explanation of how these women broke the law to gain access to Mr. Elwin's email account. In my opinion, reporting this part of the story in this manner trivializes the ethical and legal implications of getting into another person's email account.

You would expect that a news organization so eager to expose the secret underworld of hackers would act more responsibly.

Automating analysis of authentication system weaknesses

Most knowledge-based authenticators run the risk of poor uniqueness when they rely on users to generate or select the secret information. The human mind tends to seek order in the knowledge we acquire and store. This means that you, I, and a few billion others generate similar secrets for authentication.

Seeing as how I make a living off applying my knowledge I don't complain about this natural phenomenon. However, I do occasionally wish that more authentication system designers took it into consideration. While we can't expect them to overcome this reality, they do need to anticipate it and avoid design or implementation decisions that magnify problems.

For example, PassPoints is a knowledge-based graphical password system developed a couple of years ago. This system presents users with a picture and authenticates them by analyzing where they click within the image. Users choose and click on their own series of points during the authentication enrollment process. During subsequent authentications, only the legitimate user should know where to click within an image.

Of course, the security of the system relies on the premise that there aren't a limited number of predictable click points within the image. Good old human brains will sometimes look at the same picture and click on the same points. Our eyes may all be drawn to the fire hydrant, building corner, or stunning brunette. With graphical passwords this appears to be dependent on what is depicted in a particular image. The more predictable the click points are within a picture, the less useful that picture is for uniquely authenticating users.

So I was pleased to see a recent paper where the authors not only recognize this challenge, but also attempt to automatically evaluate an image for predictable points. Modeling User Choice in the PassPoints Graphical Password Scheme is an update from several of the original PassPoints researchers explaining how new software could sometimes accurately predict (70% - 80% in their test case) clickable points within an image. In turn, this software could be used to eliminate images that have too few likely-to-be-clicked points.

I hope that this trend of investigating and developing quality controls for authentication systems continues.

Banks fail to meet FFIEC multi-factor authentication requirements

According to a recent study, only 4% of financial institutions are actually meeting the FFIEC requirements for multi-factor authentication. Many of the others are relying on challenge questions or other risk-based authentication approaches that ultimately only provide single-factor security.

I’ve shared more on my analysis of this problem and its implications in this Security PS blog entry.

Nevada governor's email password is only a click away

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.

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.

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.

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.

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.

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

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.