4 ms·

"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 st

• why-el 4y ago
  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").
  • vorador 4y ago
    How would you check that across accounts if you had per-user salts though?
    • why-el 4y ago
      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.
      • vorador 4y ago
        Yeah, that makes sense!
        • why-el 4y ago
          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.
      • throwawayboise 4y ago
        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.
  • adrr 4y ago
    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.
• paxys 4y ago
  What does that line even mean? Duplicated across what accounts? Obviously they aren't checking that every password across Heroku is unique.
  • addandsubtract 4y ago
    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.
• amluto 4y ago
  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.
  • avalys 4y ago
    “Sorry, this password is already being used by joseph.h.blow@gmail.com, please choose another.”
    • genewitch 4y ago
      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
      • latch 4y ago
        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.
• na85 4y ago
  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?
• deleted 4y ago
  [deleted]
• philliphaydon 4y ago
  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.
• fourstar 4y ago
  not that they're using it, but this is something that a zk proof would be a good solution.
• slenk 4y ago
  Perhaps the haveibeenpwned.com API? Otherwise that does seem odd https://haveibeenpwned.com/API/v3 https://haveibeenpwned.com/API/v3
• bibinou 4y ago
  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 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.
  • genewitch 4y ago
    "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!