Don't check for existing password emptyness

[maxpoulin64]

Pointed out by @pugabear, it's possible for a user to have an empty password. There isn't really a need to check for password emptyness, it will simply fail with wrong old password instead. This allows users with an empty password to be created and allows them to set a password.

While I think a temporary password should be used instead, we allow creating a user with no password so we should also handle it.

[astorije]

@maxpoulin64, why not reversing this and instead prevent creating/using empty passwords altogether?
I don't see a good use case for that and it's much, much better security-wise IMO.

[maxpoulin64]

@astorije: as said on IRC, I'm not a fan of it either but I don't see any case where we'd want to block password changes when there is no existing password either. I'll mark this as not ready for merging and disallow empty password later and fix #316 while at it.

[astorije]

Do you think there is a value as reviewing/merging this by itself, or the changes you have here will be removed with the other fix you mention?

[maxpoulin64]

No, I was thinking of doing both. I consider the current behavior to be a bug, because it's possible to get into a situation where the user can't use the feature because of conflicting conditions. The user will still be able to get into this situation if the json is edited manually, but it's reasonable to disallow it through the official ways. And there really is no possible harm by not doing that check, as comparing an empty password to a non-empty password will return a failure anyway.

[xPaw]

👍

The check is pretty much unnecessary here, as it compares the password either way. Merge whenever.

[astorije]

👍