Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Parent Full thread

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)

”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.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.

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.

> That majority could be as low as 50.0000001%

It could only be that low if they have about half a billion user accounts.

> 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.

I think at least Django stores passwords with an additional field that defines the algorithm used to generate the hash of the password. One could think of a case where instead of algorithm selection you could properly define a simplistic DSL that actually defines how the hash is generated:

  algo | hash
  bcrypt(hardness=2,input=INPUT + 23423526) | 938240
  bcrypt(hardness=3,input=INPUT + 342352643) | 239223

Now the only thing that one needs to do is convert this table to:

  algo | hash
  bcrypt(hardness=3,bcrypt(hardness=2,input=INPUT + 23423526)) | 23423423
  bcrypt(hardness=3,bcrypt(hardness=3,input=INPUT + 342352643)) | 90192902

Where

  bcrypt(hardness=3,938240) = 23423423
  bcrypt(hardness=3,239223) = 90192902

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.

Perhaps we have different definitions of ugly but seems like quite an elegant kludge to me :-)

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!

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

Reply on news.ycombinator.com