App password/tokens must not be invalidated on password change

[nickvergessen]

I found this while discussing #2563 with @schiessle

Steps

1. Login
2. Create an app password
3. Setup sync client with 2.
4. Change password in personal settings

Expected

1. App passwords should still work, or
2. you should be warned that you need to regenerate all your app passwords.

Actual

Sync client auth fails

Same applies to the reset password, so maybe we should add a message there, like with encryption.

cc @ChristophWurst

[rullzer]

I would expect token to continue working if I change my password.

Now it might make sense to delete them if I do password recovery. But even then. The whole idea is that is is linked to 1 specific device/app/whatever.

[nickvergessen]

I wouldn't right away delete them, but mark them invalid or whatever, so people can still see the names of the app passwords they had to remember changing them everywhere.

[ChristophWurst]

I wouldn't right away delete them, but mark them invalid or whatever, so people can still see the names of the app passwords they had to remember changing them everywhere.

What's the benefit there? Just that you know which clients you had connected?

I would expect token to continue working if I change my password.

That would be great, of course. However, we had/have the requirement to have access to the login password at any time to reuse it for stuff like external storage.
To make it clean I'd like to give a brief overview of what we currently do:

• the token entry in the database belongs to either a browser session or a device
• for browser sesssion, we take its session id as the secret token, device passwords get a random one, which at the same time is the password you enter into your client.
• those tokens are hashed before we store them in the database
• the login password is encrypted and stored with the db token. we use the token (before hashing ofc) as encryption password.

This means: if you want to update the db entry of a device/browser session you'd have to know the secret token. Therefore this is simply impossible with the current implementation.

@LukasReschke thoughts? Anything we can do about that?

[nickvergessen]

What's the benefit there? Just that you know which clients you had connected?

Yes, it helps you to remember to create new tokens for all devices

[LukasReschke]

@LukasReschke thoughts? Anything we can do about that?

We can in fact do something about it, at least to some degree. So we would have to have an unique private key for every user which is encrypted with the secret token. The password is then encrypted in the DB to this private key and once a new password is detected it is getting updated.

This means we'd at max break the tokens until somebody logged-in again with password. Then all tokens would work again.

[mightyBroccoli]

I just noticed that this issue still happens.