Cyberduck Mountain Duck CLI

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#7573 closed enhancement (fixed)

Separate dialog for keyboard-interactive prompts

Reported by: samukallio Owned by: dkocher
Priority: low Milestone: 4.4.4
Component: sftp Version: 4.4
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

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 (1)

winscp.png (22.3 KB) - added by samukallio 5 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 5 years ago by dkocher

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

Changed 5 years ago by samukallio

comment:2 Changed 5 years ago by samukallio

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.

Last edited 5 years ago by samukallio (previous) (diff)

comment:3 Changed 5 years ago by dkocher

  • Milestone set to 4.5
  • Status changed from new to assigned

comment:4 Changed 5 years ago by dkocher

  • Milestone changed from 4.5 to 4.4.4
  • Resolution set to fixed
  • Status changed from assigned to closed

In r14423 and r14426. Please test and reopen this ticket if there are remaining issues with challenge response authentication.

Last edited 5 years ago by dkocher (previous) (diff)

comment:5 Changed 5 years ago by dkocher

#7865 closed as duplicate.

comment:6 Changed 5 years ago by dkocher

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

Note: See TracTickets for help on using tickets.
swiss made software