A Review of Real World Security Questions & Answers

Yesterday I delivered my presentation titled A Review of Real World Security Questions and Answers at PasswordsCon 13.  I have written about security questions (AKA challenge questions) before, but this presentation is based on my analysis of thousands of actual user choices that were included in hacker database dumps from three different organizations this past year.

We don't often have an opportunity to see how people are actually using security questions outside of controlled surveys, so I was thrilled to dig into the data to see what additional insights it offered about their strengths and weaknesses.  Hopefully you will find it to be a useful resource when making decisions about the use of security questions in your own organization.

You can find a copy of my presentation slides with my analysis at www.passwordresearch.com/securityqs.html.  If you would like to talk about these findings you are welcome to contact me through email or on Twitter @PwdRsch.  You can also post your comments or questions on this blog entry.

Passwords Found in the Wild for January 2013

Studying the passwords dumped on the Internet by hackers back in December provided a good opportunity for me to measure the scope of the problem. Following that experience I decided to collect and correlate some new information when analyzing password dumps from January.

Overview of Password Dumps

Last month I found 110 password dumps which met my criteria* for analysis, down from 154 in December. A few of the dumps contained data from multiple sites. There were 90 specific organizations or domains named as the source of the passwords. The remaining dumps didn't identify the source of their data, or were gathered from multiple personal computers instead of from a centralized web site.

From this collection, 40 dumps consisted primarily of plaintext passwords, exposing roughly 61,000 passwords (36% of the monthly total). Another 64 dumps primarily contained hashed passwords, adding approximately 101,000 passwords (59% of the total). Six more dumps had a mixture of plaintext and hashed passwords, accounting for 9,000 passwords (5% of the total).

Compared to 450,000 passwords dumped in December, this month's total of 170,000 passwords was significantly lower. A contributing factor to this was the smaller number of dumps, but maybe more importantly there also tended to be fewer large password dumps. This month only had two dumps containing more than 10,000 passwords, while last month had 17.

I wasn't really surprised to see this result. The number of sites that are compromised and the number of passwords they disclose will always change based on what is getting hacked that month and how large the vulnerable sites happen to be.

Over time a baseline average of 150,000 - 300,000 passwords dumped each month might emerge, but this number would skyrocket every time a large site was affected by a security breach. In June of 2012 we watched LinkedIn lose 6.5 million passwords and eHarmony lose around 1.5 million. The next month 450,000 passwords were leaked from Yahoo Voices. Just this past Friday Twitter announced a forced password change for around 250,000 users whose password hashes may have been accessed by hackers (although these have yet to be publicly dumped).

There were 40 different hackers or hacker groups claiming credit for January's password dumps, and more hackers that chose to dump their data anonymously. So even the retirement, capture, or poor motivation of any particular hacker seems unlikely to have a large impact in the flow of monthly password dumps.

The biggest deterrent to future password dumps is more likely to be improvements in the security of the code and development frameworks used by the vulnerable sites, or a widespread adoption of specific security countermeasures (e.g. web application firewalls or intrusion prevention systems). This brings us to the subject of what types of sites I found to be vulnerable today.

Sites Vulnerable to Password Dumps

In January I decided to visit all the sites named in the password dumps and gather information on the software coding language they used, the category of the function they served, and the country in which they were hosted. I hoped this might provide some further insight on whether these attacks were targeted in any way or simply opportunistic.

SQL injection attacks appear to be the primary supplier of the database dumps containing passwords. Many of the dumps include actual output from the tools (like Havij) that hackers can use to automate the extraction of database contents. This seemed pretty intuitive since SQL injection is a common web application vulnerability and one that may not require hackers to gain any other illicit access on the targeted site.

What did surprise me was that the majority of the 87 named sites targeted with password dumps were developed using the PHP programming language, as shown in the following chart.

 

Netcraft's Web Server Survey for this same month shows that 39% of all web sites (around 244 million) are running PHP. While that is a large portion of the Internet, the market share by itself doesn't seem to justify PHP sites making up 91% of the total. After all, sites using ASP and JSP can be just as vulnerable to SQL injection attacks as PHP. If I didn't know that SQL injection was the primary attack method I would suspect that hackers were exploiting some PHP-specific vulnerabilities.

A more likely explanation is that the popularity of the language has led to the rapid deployment of PHP sites and PHP-based content management systems (CMS) by people who lack an education in web application security. Even though the risk of SQL injection in PHP should be fairly well understood, some organizations still end up deploying code that doesn't implement proper security controls.

Interestingly enough, I found that one of the organizations suffering a January password dump had actually showed up previously in a hacker's report of sites vulnerable to SQL injection posted on Pastebin.com over 6 months ago. So either they never learned they were vulnerable in the subsequent months or were unable to completely fix the problem before it was exploited to dump their entire user database.

Another possible explanation is that some of these sites might be unintentionally allowing attackers to connect directly to the site database and download records that way. This should be prevented by host firewall segmentation and proper database authentication, but sites may have been deployed without these precautions. I see evidence within the posted password dump files that this is happening, but I believe it is secondary to the more popular SQL injection attacks.

While all software developers and web admins should learn about SQL Injection prevention and other secure site management practices, it appears that the PHP community needs the most help catching up.

Categories of Targeted Sites

When I visited these vulnerable sites I also assigned them a category based on the site's purpose. Most of these category labels should be self explanatory, but I'll provide a description for a few of them.

Education sites were mainly universities, although there was one primary school. Business sites were a corporate web presence that mainly published data and didn't offer online services to customers. Entertainment sites could be a discussion forum or a site sharing information on a specific topic (e.g. movies or sports).

An Online Store was a business site where customers could make purchases. This type of site would be particularly valuable to attackers looking to capture stored billing information or to order merchandise and charge it to customers. As mentioned last month, sites like this often don't make it into public password dumps because attackers can sell the account data in the underground marketplace.

Info Services are the sites that sell information as a single-use or subscription service. These sites could also be valuable to attackers, depending on what type of data they make available to customers. Finance sites are banks, credit unions, or other related institutions, but in this month's case it was a single investment firm.

The chart below shows how many sites matched each category in the January password dumps.

I didn't really have many preconceived ideas about the categories of sites I expected to see targeted. Government, Business, Medical, Education, News, and Political certainly make sense if the attacker hopes to gain media attention with their data dump. 

The Online Stores, Info Services, and Financial sites make sense if the attacker hoped to make a financial gain from the attack. Although going after these sites could also certainly just be for bragging rights.

There is probably some ratio of opportunistic and targeted attacks in this mix, but it is difficult to detect unless the hackers specifically outline their motivations in the dump descriptions.

Countries Hosting the Targeted Sites

I was able to identify the country of origin for 96 of the January password dumps. There were 35 different countries represented in that total. The top 10 countries that experienced the most password dumps are shown in the chart below.

Seven other countries tied the Philippines with two vulnerable sites each. South Africa was given a bit more attention in January than normal due to one hacker group specifically targeting organizations in that country as part of a political statement.

Another observation was that half of the vulnerable sites in India were Education category sites. They were the only country that had such a large percentage of their sites in the same category. This might indicate greater web site security problems at universities in India, or it could just be chance.

Impacts on Users of Targeted Sites

At least some users of the hacked sites are likely to experience problems as a result of these password dumps. If passwords were stored in a plaintext format then any account is vulnerable to misuse by unauthorized individuals. Even if hashed, password cracking software can produce the plaintext passwords fairly quickly for all but the stronger passwords. Whether hackers care to use these stolen credentials will depend partially on what the account can be used for and partially on how motivated they are to annoy users.

Some web sites use an email address for the username, or record the email address during the account registration process. Email addresses of users were found in 96 (87%) of the analyzed password dumps in January.

The use of email addresses isn't necessarily a problem by itself, but the reality of user password practices can result in email address leaks endangering their identities on other Internet sites. If one organization leaks email addresses and passwords this allows attackers to try those credentials elsewhere. In fact, hackers have developed software tools that automate the process of trying discovered email and password combinations against a list of popular web sites.

Password reuse makes this a real problem, although mainly for the users and not necessarily for the site that was vulnerable to the password dump in the first place. Even if a user chose a stronger password to reuse, it only takes one site storing that password in plaintext to potentially expose all of their accounts.

My suggestion to users is that passwords should never be reused across any sites where you would care if your account gets hacked. Always choose a strong and unique password for each site and then store it in a password manager if you are concerned about forgetting it.

Web sites often can't do much to prevent password reuse other than enforcing good password selection controls that might eliminate the worst of the reused passwords. However, they can make sure that they use adequate password hashing and salting techniques that make the task of cracking user passwords much more difficult for hackers. Sites should also notify users when a database breach is detected and warn them to change their password anywhere else it was used, in addition to forcing a change on the hacked site itself.

Conclusion

I wasn't able to complete my analysis of all the information provided by the password dumps in January, but I'll continue to work on it and will post new results here on the blog. In the meantime, if you have any questions or comments leave them below, or contact me on Twitter @PwdRsch.

* Study Methodology

I monitored Twitter and other sites for notices that a data dump had been publicly posted. Some data dumps contained user or customer information but not passwords. Others contained only the administrator password or the passwords of a very limited number of users. I ignored these and focused only on sources that contained passwords (hashed or plaintext) of at least a dozen or more users.

I also attempted to eliminate duplicate dumps, a practice where one hacker copies a full or partial dump from someone else and reposts it as their own. Sometimes these dumps are from the same month and sometimes they are from previous months.

In a few cases the dump poster noted that they had included only a subset of the available user passwords. While I didn't count the unposted passwords, we should assume that the attacker had access to the complete user database, which would increase the total number of passwords exposed.

When reviewing these figures keep in mind that they account only for the publicly posted data which I was able to discover. Hackers certainly compromised the passwords of other sites and kept this activity secret, or shared the data over more private channels.

Passwords Found in the Wild for December 2012

In the late 1990's when I started analyzing passwords it was much harder to find samples to review.  My password collection routine consisted mainly of begging colleagues to share data or volunteering to perform the cracking for their security assessments.  Occasionally I would get lucky and find a publicly readable password file on the Internet.  Then I could dedicate a computer for several months to cracking each password database because it would certainly take at least that long before another sample showed up.

Today I find that I am actually overwhelmed with the opportunities to gather passwords.  The raw number of Internet sites that register users and collect their passwords is huge.  Correspondingly, the number of these sites that are susceptible to SQL injection or other vulnerabilities that allow attackers to extract their user databases has also grown.  Hackers are regularly exploiting these flaws and publishing password dumps to embarrass companies, to attract attention to their causes, or to simply stroke their egos.

I decided to monitor password dumps in December 2012 to get a better idea of how widespread this practice has become.  I monitored several sources (though mainly the Pastebin.com web site) for announcements of dumps and analyzed the data posted.

Study Methodology

Snippet of Password Dump Tracking Data

Some data dumps contained user or customer information but not passwords. Others contained only the administrator password or the passwords of a very limited number of users.  I ignored these and focused only on sources that contained passwords (hashed or plaintext) of at least a dozen or more users.  I also attempted to eliminate duplicate dumps, a practice where one hacker copies a full or partial dump from someone else and reposts it as their own.

In some cases the dump poster also noted that they included only a subset of the available user passwords.  However, we should assume that the attacker had access to the complete user database, which would increase the actual number of passwords exposed.

When reviewing these figures keep in mind that they account only for the publicly posted data of which I was made aware.  Hackers certainly compromised the passwords of other sites and kept this activity secret, or shared the data over more private channels.  Brian Krebs covered the underground marketplace for the more valuable passwords in his recent blog post.

Password Dump Findings

In December I found 154 dumps which met my criteria for analysis.  A few of the dumps contained data from multiple sites.  They named more than 125 different organizations and domains as the source of the leaks.  Passwords belonged to users at businesses, governments, schools, industry groups, and discussion forums.  Some dumps didn't identify the source of their data, or were gathered from multiple personal computers instead of from a centralized web site.

From this collection, 66 dumps consisted primarily of plaintext passwords, exposing roughly 221,000 passwords.   Another 82 dumps primarily contained hashed passwords, adding approximately 222,000 passwords to the count. So while the number of hashed password dumps was greater than the plaintext dumps, the number of passwords exposed was nearly equal.  Six more dumps had a mixture of plaintext and hashed passwords, but only accounted for 6,000 passwords.

Altogether, I found that almost 450,000 passwords were publicly exposed during the month. There were 103 dumps containing less than 1,000 passwords, and 17 dumps containing more than 10,000 passwords.  About 184,000 passwords (41% of the total) came from several dumps simultaneously released as part of Team GhostShell's Project WhiteFox on December 10th.

Finding that half of the exposed passwords lack the security provided by basic password hashing is disappointing.  While some of the affected sites likely have low security requirements, storing only password hashes is a pretty standard security practice that should be followed by almost every site.

Without password hashing both the poorly and well constructed passwords are exposed during leaks like these.  A user may think their password is secure only to find that their account has been compromised due to insecure password storage that was beyond their control.

Even hashed passwords can only offer resistance against attacks once they have been stolen from an organization.  Password crackers have become faster and more proficient at trying common words, names, phrases, and other combinations of guesses that can disclose a password after it has been hashed.

Conclusion

My feelings are mixed when it comes to the results of this study.  On one hand I'm frustrated with the security vulnerabilities that continue to plague many Internet sites, and on the other hand I'm eager to see what wisdom is provided by examining these leaked passwords.  The wide variety of passwords from these different sources allows researchers like me to pick and choose the password samples that seem most interesting or likely to produce the information we seek.

So these days instead of begging for passwords I'm finding myself begging for help to sort through all the password data that is available to me.

Finding the humor in changing your password

On the lighter side of things, here's a reminder of what users may experience when it comes to changing their passwords:
http://www.washingtonpost.com/wp-dyn/content/article/2009/07/12/AR2009071202012.html?hpid=sec-metro

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.