10 ms·

Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A relate

• joaomacp 5y ago
  It can all be done client-side: the client can try (un)capitalizing the letters after the original password fails
  • freemint 5y ago
    This would be bad for rate limiting though.
    • jacurtis 5y ago
      Note that the client would only need to do this on a failed attempt. So if i typed "Password" on mobile. The client would first send the request as "Password". If that succeeds, then no worries. If it fails, then the client could send a second request by reversing the case of the first letter. In this case, it would send a second request for "password". At most, it is 2 login requests per password. Many other commenters here are incorrectly stating that 3 requests would be necessary, but this is untrue. A letter can only have 2 possible cases (uppercase or lowercase). So the client sends the originally typed one, and if that fails, then it flips the case of that first letter. That is the only alternative. There is not a third option. A well-built login form would restrict users after 3-5 login attempts anyway and require a password-reset process. So that is 6-10 client requests to the backend (n * 2). That shouldn't be hitting any sort of rate limit.
      • ipaddr 5y ago
        Why would you need the client to send the request over and over when you control the backend?
        • volkanvardar 5y ago
          Not to send the password in plain, maybe?
          • freemint 5y ago
            Are you aware of transport encryption?
    • ehsankia 5y ago
      It would only half the rate limit, but any real brute force attempt requires way way more than what a normal human would try. Something like 5 attempts would double to 10 in the backend, still nowhere enough to bruteforce, but enough for human trial and error.
  • konschubert 5y ago
    And it should. Better not to clutter the security-critical parts of the back end.
• bborud 5y ago
  You would just hash the incoming password with however many mutations you need.
• hashworks 5y ago
  Most certainly not. Those systems normally work by A) you providing the old password for verification or B) storing hashes of password substrings.
  • jhgb 5y ago
    This sounds like a combinatorial explosion situation for longer passwords and longer changes required.
    • deleted 5y ago
      [deleted]
• ineedasername 5y ago
  They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.
  • adolph 5y ago
    I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple. To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.
    • dylan604 5y ago
      why would you have to retrieve multiple? could you not calculate the 3 hashes, and then do SELECT WHERE pass = HASH1 OR pass = HASH2 OR pass = HASH3? You don't care which one was correct just that one is.
      • eterm 5y ago
        Please never implement a password feature without reading more about how passwords should be stored.
        • names_are_hard 5y ago
          Instead of just telling the parent that they're doing something can wrong in a condescending way, can you explain what it is they should do differently? At least a link to an article that explains this?
        • dylan604 5y ago
          good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.
• WithinReason 5y ago
  You could normalize the PW before hashing (invert case unless last letter is lower case, then make 1st letter lower case)
• farmerstan 5y ago
  I’m sure it’s client side and it just retries the different ways if it encounters a password error. Much easier and more secure than 3 versions of the password.
• sokoloff 5y ago
  To your related question, on the rare systems where I’ve had to do that, I’ve always (to the limit of my memory) had to submit “old password” “new password” “new password again”, so the old password would be available in plaintext client side (and still able to be verified server side after hashing).
• miki123211 5y ago
  When you change your password, you're usually required to enter both the old and the new one. This is when the check is usually performed. What I'm more worried about is the system that some Polish banks use, called masked passwords over here. With this system, you're only required to enter certain characters of your password, but the set of required characters changes at each login. This exists to make key loggers much less effective. There's apparently some hashing going on (something to do with curves and polynomials), but I couldn't find more details when I last looked.
  • jsf01 5y ago
    Hopefully the bank stores a separate hash for each mask, generated at the time of password creation. Otherwise, it’s hard for me to imagine how this would be possible without saving the password in clear text.
    • repsilat 5y ago
      > a separate hash for each mask If someone steals a hash for characters 1-4 they'll be able to brute force it. Only 10000x the cost of a single login. And then if you have the hash for characters 2-5...
  • BrandoElFollito 5y ago
    Is this still the case? When living in Poland 15 years ago I had an account with WBK and they had this idiotic system where I had to write my password on a piece of paper with numbers below to be able to give the 3rd, 5th and 11th character. Goodbye password managers (at least the automatization part). Then, suddenly, they got back to a normal login and password (I think I had the choice IIRC) but then I left the country. Poland is a beautiful country, I lived in Krakow for a few years and it was A-WE-SOME.