Authentication migration was handled VERY poorly

The new authentication as of 0.77 is described in the blog post as a “non-breaking change”. There is no further word on how existing configurations would behave under the update. I interpreted this to mean that, given my preexisting installation, things would continue to function as it did previously. This was not the case; in fact, the actual behavior is incredibly dangerous and nothing short of negligent on the part of the developers.

Browsers with a preexisting authentication token were still “logged in” despite there not being any account. So I’m seeing my dashboard just fine and have no clue that there’s a sudden gaping security hole: clients without a token are served an unauthenticated prompt to create the owner account.

I normally have my instance exposed to the open Internet on a nonstandard port, as to me the risks are worth avoiding the headaches of maintaining VPN clients on various phones. So, for about a day, my server was inviting anyone that says hello to take full control of the system, no exploit needed, and all my devices acted like there was nothing wrong.

To be clear, I still had my API password in my configuration. The system had a preexisting authentication mechanism that it knew full well about and could have easily hidden the account creation behind the old password prompt. There is zero excuse.

Future changes to security and authentication must be handled carefully, and communication and migration methods carefully considered to, one, spell out how those changes will impact existing installations, and two, ensure that the changes do not disable preexisting security measures.

1 Like