What is the name of the law?
The law is called the "Data Breach Notification Act" and it supercedes all similar state laws.

Who does the law apply to?
The law applies to any agency or business entity engaged in interstate commerce that uses, accesses, transmits, stores, disposes of, or collects sensitive personally identifiable information.

What is "sensitive personally identifiable information"?
Sensitive personally identifiable information is defined similarly to many states, and takes the form of one of the following:

• First and Last Name or First Initial and Last Name plus one of the following:

• Social Security Number
  
• Driiver's License Number
• Passport Number
• Alien Registration Number

• First and Last Name or First Initial and Last Name plus one of the following:
• Home address or telephone number
• Mother's maiden name (if so identified)
• Month, day, and year of birth

• First and Last Name or First Initial and Last Name plus biometric data
• First and Last Name or First Initial and Last Name plus account credentials (e.g. username and password) that could be used to obtain monney, goods, or services.
• First and Last Name or First Initial and Last Name plus financial account number, credit card number, or debit card number along with the access code, PIN, or password.

How soon must the notification occur?
The notification must occur without reasonable delay. Reasonable delay includes time to determine the scope of the breach, prevent further disclosures, restore the integrity of the data system, and provide notice to law enforcement (if required).

This time may be delayed if a Federal law enforcement agency determines that such notification would impede a criminal investigation.

What about exceptions?
Notification requirements can be avoided if a risk assessment is performed and concludes that there is no significant risk of harm to the individual whose sensitive personally identifiable information was involved in the breach. However, the results of this risk assessment have to be passed by the Secret Service, who can require that notification be given anyway.

According to the law, "no significant risk of harm" can be presumed if the data was encrypted or otherwise protected by effective industry practices or standards.

Where can I get more information about the law?
The actual law can be found at:
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=111_cong_bills&docid=f:s139is.txt.pdf

As reported elsewhere, approximately 10,000 username-password combinations were posted to Pastebin earlier today. Quite a few analyses of the results have been posted, but the actual list was pulled from Pastebin.

A few things haven't been reported yet:

1. The data looks like it came from a Trojan or through a man-in-the-middle attack, because there are multiple entries for specific user account names. (It looks like someone typed their password wrong a few times before getting it right.)
   
   
2. From a quick glance, it looks like none of the passwords were hashed. As mentioned in this article, you should consider using tool like Password Hasher to pre-hash your password before it is submitted.
   
   
3. Only accounts with usernames that fall between ara... and bla... were included in the list, so if your username was outside of that range, it wasn't on the list. (But read the next item!)
   
   
4. This list contains 10,027 accounts (actually only 9360 unique ones), but statistically, the list only covers between 1.6% and 3.1% of the possible space of usernames (depending on whether Hotmail accounts can start with a digit), so it's safe to assume that between 300,000 and 600,000 accounts were actually compromised, and the attacker only posted this subset.
   

This means that you should do the following right now:

1. Get a good anti-virus/anti-malware program. There are plenty of free ones, including Trendmicro's Housecall, Bitdefender's Online Scanner, annd CA's Threat Scanner.
   
2. Change your passwords, and don't use any of the common passwords.
   

Many web-sites today have implemented "secret questions" that are used when you forget your password or as second factor of authentication. Questions like What is your mother's maiden name? or What is the name of your primary school? are among a small list of very common questions.

The basic reasons why these questions should be avoided include:

• There isn't enough entropy in the answers
• The answers are often publicly discoverable
• The answers are common across different web-sites

Reason #1 - Not Enough Entropy

When you answer a question like, What was the make & model of your first car?, there are only a limited number of answers. Out of 100 random individuals in the US, how many of them do you think would answer, "Toyota Corolla", "Honda Civic", or "Nissan Sentra"? (I have no idea if these are actually the most popular answers, but you get the point.)

A particularly awful question that further illustrates the point is Are you male or female? The attacker gets a 50% chance of guessing correctly.

We can easily estimate the strength of a secret question through the following method:

1. Let X be the total number of unique possible answers to the question.
2. Calculate log(x) in base 2. This determines the number of bits required to encode all possible answers.
3. Divide that answer by 6.2 (approximate number of bits in a standard password character).

That's it. Let's try it with the question, What was the make & model of your first car?

Edmunds provides a list of the 50 most popular make-model combinations. I have no idea how it calculated that, but let's assume it's correct for the demographics of our victim base. We take 50, and calculate log(50) in base 2. We can do that easily by searching Google for log(50)/log(2) and get an answer of 5.64. We divide that number of 6.2 to get 0.90.

That means that asking, What was the make & model of your first car? is as strong as asking the user for a one-character password.

Reason #2 - Answers are Publicly Discoverable

In September 2008, Sarah Palin's Yahoo account was compromised by a "hacker" that was able to reset the account password after providing Sarah Palin's birthdate, which was publicly available on her Wikipedia page.

This demonstrates that answers to security questions are often public knowledge. For example:

• Birthdate: Facebook, MySpace, Wikipedia, birthdatabase.com, and other sites
• Car Make & Model: DMV records, which are public records, can be obtained by anyone
• Mother's Maiden Name: ~25% chance that an uncle or cousin will have the same last name, Facebook, MySpace, Classmates.com
• Name of Primary School: Most people live near where they grew up.

Reason #3 - Answers are Common Across Web-Sites

When multiple web-sites ask the same security question, it reduces the security of all of the sites, because a security compromise against any one of those sites could result in attackers logging in as affected users into the other sites. If PayPal asks me about my mother's maiden name, and so does foobar.com, and an attacker gets into the database at foobar.com, then they'll have my mother's maiden name, and can reset my password at PayPal.

What Can We Do?

It's usually far easier to point out a problem than to fix it, and that's certainly true in this area. I have a few suggestions on how to make the process a bit safer.

For Web Developers:

1. Store Answers in Hashed Form. Never store security answers in clear text, or even encrypted. Instead, the answer provided should be hashed with a public and private salt, just like a password. In order to make things a little easier on the user (e.g. "Saint Agnes" vs. "St. Agnes"), you can remove spaces, convert to a single case, and substitute common abbreviations, so that both answers would be converted to SAINTAGNES before being hashed and stored. The result is that if an attacker were to ever compromise your database, the hashed answers would not be useful in attacking any other web-sites.
2. Ask the User for the Question. Instead of forcing the user to choose a question from a list, ask them to write their own question. If the user attempts to use a common question, force them to use a different one. Store the question encrypted (not hashed, since you'll need to ask them at some point). This doesn't guarantee that the user will choose a strong question, but neither does it restrict them to choose a weak one.
3. Never Limit Password Length. It seems absurd to me how many major web-sites limit password length to 8 characters or less. Never limit the password length that your users give you. (You can be reasonable, and use something like 256 characters if you're worried about a denial of service attack.) I'm including this best practice in this list because the answer to a secret question is a de-facto password and should be treated in the same way.

For Users:

1. Use Password Hasher. Password Hasher is a add-on for Firefox, but a similar add-on could be created for any web-browser. The purpose of Password Hasher is to pre-hash passwords (using a secret key) before they are submitted in a form. The user types "St. Agnes" into the secret answer field, but the web-browser submits "d8b82e7d4b825ee2451f9c5743ab8e41ad0359dba1b4f18f68eeb232b499878a" instead.
2. Don't Answer Questions Truthfully. When a web-site asks you for the name of your primary school, you don't actually have the answer truthfully. Type anything you want - just be sure that if the site asks you that question when you need to reset your password, you type that same thing in. Giving out information such as your mother's maiden name, social security number (even the last four digits) or birthdate should be avoided whenever possible.
3. Remove Your Birthdate from Social Networking Sites. Yes, everyone loves getting a bunch of "Happy Birthday" tweets or posts on their Facebook wall, but your birthdate is pretty sensitive and shouldn't be given out to the world.

More Information:

• Bruce Schneier's Blog: Secret Questions, May 2009
• Technology Review: Are Your "Secret Questions" Too Easily Answered?, May 2009