Anonymous Damage Control Anybody?

Published: 2011-02-14. Last Updated: 2011-02-14 16:39:00 UTC
by Richard Porter (Version: 3)
10 comment(s)

One of our readers sent in  link to a list of passwords stolen from rootkit.com (original link removed per reader request).

Dumps of large password databases, many of which are leaked from buggy web applications, have become a quite common. We have said it before, and this is yet another reminder: DO NOT USE THE SAME PASSWORD ON DIFFERENT SITES.

rootkit.com is down right now, and I am not aware of any notification done by rootkit.com to affected users. Many of the leaked passwords have been shown to work for respective twitter and google accounts, showing that the advice is often ignored. 2 Factor Auth cannot come fast enough? 

We can't really make up our mind on whether or not to publish the list of leaked passwords. On the one hand, the users that are affected need to know about them, on the other hand, the data may be considered "contraband". We may publish a list of md5 hashes only later which would probably present a compromise (people can still look up if their password is leaked).

Even if you didn't have an account with rootkit.com, please consider not using passwords that are on the list. These passwords will likely soon be added to everybody's favorite password cracking tools.

Another indication of heavy password reuse, here a list of the top 10:

1023 123456
384 password
329 rootkit
190 111111
181 12345678
174 qwerty
170 123456789
 99 123123
 91 qwertyui
 89 12345
 87 letmein
 76 1234
 72 abc123
 69 dvcfghyt
 67 000000
 55 r00tk1t     <- one advice some people follow is to use a password derived from the site name. Not always a good idea. Maybe these people use 'g00gl3' to log into google?
 51 ìîñêâà
 49 1234567
 46 1234567890
 45 123

 

Richard Porter

--- ISC Handler on Duty

(updated by Johannes Ullrich)

10 comment(s)

Comments

Speaking of damage control, has HBGary/HBGary Federal released any official response to this other than the placeholder they had on their site for a few days? I'm not sure it would be okay for me to download the leaked email archive, but since we have Responder Field Edition I'd like to know if any of my company's information was exposed.

I hope the company learns some lasting lessons but I'm not sure if we'll see it. Mr. Barr's updated LinkedIn profile is just astounding and HBGary's site is slowly being pieced back together with no further mention of what happened to them.

This really has been a fascinating saga to watch unfold.
My SourceForge password was recently reset/disabled, but I can't remember what password I used. Therefore I don't know if I used it elsewhere, and may even end up resetting my account password to its original value! In that situation it would have actually been preferable for my password hash to be available to me.

This give me an idea. When large databases of unsalted password hashes are publicly leaked, they could be used to compile a blacklist of common or compromised passwords to avoid. Websites that enforce good password choice by their users could refuse to allow passwords if their unsalted hash matches one in the blacklist.

In some situations it may be possible to pro-actively disable accounts whose passwords have found their way onto the 'compromised' list. Websites that store plaintext or unsalted hashes of their users' passwords can do this easily. Websites that wisely use a salted hash can still look up passwords against the blacklist at login.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." — Albert Einstein

> https://www.microsoft.com/security/online-privacy/password-checker.aspx
.
I like Steve's idea for a blacklisting of published passwords - perhaps another way to populate it would be with a fake SSH listener capturing those attempts.
pam_cracklib will run proposed passwords past dictionaires (cracklib_dicts or cracklib_words). I thought it also used the John the Ripper wordlist but maybe not. You can get the JtR wordlists and add them to the cracklib dictionaries though if you want to block common passwords. Maybe someone else knows...
I would suggest publishing the passwords. Using some type of 'password blacklist' feed. Then we could use a script to check EACH REGISTERED user of our unrelated website, to see if the password they are using is in the feed.

If ever we detect any current user's password matches one in the feed, then their account gets disabled, GUI will just behave as if password invalid/user does not exist (to avoid providing hackers information), and they have to reset their password VIA 'forgotten password' process.

We should devise a standardized protocol for this, and utilize the "published password blacklist" method for compromises of all type.

Then all secure websites; banks, online brokers, weblogs, forums, blogs, webmail providers, etc,
can subscribe to the feed, and use the blacklist as a way to disable accounts associated with compromised passwords, to help quarantine the password against being used for future damage/impersonation to the user.








On several sites, I use a One-Time-Password. A long random value (rand uuencoded). I don't bother remembering it. I use it once to log in. At the next login, I simply go through the Change-Password procedure and set a new long random. That keeps that password strong and unique, and I don't even have to remember it and it's not written down. Appears simple and effective to me.
Lastpass with a Yubikey - Cheap and very effective if you randomly generate your passwords.
So...Now users cannot use a password which they don't know about (blacklisted), they then start using different "approved" passwords, which will then also become blacklisted which then forces them to use other unknown...... Sounds like a vicious circle to me.
ìîñêâà is odd. Turns out to translate to "Moscow" I guess not so odd then.

Diary Archives