It has a publicly disclosed list of accounts exposed from the attack on HBGary. As always follow the link at your own risk but it has been checked. It is regarding the site rootkit dot com. Their site seems to be unreachable at the moment but the article from Dazzlepod indicates that some passwords match Gmail and Twitter. 2 Factor Auth cannot come fast enough?

If you would like an offline copy email me at richard at isc dot sans dot edu

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.

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.

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.

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.