Design improvement for encryption + reset password

Hi,

There are 2 major issues when a password reset is performed with encryption enabled. Especially the first one is actually well known, and has been reported from time to time, but I would like to discuss and contribute (if necessary) to finally provide a solution that isn't only a half-hearted one.

1) Existing files cannot be opened anymore after a password reset

Previously uploaded files can only be recovered when all these conditions are met:

• the user has enabled the password recovery option before the incident
• he reaches out to a system or group administrator for help to reset the password
• the new password is communicated in a (hopefully) secure way between the administrator and the user

To have to go through all this, doesn't really promote user-friendliness, to say the least. In a project of a larger scale, this would additionally lead to administrative overhead as a non-negligible consequence.

Obviously, an ideal solution would be to provide the same user experience as when encryption was disabled.

2) There is only one global recovery password

As there is only one global recovery password to recover files after a password reset, this password needs to be shared among all relevant system and group administrators. The more groups and administrators exist in an environment, the more communicating the recovery password (e.g. after a renewal) becomes a security concern.

Here, it would be more preferable, if every administrator could maintain his own recovery password.

Solutions?

If issue 1) could be resolved, it would obviously at the same time solve issue 2), so the focus would be on 1). Last but not least, there have been quite a few reports about it (e.g. #427 etc.) and there are examples (including my project) where the reset password function with the current design would prove completely useless and would have to be themed out completely.

Solution A

One solution that currently comes to my mind is to use a similar method like the master key approach. With the master key, the application is able to decrypt user files automatically, so how about doing the same with the recovery key? Just additionally it would be helpful to add a feature enabling the renewal of the recovery key through occ (for reference see here).

An activation of this feature could be an optional setting like "Automatic recovery". It would leave the current approach untouched by default and only comes to action if activated. If activated, recovery is enabled for all users by default and there won't be any indications of manual password recovery in the Web UI any more.

Solution B, C, D...

Any idea? :D

@schiessle @LukasReschke Your opinion is highly appreciated :)

Start by reviewing the existing password-reset and encrypted-file recovery behavior, including the related issue #427 and the master key approach mentioned here. Compare the current manual recovery flow with the proposed automatic recovery and per-administrator recovery ideas; done would require an agreed design before implementation.