• Clent@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    6
    ·
    20 days ago

    This thread is just a series of people who think they understand.

    Thinking you understand when you do not is the real cyber security threat.

    This is a password reset form. This requires the user having successfully authenticated or gone through a password recovery form. The best practices in this instance are not the same as the best practices for a login form.

    • Agent641@lemmy.world
      link
      fedilink
      arrow-up
      11
      arrow-down
      1
      ·
      20 days ago

      This form can be used to brute force or dictionary guess passwords and infer what they are without a limitation on login attempts. Even if the password has already been invalidated on that service, finding a collision on this service gives you a password that might work on other services for the same email address/username

      • Clent@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        20 days ago

        And waiting for a form submit changes that in what way that cannot also be done on a debounce?

    • owenfromcanada@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      20 days ago
      1. Aquire password database (it’s properly hashed and salted)
      2. Create an account and access the password reset form
      3. Dig into the front-end code to find whatever is doing the hash calculations
      4. Brute-force a list of common passwords and look for matches

      It would still take significant time, but it’s still a vulnerability, especially as technology evolves. You’re right that best practices are different for a reset form, but there are some things that are common (like don’t do hashes in the front end).