Make it possible to use OC login credentials for external storage

[PVince81]

The idea is that any storage backend can have an option "use OC login credentials" so it will use the current user's credentials instead of requiring the admin to specify any.

So far the SMB_OC external storage already does this. This approach/code should be make generic to allow any external storage to do so.

Since recently the password is already stored in the session in encrypted form (right, @LukasReschke ?)

Some comments from @LukasReschke here: #12216 (comment)

@nickvergessen @MTRichards @craigpg @karlitschek @Xenopathic

[PVince81]

Note that there is already a magic variable "$user" which can be put into any configuration field and will be automatically replaced with the user name. Maybe a similar approach (even if it's done internally) could be used to replace the password.

[RobinMcCorkell]

There are two problems. One is that not every storage uses a username and password, so this option cannot be available for all storage types. In addition, having yet another configuration option on storages is going to make the UI even more cluttered: see #9663. Then you have the problem of storage types that already, or at least should, support multiple authentication types (SFTP with password/key?) - how do you manage those? It quickly becomes clear that our current approach to the config UI is insufficient.

[PVince81]

Thanks for your input.
For the multiple external storage options I think we should use a dropdown "extended options" that looks like the share dropdown, so space wouldn't be a big problem.

But the part about having multiple auth types (key instead of password) will need to be kept in mind. Maybe not all backends will support using the credentials.

For SFTP with password and one with key, I think this could be done now by registering two backends, one called "SFTP (password based)" and one calls "SFTP (key based)".

But ideally storage backends might need to be decoupled from their auth. One idea would be to hav Auth classes. Whenever a backend registers itself, it can also register a list of matching Auth classes/backends. And every 'Auth` backend can also specify fields/options to be displayed in the UI and an optional flag to say whether to use the login session's password.

[RobinMcCorkell]

@PVince81 That sounds like a perfect solution, however I'd put 'Use login credentials' as a separate auth type, so there are no redundant username + password fields as we have at the moment. However, it would be registered as a sub-type of password auth, so a storage backend only needs to register itself for password auth to get both standard password auth and the modified login credentials auth.

We still haven't worked out how to store the login credentials for sharing purposes though...

[PVince81]

Hmm yeah... fixing sharing was actually the main reason for this requirement.

[LukasReschke]

First requirement was to store password encrypted in mount.json, after that we can think about encrypting it somewhat more using the session as described at #12216 (comment) . - Should be chooseable per mount-pount by the user.

[PVince81]

Seems like this guy already tried introducing $uid and $password, linking here for reference: #11939

[PVince81]

Just had a discussion with @icewind1991 and @schiesbn and we raised the idea of using an algorithm similar to the encryption app to encrypt the password.

When user "user1" shares a mount point "SFTP" with users "user2" and "user3", the password is encrypted with the share keys of user1, user2 and user3 using "multikeyencrypt". (it is similar to when a file is shared with users "user2" and "user3" with the encryption app enabled).
However this approach would have the same shortcomings like the encryption app that when sharing with a group "group1" we need to use the share key of all members. So the admin who adds a user "user4" to such a group also needs to have access to the password to be able to reencrypt the password with all the share keys of all members, including the new member "user4". Maybe a group key could help with that.

@LukasReschke what do you think ?

[PVince81]

The recovery key approach could also help, which gives the admin access to any file (or encrypted mount password in this specific case).

[LukasReschke]

@LukasReschke what do you think ?

In my opinion: Massive overkill without any real gain instead of making the code harder and potential introducing more funny bugs and unexpected behaviour again.

The point here is: Against what do we want protect? - Let's just assume that as administrator you always get the password if you want to. Therefore you've nothing to hide from him. An initial encryption with a per-instance key is already a "sufficient" protection against looking at the file by mistake.

Then we have a malicious attacker left which is somehow able to snoop on the file system - admittedly, that is a problem, but we can make this already harder by storing some additional parts of the encryption secret in the database. That would be trivially to implement with the new crypto wrapper. And once an attacker has already access to the database and the local filesystem you can be pretty sure that he anyways will be able to execute arbitrary code. (actually - he easily is able to once he can write into the DB)

Do we really want to introduce some more magic that no user really can understand the reasoning behind only for the sake of having the password stored in an marginally better way? Supposedly, not storing the password at all would be the best solution but that would require the backend to support ticket-like systems (such as Kerberos).

[PVince81]

Yes, good arguments.

Supporting ticket-like systems like Kerberos would fit well with the "alternative auth" concept.

[PVince81]

Closing in favor of #16305