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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate dialog for keyboard-interactive prompts #7573

Closed
cyberduck opened this issue Nov 7, 2013 · 5 comments
Closed

Separate dialog for keyboard-interactive prompts #7573

cyberduck opened this issue Nov 7, 2013 · 5 comments
Assignees
Labels
Milestone

Comments

@cyberduck
Copy link
Collaborator

1bfeaf9 created the issue

Some keyboard-interactive authentication schemes involve echo-on prompts, and echo-off prompts which don't correspond to user passwords (e.g. PIN prompts). The current behavior which is to use the standard user/password dialog for the prompts works, but is very confusing especially for echo-on prompts (e.g. giving an e-mail address in a password field). A separate dialog for keyboard-interactive authentication could support all possible prompts in a general way.


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

How would that input prompt differ from the standard window? Can you provide a mock up?

@cyberduck
Copy link
Collaborator Author

1bfeaf9 commented

The most straightforward solution would be to bring up a dialog for each prompt in turn, containing the prompt message and a single input field for the answer. The input field would be a regular text field or a password field depending on the "echo" flag for that prompt. I've attached a screenshot showing how this is implemented in WinSCP. Here, "#AC login:" is the prompt message and the field is a regular text field (echo on).

Generally speaking, it's not possible for a client application to know for sure the meaning of any prompt, because the challenge-response authentication method can't convey any metadata about them. Still, if the server is simply doing normal password authentication using challenge-response, sending a simple "Password:" prompt, it's probably safe to assume that is the password. Currently, Cyberduck assumes that the first prompt is always the password prompt regardless of the message or value of the echo flag.

Here is how I would implement this:

  • If this is the first prompt, echo=off and the message is "Password:", assume it's asking for the user's password. Supply the value from the standard user/password dialog (or automatically, if the user chose remember password). If that is all the server wants, then the user doesn't have to deal with the challenge/response prompt dialog.
  • If this is the first prompt, but the prompt it something else, then don't assume anything and just present the user with the challenge/response dialog. Don't record the answer anywhere (as in "remember password"), since it's not really possible to say if this is a one-time value (e.g. google authenticator code) or not.
  • For all the rest of the prompts, present the challenge/response dialog.

Note that if a "Password:" prompt comes in after the first prompt, it might not correspond the password for the SSH user. This is the case for the service depicted in the screenshot, where it first asks the user for his e-mail address, and then for a password corresponding to that e-mail address (not the SSH user). In this case, the password from the standard user/password dialog would go unused and could be left empty.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 67484c0 and fde28ac. Please test and reopen this ticket if there are remaining issues with challenge response authentication.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#7865 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please update to the latest snapshot build available and reopen this ticket if there are remaining issues with two factor authentication.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants