Unless you've been hauled up in a bunker, eating MREs and watching Doomsday Preppers marathons, you've likely heard of the recent compromise of over 1.5 million eHarmony password hashes. After a little work tracking down the hashes, we launched several attacks against them, hoping to recover at least 75% of the plaintext passwords. Roughly 72 hours were spent cracking the hashes over the course of a week. This netted 1,215,846 of 1,513,935 (80%) plaintext passwords.
Password cracking was performed on a custom built system using off-the-shelf parts totaling less than $1,500 utilizing three NVIDIA 460GTX graphics cards (GPUs) as the primary medium for the password cracking process. The majority of cracking was done using oclHashcat, part of the Hashcat password cracking suite. Secondary cracking was done using John the Ripper.
The dump shows that the passwords were stored in a non-salted MD5 format. While this is far better than storing plaintext passwords, it's also far from best practice. MD5 has been long
considered in adequate for password storage.
After cracking was completed, password analysis began. The first thing we noticed was that no lowercase characters we present in any of the plaintext passwords. This means that not only was eHarmony storing passwords in the weak MD5 format, they were also case-insensitive. All lowercase alphabetical characters were converted to uppercase before hashing. This drastically reduces the time it takes to crack, as there are far less possibilities. Using a full 95 character keyboard, bruteforcing an 8 character password gives us 6.6342x1015 possbilities. For eHarmony, this is reduced to 5.13798374 × 1014, due to the loss of the lowercase characters. Next we noticed, that no single password was found more than three times. This brings into question the integrity of the original dump and the possibility of modification by the dumper.
Since no password was seen more than three times, we can't really generate a most commonly used password. What we can do is look for the most common patterns or base words. Below are some of the interesting things we found.
The most popular length of password was seven characters. Followed closely by six characters and eight characters. Expectedly, the percentages drop drastically as you go higher in length.
Length of Passwords:
5 = 46628 (4%)
6 = 253347 (21%)
7 = 279971 (23%)
8 = 230315 (19%)
9 = 169252 (14%)
10 = 145894 (12%)
11 = 47911 (4%)
12 = 25490 (2%)
13 = 10964 (1%)
14 = 5779 (.5%)
15 = 378 (0%)
One interesting statistic here is that 99.5% of passwords do not contain a special character. The majority of passwords contained letters and numbers, which is an improvement compared to other dumps we've seen.
Letters and Digits - 696688 (57%)
Letters Only - 499531 (41%)
Digits Only - 18381 (1.5%)
Letters Digits and Special Chars - 629 (0%)
Letters and Special Chars - 548 (0%)
Special Chars and Digits - 45 (0%)
We found it interesting that we saw the Top 100 dogs names more often than the top 100 baby girl names. Also, that National Football League teams were seen less than National Hockey League teams. Does this say anything about eHarmony demographics?
Passwords containing the following:
Top 100 baby Boy Names of 2011 - 47,478 (4%)
Top 100 baby Girl Names of 2011 - 25,670 (2%)
Top 100 Dog Names of 2011 - 41,700 (3.5%)
Months of the Year (Abbr.) - 26,358 (2%)
Days of the week (Abbr.) - 12,492 (1%)
Years 2000 through 2012 - 13,143 (1%)
Top 25 Worst Passwords of 2011 - 4,894 (.5%)
National Football League Team Names - 1,367 (0%)
Major League Baseball Team Names - 8,725 (1%)
National Hockey League Team Names - 2,491 (.5%)
100 Most Populated US cities - 2,392 (0%)
100 Most Populated World Cities - 2,197 (0%)
Curse Words - 10,144 (1%)
Below are numbers on specially chosen words and are not the "top" base words. That being said, we saw some very interesting things here too. Generally known as the most common word in passwords, "PASSWORD" was only found in 240 passwords. "LOVE" was found most often of all the words we checked, which is not surprising due to the fact that these are password from eHarmony users. Also interesting to us, was that we found "DOG" more than twice as often as we found "GOD". Would that hold true if this were a Christianmingle.com dump?
Interesting Base Words:
LOVE - 10,690
DOG - 5,481
1234 - 3,526
LUV - 3,991
SEX - 2,616
GOD - 2,445
ANGEL - 1,703
LOVER - 1,325
123456 - 830
JESUS - 748
DATE - 683
HARMONY - 656
EHARMONY - 383
FOREVER - 337
PASSWORD - 240
Lastly, we looked to see how many digits were used in passwords, regardless of their position. We found it odd that more passwords contained four digits than any other. In close second place was two digits, followed by one digit.
Number of passwords with the following:
1 digit - 148296 (12%)
2 digits - 179901 (14.5%)
3 digits - 99972 (8%)
4 digits - 204685 (16%)
5 digits - 26167 (2%)
6 digits - 28737 (2%)
7 digits - 3647 (.5%)
8 digits - 4567 (.5%)
9 digits - 6733 (.5%)
10 digits - 12415 (1%)
Over 10 digits - 638 (0%)
We did however, find a surprisingly high number of passwords following the patterns of either (d=digit): ddEHARMdd, ddddEHARM, or EHARMdddd. We tested to see if this pattern was used by eHarmony as password reset defaults, but this does not appear to be the case. There is still a possibility that eHarmony may be resetting passwords as part of a lockout functionality, but we have no way of testing this. What we did discover during these tests was yet another eHarmony password policy failure. During our tests, we reset the password for an eHarmony account several times. Each time, we found that the passwords were reset to a five-character password using only letters and digits. While the password appears to be using uppercase and lowercase letters, we know that the hashes use only uppercase. Bruteforcing five characters, under these circumstances, can be done in less than 10 seconds while utilizing at least one GPU.
In conclusion, we found numerous irregularities in this password dump. While we saw many patterns we expected, we also saw many more that surprised us. The eHarmony dump is just further proof that organizations need to not only store passwords in stronger, salted formats than was previously acceptable, but also need to enforce stronger case-sensitive password policies. Users, as a whole, still do not understand the need for strong passwords, and will continue to set passwords that meet only the minimum requirements.