0

When registering for an account or when resetting a password of a web service, users are often required to type their password twice to ensure that they do not accidentally misspell their passwords.

If accidental misspelling is the only consideration for this feature, it would be acceptable (perhaps even better, from a website design perspective) for the retyped password to be validated by browser/client JavaScript rather than being sent to the server for validation.

Am I right that accidental misspelling is the only consideration for this feature?

Bernard
  • 5,209
  • 1
  • 34
  • 64
  • Yea, that sounds right to me. Just hash both immediately, compare the hashes, and then if they match send the one hash over https to your server. – Jameson Feb 19 '17 at 10:06
  • @Jameson Why should the password be hashed before sending to the server? That would make the hash logically become the user's password - someone who intercepts the hash can impersonate the user. Right now I'm sending the real password over HTTPS, and then salting and hashing at the server before storing it into my database. – Bernard Feb 19 '17 at 10:12
  • i don't see the point of comparing hashes instead of value, nor of bringing hashing into JS just for that. yes, it IS only a user convenience... – dandavis Feb 19 '17 at 10:16
  • 1
    @Bernard http://stackoverflow.com/a/21716654/695787 – Jameson Feb 19 '17 at 10:16
  • people like doing extra things that kirchoff would laugh at, but on a human level, it makes them _feel_ better... If https works, then why hash? if https doesn't work, the hash still does nothing to protect the password. – dandavis Feb 19 '17 at 10:19

1 Answers1

0

This is a bit pedantic, but a confirmation field is for accidental mis-entry rather than misspelling as such given the nature of passwords.

To answer your question; yes, a password re-entry field is just for verification of the user's input.

JavaScript could be used to ensure the entry meets the password requirements (length, special/valid characters, strength, etc.), but what if the user has JavaScript disabled? You'd have to code for the password to be validated server side in this case. Also, it's possible that, as the code is client side, it could be tampered with to bypass your checks (some people just like to break things). On top of that, from a web design perspective, the client will need to download more code in order to achieve this instead of posting an extra form field so there's an extra (albeit very small) data-use overhead when considering mobile.

All this can be rendered unnecessary however. If your password reset process is secure and robust enough (e.g. require email address verification), then you arguably don't need the user to verify that they've typed in what they meant to. You'd need a process to remove accounts that hadn't been validated though, in case they mis-entered their email address... unless you get them to enter their email address twice ;) For example, based on the fact Stack Overflow only required me to enter a password once upon registration, this seems to be the approach this site uses.

Hope this helps.

JNoob
  • 58
  • 1
  • 4