Hacker News Reader

Comment by jmbpiano | Hacker News Reader

"Passwords may not be duplicated across accounts"

This concerns me. How are they checking that no other account has the same password? Wouldn't that imply a strong possibility they're either hashing with the same salt across all accounts or not hashing at all?

Hopefully some of the smarter folks here can tell me why I'm way off base...

View on HN

Perhaps they assume that all of their users’ passwords are pwned essentially immediately, so they can check against haveibeenpwned.com.

More seriously, it ought to be possible to create a data structure that, with some degree of security, will efficiently state either that a password is probably in a set or that it’s probably not. A bloom filter can do this, for example. I would not do anything of this sort in production, since, even if it has the best possible level of cryptographic security, any such capability could be abused to precompute a dictionary containing at least a massively higher than average density of Heroku passwords.

IOW, the mere fact that Heroku can tell if a password is or was in use with decent accuracy is, in and of itself, a dangerous oracle.

“Sorry, this password is already being used by joseph.h.blow@gmail.com, please choose another.”

every so often i'll find a website that has logins that will say "email address / username not found" instead of "username or password incorrect"; or, when clicking "i forgot my password" it will say it doesn't recognize the email address instead of "check your email inbox, if you have an account here, you will receive instructions via email".

I don't even

You can remove username enumeration from login and password reset, but it's much harder to remove it from signup. And this is pretty much an all or nothing, there's no point giving cryptic error messages (in the case of forgot password) to users when hackers will just use the signup form anyways. Want a good example? Hacker News: "That username is taken. Please choose another." I just tried on github, generic error message on login, explicit "email in use" error on signup. Amazon? Same thing.

I'd wager that 99% of website allow username enumeration. The very few cases that don't, typically shield their signup with additional steps (captchas, mobile OTP (e.g. paypal, ...)). None of which are foolproof and all of which are a compromise not just from a security point of view but also from a usability point of view.

Until someone gives me a great way to do this with signups, I'm going to stick with the much more usable forgot password error message.

Hacker News has username enumeration anyway because it has per-user profile links which, like Reddit's, are cool URLs (ie the URL has the username in it, as a parameter, not some UUID minted by a machine at random).

Also, and again like (most of) Reddit, Hacker News is public anyway, it's outright weird to have a HN user, choose a distinct name for it when you didn't have to, and then be angry that HN reveals the existence of your user.

However, if sites have distinct username and email then getting one doesn't give you the other.

How about email validation as a first step and send the "this email is in use" message via email instead of on the sign up form.

Adds friction to signup, but would work when it's really important to not leak account existence.

I think this is a good idea. It's essentially what I mentioned with Paypal requiring OTP before the signup process starts up.

But as you said, it adds a lot of friction to something most companies want to be as frictionless as possible: signups. So it's a compromise. I don't expect many companies will opt for it, except, as you say, those where it's particularly important.

I stand by my reply, since my parent implied that username enumeration was rare (i.e. "every so often") and some awful security practice (i.e. "I don't even")

multiple salts can be stored, no? and they can still figure out the same password. Google does the same, even going back multiple passwords in the past ("this password was used previously X years ago").

How would you check that across accounts if you had per-user salts though?

Ah I see, that I don't know (and I misread the original, quite correctly concerned post, my apologies). I am a customer and I will follow up with them about this. If I were to guess, they mean same accounts within the same organization, in case account setup has been automated.

They could in theory hash the new password with every salt on every other account and see if there is a match... but that seems unrealistic, and if they can do it, it would imply that they are not using a slow hash algorithm such as bcrypt.

Yeah, that makes sense!

This is the response I got:

> Sorry, that part of the email wasn't clear. We don't compare passwords between Heroku accounts, this was more of encouragement so customers will hopefully practice good password hygiene.

It is easy to determine previous password. Just store the previous hashes with the salt and check it when the user changes the password. The too similar checks are easy when you require the previous password. You can compare the new and old passwords together.

I'm pretty sure they don't check. "May" now means "legal told us to ask you to PLEASE don't do this".

Related, I often see people trip on the sense of MAY in RFCs (https://www.ietf.org/rfc/rfc2119.txt), because in everyday use it has become "passive-agressive must".

edit: I'm ESL so might be reading way to much into this.

"may not" is kind of weird, and probably was a legal team decision. "passwords can not be reused" would imply security issues that an A+ certified fresh-faced intern would prickle at, but "should not be reused" is too mealy and "Do not feed the ducks"-ish.

Also while "MAY" in RFCs per that document mean something, press releases aren't RFCs and there may be significant amounts of money riding on the exact interpretation of what those words mean.

And "reading way too much into" is the bread and butter of lawyers, technologists, and mathematicians. Don't worry about it!

All you do is keep a history of Password + Salt. When you change the password you hash the password against all historical salts, if one of those matches then you know the password has been re-used.

Perhaps the haveibeenpwned.com API? Otherwise that does seem odd

https://haveibeenpwned.com/API/v3

Couldn't you freeze the current, compromised database and when a user tries to set their password, try to "log them in" to the frozen db?

What does that line even mean? Duplicated across what accounts? Obviously they aren't checking that every password across Heroku is unique.

That's how I read it. How else would the sentence make sense? Maybe they're saving a separate list of all passwords, saved with the same salt, but not associated with any account? Not sure how compatible that would be with the rest of their "security measures", but then again, their security policy is all over the place already.

not that they're using it, but this is something that a zk proof would be a good solution.

Reply on news.ycombinator.com