3 ms·

That's unfortunate. At least we didn't get the stereotypical "your passwords are hashed, so nothing to worry about" one liner I've been reading from a lot of c

That's unfortunate. At least we didn't get the stereotypical "your passwords are hashed, so nothing to worry about" one liner I've been reading from a lot of companies during disclosures. All they said here is that the passwords are hashed and with a reasonably secure method -- bcrypt (although without knowing work-factor and percentage of passwords, it is hard to know just how strongly). It has become pretty difficult to operate online these days without password managers. Password reuse has become a massive problem that worsens with each breach at a popular service. With a password manager you can just rotate the randomly generated password since you likely didn't know your old one anyway. Off Topic: I'm surprised nobody makes a hardware "pepper"[0] that supports popular algorithms. Meaning you hash the password as you normally would (inc. salt) and then send it through the pepper-ing device for another round before storing it. That way even if someone stole the database, knew the salt, and the hashing algorithm+work-factor, they'd still lack the hardware pepper making their job significantly harder. [0] https://en.wikipedia.org/wiki/Pepper_(cryptography) https://en.wikipedia.org/wiki/Pepper_(cryptography)

Someone 9y ago
”All they said here is that the passwords are hashed and with a reasonably secure method -- bcrypt” The “majority” of the passwords was hashed with bcrypt. https://content.myfitnesspal.com/security-information/FAQ.html https://content.myfitnesspal.com/security-information/FAQ.ht...: ”The MyFitnessPal account information that was not protected using bcrypt was protected with SHA-1, a 160-bit hashing function.” That majority could be as low as 50.0000001%. I also couldn’t find how many accounts were affected. I guess they don’t know, so we must assume all of them.
- recursive 9y ago
  > That majority could be as low as 50.0000001% It could only be that low if they have about half a billion user accounts.
- matthewmacleod 9y ago
  They probably do know, and practically speaking I would guess that those accounts using an older hash are those which nobody has logged into since they switched to bcrypt. Yeah, we don’t know for certain, but it’s a reasonable assumption.
asdsa5325 9y ago
A hardware pepper / software implemented with existing integrated crypto hardware is a great idea.
tzs 9y ago
> All they said here is that the passwords are hashed and with a reasonably secure method -- bcrypt (although without knowing work-factor and percentage of passwords, it is hard to know just how strongly) Speaking of proper password hashing--are there any methods similar to bcrypt but where you can increase the work factor on the currently stored passwords without having to have access to the plain password? E.g., suppose you have a database of hashed passwords with work factor 4. You want to up the work factor to 6. The usual way to do this that I've seen is to start using 6 for new passwords, and when people with existing passwords log in you verify the password with the 4 hash, and then before discarding the plain password you 6 hash it and update the database with that. But that leaves 4 hash password still working for however long it takes people to get around to logging in. If you are raising the work factor it is presumably because you think the old work factor is no longer secure enough, so you probably don't want the old 4 hashes to keep working. You could remove the 4 hashes of anyone who doesn't login and get updated within a reasonable time, making them go through the "forgot my password" routine, but that will annoy them. Hence, my curiosity about ways to updated the work factor more directly. There's a kludge way to kind of do it. Go through the database, take all the 4 hashes, and treat those hashes as if they were the passwords, and 6 hash those and store them, along with a flag that marks this as a transitional password. When a user with such a password logs in, you 4 hash their plain password, 6 hash the result, and if it matches, you then 6 hash the plain text password and store the hash, and remove the transitional flag. But this is really quite ugly.
- entropy_ 9y ago
  Perhaps we have different definitions of ugly but seems like quite an elegant kludge to me :-)
- larkeith 9y ago
  Another slightly kludgey option would be to generate a second salt for each user, then 2 hash each hashed password in your database. When the user logs in, you 4 hash with the original salt and 2 hash with the new one each time. Interestingly, a similar scheme could be used to offload some of the hashing work to the client machine - send the first salt to the client and have them do the 4 hash, then do a serverside 2 hash on the client's result.
Dibes 9y ago
I initially really liked the idea of a hardware pepper, however, if that ever goes defunct or you need to spread the load over multiple machines the password now is invalid and the user is stranded and forced to recover their account via email or some other means. I think there are definitely areas where a hardware pepper would be awesome though!

Someone 9y ago

”All they said here is that the passwords are hashed and with a reasonably secure method -- bcrypt” The “majority” of the passwords was hashed with bcrypt. https://content.myfitnesspal.com/security-information/FAQ.html https://content.myfitnesspal.com/security-information/FAQ.ht...: ”The MyFitnessPal account information that was not protected using bcrypt was protected with SHA-1, a 160-bit hashing function.” That majority could be as low as 50.0000001%. I also couldn’t find how many accounts were affected. I guess they don’t know, so we must assume all of them.

recursive 9y ago
> That majority could be as low as 50.0000001% It could only be that low if they have about half a billion user accounts.
matthewmacleod 9y ago
They probably do know, and practically speaking I would guess that those accounts using an older hash are those which nobody has logged into since they switched to bcrypt. Yeah, we don’t know for certain, but it’s a reasonable assumption.

asdsa5325 9y ago

A hardware pepper / software implemented with existing integrated crypto hardware is a great idea.

tzs 9y ago

> All they said here is that the passwords are hashed and with a reasonably secure method -- bcrypt (although without knowing work-factor and percentage of passwords, it is hard to know just how strongly) Speaking of proper password hashing--are there any methods similar to bcrypt but where you can increase the work factor on the currently stored passwords without having to have access to the plain password? E.g., suppose you have a database of hashed passwords with work factor 4. You want to up the work factor to 6. The usual way to do this that I've seen is to start using 6 for new passwords, and when people with existing passwords log in you verify the password with the 4 hash, and then before discarding the plain password you 6 hash it and update the database with that. But that leaves 4 hash password still working for however long it takes people to get around to logging in. If you are raising the work factor it is presumably because you think the old work factor is no longer secure enough, so you probably don't want the old 4 hashes to keep working. You could remove the 4 hashes of anyone who doesn't login and get updated within a reasonable time, making them go through the "forgot my password" routine, but that will annoy them. Hence, my curiosity about ways to updated the work factor more directly. There's a kludge way to kind of do it. Go through the database, take all the 4 hashes, and treat those hashes as if they were the passwords, and 6 hash those and store them, along with a flag that marks this as a transitional password. When a user with such a password logs in, you 4 hash their plain password, 6 hash the result, and if it matches, you then 6 hash the plain text password and store the hash, and remove the transitional flag. But this is really quite ugly.

entropy_ 9y ago
Perhaps we have different definitions of ugly but seems like quite an elegant kludge to me :-)
larkeith 9y ago
Another slightly kludgey option would be to generate a second salt for each user, then 2 hash each hashed password in your database. When the user logs in, you 4 hash with the original salt and 2 hash with the new one each time. Interestingly, a similar scheme could be used to offload some of the hashing work to the client machine - send the first salt to the client and have them do the 4 hash, then do a serverside 2 hash on the client's result.

Dibes 9y ago

I initially really liked the idea of a hardware pepper, however, if that ever goes defunct or you need to spread the load over multiple machines the password now is invalid and the user is stranded and forced to recover their account via email or some other means. I think there are definitely areas where a hardware pepper would be awesome though!