Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow submission of one-time password on API calls #1114

Open
bpcurse opened this issue May 14, 2021 · 4 comments
Open

Allow submission of one-time password on API calls #1114

bpcurse opened this issue May 14, 2021 · 4 comments

Comments

@bpcurse
Copy link

bpcurse commented May 14, 2021

Feature Request

Not sure if this feature request belongs here or in the server repository 馃 Sorry if it's the wrong one.

The use of one-time passwords is a nice security enhancement and I would like to enable it for all users, but I think there is a use case that hasn't been anticipated yet.

Login through the web interface lets you provide user credentials and totp, external applications can use app passwords but afaik (trusted) external applications that let the user enter their credentials cannot access totp protected accounts.
I haven't found a way to supply the one-time password to the API. Github for example supports the X-GitHub-OTP header.

Use case: For security reasons I do not want to store an app password in an external application (at least not yet) but instead let users provide their credentials including totp to a form when needed.

Summary

Support the submission of one-time password on API calls (e.g. user metadata).

@ChristophWurst
Copy link
Member

can't you use oauth?

@ChristophWurst
Copy link
Member

if your application sends the request (including the totp as some sort of special header) the situation is already bad as the user has to pass their actual login password to your application. They are better off if an app password is used or oauth. Then your application doesn't ever get hold off the password.

@bpcurse
Copy link
Author

bpcurse commented May 19, 2021

Thank you @ChristophWurst for the quick reply.

I should describe the use case a bit more. It refers to my supporting user management tool https://github.com/bpcurse/nextcloud-userexport (please don't judge it now, there is a major rewrite going on).
The tool is meant to be self hosted by server admins. Administrators are asked for their credentials, which are then used in API requests to pull Nextcloud data (user metadata, ...). Credentials are stored until logout or for up to an hour in session variables. I will probably delete them immediately in the next version or make this configurable.

Although I could ask the users to create an app password and store it in a database, they would still need to authenticate against the tool on each use, potentially using their Nextcloud credentials here, too.
Aside from the need to create and store an app password I would have to create a login process that is as secure as the one from Nextcloud itself. I do trust the Nextcloud dev team to be far more competent than me ;)
But even if this process was secure enough, the basic idea of using OTP would somehow be corrupted.
I am afraid that people might create non-OTP protected accounts to still use the functionality of the tool.
That's why I'm asking for this feature. If the concept itself was wrong, why should a major portal like github allow it?

What would of course be an interesting alternative is a web login process similar to Nextcloud's official apps to handle OTP protected account access. Sorry if I am misusing this issue for questions, but is it complicated to achieve this?

@ChristophWurst
Copy link
Member

What would of course be an interesting alternative is a web login process similar to Nextcloud's official apps to handle OTP protected account access. Sorry if I am misusing this issue for questions, but is it complicated to achieve this?

This is why I suggested oauth. It does that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants