Notice of Security Incident

https://about.flipboard.com/support-information-incident-May-2019/

by captn3m0 • 7 years ago

46 23 7 years ago

about.flipboard.com

For an app that I no longer use, long since deleted and have forgotten about, hearing that there was a security incident that compromised my password is unsettling. I was relieved that I logged in to their app through twitter and my password wasn't store through them.

newnewpdro• 7 years ago

Why does it matter? Do you use the same password everywhere?

kelnos• 7 years ago

Same here, at least for the first part. I had used a plain email/password to sign up. After getting this advisory I reset my password and immediately deleted my account.

Nothing against Flipboard, and I appreciate the level of transparency here, but it's annoying to think that I created that account 7 or 8 years ago, haven't touched it since, and it's still there, with the potential to be a liability to me.

CiPHPerCoder3• 7 years ago

If users created or changed their password after March 14, 2012, it is hashed with a function called bcrypt. If users have not changed their password since then, it is uniquely salted and hashed with SHA-1.

This is a common mistake.

Don't ever do opportunistic upgrades. Instead, upgrade all at once and retain "legacy" metadata needed to re-authenticate the user until their password hash is rotated. https://paragonie.com/blog/2016/02/how-safely-store-password...

Beyond that: Bcrypt is great, SHA1 is terrible, and the level of technical detail in this advisory is excellent. The fact that I was even able to critique their 7 years old security decision at all speaks volumes to the transparancy.

msbarnett5• 7 years ago

Popped in to say exactly this.

If you ever come across insecurely hashed passwords in your career, always remediate all of them with a second more secure hashing strategy at once.

moloch• 7 years ago

I think their main mistake was requiring a user to change their password to upgrade the hash instead of upgrading the hash on the next user login.

CiPHPerCoder3• 7 years ago

What if there wasn't a "next user login"? You'd hold onto insecure hashes possibly forever.

Don't make this mistake. Rehash all of them up front.

The details of whether or not users are forced to change their password is irrelevant to the escape route from this trap.

msbarnett5• 7 years ago

Half measures are not solutions. Keeping insecure hashes on hand was the main mistake, full stop.

They'd still have leaked all of the insecure hashes of people who never logged in after the change in 2012 -- and that's still not good enough.

Immediate remediation means never keeping toxic hashes on hand, and never having to say to any subset of your customers "Sorry, but your password has been compromised due to our incompetence".

danarel• 7 years ago

This just made for a good reminder I needed to close this account.

ppierald• 7 years ago

Bummer for the company and I wish them well as they navigate the incident response waters. What I found interesting from the article was

If users created or changed their password after March 14, 2012, it is hashed with a function called bcrypt. If users have not changed their password since then, it is uniquely salted and hashed with SHA-1.

They could have migrated all accounts regardless of whether they came back to the site or not, changed their password or not, etc. Just use:

password_hash = bcrypt(sha1(raw_password))

earblast2• 7 years ago

What can someone use as a salt that is unique to a user that would not be in that record as plain-text and guess-able? Creation timestamp? email? username?

c222• 7 years ago

Just use a random value and store it with the hashed password. The salt is there to prevent an attacker from using a rainbow table to search your whole database for known passwords. Even if they have all your hashes and all your salts the fact the salts are unique forces them to attack each hash individually.

What you're looking for is a pepper [0]

[0] https://en.wikipedia.org/wiki/Pepper_(cryptography)

earblast2• 7 years ago

Hmm, seems to me using both is optimal

horrible psuedocode follows...

  cryptchoice = len(username) % 3

  switch cryptchoice:
     case 0:
       pepper = pepper[1]
       salt = email

     case 1:
       pepper = pepper[0]
       salt = creation_time
       
     case 2:
       pepper = pepper[2]
       salt = username
       
  bcrypt(salt+password+pepper)

Notice of Security Incident

Related Stories