For the things Reputation.com does you have to ask why they used encrypted rather than hashed passwords. Not that hashed passwords would make me super excited to be lost, but why did Reputation.com need to keep the password around? They don't really interact with accounts, and if they do those should be stored separately from the access to the site. So the message should have been "we lost users bank account passwords" or something along those lines.
Because I know that Reputation.com is practically in the extortion business this password storing rather than hashing issue makes me think even less of them, which is difficult to do.
It's no s/b/...crypt but they don't seem to have been 'kept around'.
o_O
Also, not sure we should take blog comments for the gospel before all the facts are out.
Knowing this. Salted and Hash and Encrypted doesn't make any sense. So either they are BSing because they are stupid. Or because they are dishonest.
From where I stand it doesn't really matter which of the two they are. When it comes to privacy I have no tolerance for Stupid or Dishonest.
As for the statement that they aren't legally required to notify you... That's not true. If any of the people on the list live or access their account from North Carolina, or any of the 14 other states that use NC's breach terms then they would have to. Since it is nearly impossible to tell that this is not the case they legally have to give notice. A company that deals in Reputation Management should know this.
PS Friendly Tip regarding credible sources I can already buy the list online. With passwords in decyphered. This doesn't lend well to they were Hashed and Salted.
The e-mail says "encrypted" and then clarifies what it means (salted & hashed). 99% of just about any site's users will not know what hashing means, but they would respond well to the term "encrypted," as it conveys the data was not recovered in a form that would be useful to an attacker. For those who do, it's offered as an explanation. I don't have a problem with this. Sufficiently encrypted data when you can prove an attacker could not access a key is potentially secure (albeit not ideal), just as a simple hash with a basic salt is potentially secure (for now, albeit not ideal).
Things like this are typically written by PR people, not engineers, so while we'd like to hear that passwords were hashed and salted using PBKDF2 with 4096 rounds of HMAC-SHA1, only the few thousand people who saw this article on HN (a small fraction of whom are likely impacted) would care to know this information.
> As for the statement that they aren't legally required to notify you... That's not true. If any of the people on the list live or access their account from North Carolina, or any of the 14 other states that use NC's breach terms then they would have to. Since it is nearly impossible to tell that this is not the case they legally have to give notice. A company that deals in Reputation Management should know this.
IANAL, however from my understanding, internet-based companies that have no physical presence within a state are not bound by these laws as they typically require a physical presence. They are obviously required to follow federal laws, but AFAIK, there is no federal law regarding security breach. However, since this company is based in California, one would expect them to be responsible for abiding by such laws here, and there are such laws. Credible sources, though, indicate that the criteria that require a breach have not been met in this case (first initial or first name + last initial or last name along with specific personally identifying information): http://www.law.berkeley.edu/files/cso_study.pdf. This citing the 2003 law (the study itself was done in 2007). Since the only thing accessed was name, address, dob, and phone numbers, the criteria on page 9 are not met. All handwavy of course, but in my IANAL opinion, this is perfectly valid in a letter. They may very well not be required by law to disclose the breach. They certainly are not required to disclose the breach to EVERY user (given some, themselves, are in CA), so it is neither correct to say "we are required" nor "we are not required." It doesn't really matter, at the end of the day. The breach was disclosed, end of story.
> PS Friendly Tip regarding credible sources I can already buy the list online. With passwords in decyphered. This doesn't lend well to they were Hashed and Salted.
You do not represent a credible source in this matter, nor does "I can already buy the list online" prove that such an availability exists, nor that it actually contains information from this breach, nor that that information contains plaintext password data.
At the end of the day, user passwords should be the least valuable piece of information in that database. I know that realistically they aren't, but I surely can't be the only person who makes the assumption that my password is always compromised for every website I use. I don't re-use passwords, and I generate them cryptographically for each site. I would personally be significantly more upset that they have my DOB, name, email, and phone number than that they have a password of mine.
At least one major software security company recommends, as best practice, doing an scrypt of your user passwords, and then doing an encryption of that based on a key stored in your appserver (which you may not necessarily lose as easy as you lose your DB).
I'm not necessarily defending that practice -- I was not prepared for a debate when presented with it -- but Reputation.com could well have gotten advice from this company and followed it, and they would call it "Salted and Hashed and Encrypted" very honestly.
That is a lot of personal data to lose given Reputation.com's supposed to be opening a data privacy vault this year.[1] The founder gave interview to Fox March 1st describing Reputation.com's move into vendor relationship management.[2]
Advocates for personal data vaults / VRM business model[3][4] like Reputation.com and Personal.com stress that personal data is mishandled today, especially by data brokers. Thus it must be particularly frustrating for Reputation.com to be directly involved in a data breach.
[1] http://www.nytimes.com/2012/12/09/business/company-envisions...
[2] http://www.reputation.com/reputationwatch/multimedia/michael...
[3] https://cyber.law.harvard.edu/projectvrm/Main_Page
[4] http://www.nytimes.com/2012/02/13/technology/start-ups-aim-t...
I don't really see a big drawback to inserting a few extra words, if those words might get reputable people to say that the bad thing that just happened wasn't really so bad.
What should one look into in order to fill in OWASP's gaps?
I put my salted and bcrypt'ed passwords in a CHAR or VARCHAR column named "password". Anything wrong with that? Should I change the name of the column to something like "hashed_password"?