2024-02-02

Hiding passwords

A minor niggle, but some times you want a web form that has passwords.

The classic solution is type=password and send the password as the value. This works, and if the page is all https, then why not, it is secure. It also offers to save the password (something that is really hard to disable these days, and there are reasons to want to do that!).

But what if not https, for, reasons*

Sending a password is not ideal - but if not https, sending one back is also in the clear, but if the threat is purely snooping then it is not too daft to minimised sending it when not needing changing. You minimised the window of capturing it. You also stop someone simply requesting the page to see it, even if they are able to change it.

So a simple fix is to have a rouge value password you use to mean no change such as ********. You can send this and if a returned value is not that then it means a new password has been set.

It bugs me slightly, as it means you cannot have a password of ********.

Well, maybe.

  1. Only send when password set, as always useful to be clear if a password is set or not.
  2. Why not use something more esoteric, such as ✶✶✶✶✶✶✶✶ (unicode 6 pointed stars). Passwords should allow unicode stuff, obviously.
  3. Allow setting the password to the rogue value if not currently set, meaning you sent blank and not the rouge value, so the rouge value coming back means someone set it. This means the only limitation is changing from one password to the rouge value without unsetting it first - not a biggie (if documented).

* such as local control to a microcontroller that has limited capability to do https and limited capability to handle certificates. A problem we would all like to solve cleanly.

** And yes, I mean for those occasions where one cannot store a hash! They exist! WiFi passwords for one. But even when a hash, you need a way to know someone is trying to change the password, and this works for that too.

6 comments:

  1. Not 100% sure if this would work for all versions of your use case… Could you have the password field blank, but use the placeholder attribute to make it look password-y? Set placeholder=“********” and if they type in, those asterisks vanish as if they were pre-selected, and the form field value is set on POST, but only if they typed into the field.

    ReplyDelete
    Replies
    1. Then a password could never be removed, could it, if the form submit a blank was it the blank we sent or the user blanking the password?

      Delete
  2. If you're currently thinking about password security, any chance of getting SIPTLS support on the A&A SIP services?

    ReplyDelete
  3. Or have two different rouge values - one in the password field and one in the confirm new password field.

    ReplyDelete
  4. Perhaps I'm in a minority, but I absolutely detest password hiding.

    I'm almost never in a situation where "shoulder-surfing" would actually be an issue, but I frequently make typos when entering complex passwords, and occasionally want to extract a password from one form to enter it in another (e.g. a WiFi or PPP login saved in a router admin page), and a hidden password gets in the way of both of these usages.

    I would have no objection to passwords being hidden by default so long as there is a button to make the password visible, but a lot of apps and forms don't give you this option.

    ReplyDelete
    Replies
    1. I agree, and this stuff is not a "password" field, so when changing it you can see what you type, but as it is not secure it means existing password is not sent in the clear, which is a start.

      Delete

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

The power of eSIMs

I was always skeptical of eSIMs. The idea you have a mobile identity in a physical SIM that you control seems a sensible approach. An eSIM i...