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

Remove password saved to keychain #9096

Closed
cyberduck opened this issue Nov 4, 2015 · 9 comments
Closed

Remove password saved to keychain #9096

cyberduck opened this issue Nov 4, 2015 · 9 comments

Comments

@cyberduck
Copy link
Collaborator

cyberduck commented Nov 4, 2015

edae31c created the issue

Hi, thanks for writing this application.

I noticed a weird behavior with a password that is saved and cannot be cleaned from within the application no matter what I've tried.

  1. With option 'Use Keychain' enabled, I created a bookmark for an S3 bucket only by setting the remote path to be the '/bucket-name'
  2. Launched the bookmark, entered access credentials and, while the 'Save Password' option in that dialog was checked, I connected to the remote resource.
  3. After unchecking the 'Use keychain' option in the settings, deleting the bookmark and history, and also after editing the bookmark and removing the saved access ID, every time I enter the access ID (that had been previously saved), the password field is also auto-populated.

This does not happen with bookmarks that were created after 'Use keychain' was unchecked, which results in the 'Save password' option to be deactivated in the dialog for credentials.

The expected behavior would be the application to auto clean the saved password for the resource if the 'save password' is unchecked.

I'd appreciate some pointers about how to completely clean the password from where it has been stored, as it happened to enter it in a 3rd party pc. The program was launched by an unprivileged Windows user, while it had been installed system-wide.

Where are the passwords saved?

Looking forward to your reply.

Kind Regards,
George

@cyberduck
Copy link
Collaborator Author

cyberduck commented Nov 4, 2015

edae31c commented

After much effort the only way to resolve this was to revoke my access credentials and generate new ones in the AWS IAM console. But that really sucked as a workaround...

Please find a way to make the application clear those saved passwords automatically or, if there is a bug involved, please fix it.

I would also suggest the following:

  • The option to save the password, which exists in the dialog that asks for the credentials, should be unchecked by default.
  • IMHO you should consider disabling the "Use Keychain" option by default.
  • Moreover, the application is configured to save too much information by default out of the box (username, password, credential auto-saving, history). IMHO, apart from the above, there should be options to prevent it from saving history, even from saving the username, if it hasn't explicitly been set in the bookmark.

Kind Regards,
George

@cyberduck
Copy link
Collaborator Author

cyberduck commented Nov 4, 2015

@dkocher commented

Documentation in wiki.

Passwords are encrypted using the Windows Data Protection API (​DPAPI) and stored in the user.config file in the application support directory.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Nov 4, 2015

@dkocher commented

On the Mac, you can manage passwords using Keychain Access.app.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Nov 4, 2015

edae31c commented

Thanks for this info.

However, I noticed that the ticket has been closed. Cyberduck saves too much information by default and in some cases there is no way to deactivate such functionality.

I'd suggest to take a second look at the following:

  • The option to save the password, which exists in the dialog that asks for the credentials, should be unchecked by default.
  • The username should not be auto-saved, unless the user has explicitly added it in the bookmark settings.
  • There should be an option (and command line switch whenever the cli interface is improved on the GUI app) to deactivate saving history.
  • You should consider disabling the "Use Keychain" option by default.

Thanks in advance.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Nov 4, 2015

edae31c commented

I see, \AppData\Roaming\iterate_GmbH\. Well, this is really hard to guess, especially from the moment that there is a separate \Roaming\Cyberduck directory.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 12, 2018

1bb2969 commented

Sorry to add a comment to this closed ticket. IMO, I like the nudge to save the password in the system keychain, so I have no complaint with that. Our problem, however, is that we have users who enter an incorrect passphrase when using key-based authentication, and this passphrase is then being saved to their keychain. The next time they try to connect, the stored passphrase is tried, and when it fails, Cyberduck falls back to password-based authentication which we do not permit on our server. The user then becomes confused, because it is not obvious what is happening.

This isn't too bad on OS X, but is much more problematic on Windows since many Windows users do not know how to edit their system keychain.

Is it possible that Cyberduck is saving the passphrase even when it fails to connect (that is what appears to be happening)? If so, while not a bug, I would categorize that as misbehavior, and would suggest that it be changed so that the passphrase (when using key-based authentication) is only stored if the subsequent connection is successful.

Thanks very much.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Aug 12, 2018

@dkocher commented

Replying to [comment:7 pschumm]:

This isn't too bad on OS X, but is much more problematic on Windows since many Windows users do not know how to edit their system keychain.

In later versions on Windows, passwords are saved in the Credential Manager. You can view and delete your saved login information in Control Panel → User Accounts → Credential Manager → Windows Credentials.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Oct 30, 2018

1bb2969 commented

I'm coming back to this because we continue to have problems with users who enter their passphrase incorrectly the first time they try to connect. On both OS X and Windows, Cyberduck appears to save the passphrase (if the user has checked the box to do so) even if the connection attempt is unsuccessful. This creates a problem when the user tries to connect again—the stored passphrase is then tried and fails (since it is incorrect), and Cyberduck automatically falls back to password authentication (which we do not permit for security reasons). Although a savvy user may figure out what's going on and can delete the stored passphrase as described in the thread above, the average user simply perceives that he or she is unable to connect, despite having followed our instructions for setting up key-based authentication. Of course, users should remember their passphrase and type it correctly, but many simply don't.

In sum, I believe that when using key-based authentication, Cyberduck should not store a user's passphrase in the system keychain until the connection has been successfully established. This would avoid storing an incorrect passphrase, which can then cause confusion on the part of the user. I believe that this is the standard behavior for web browsers that store credentials.

If you would like me to create a new ticket for this, please let me know. Thanks very much.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Oct 30, 2018

@dkocher commented

Replying to [comment:9 pschumm]:

I'm coming back to this because we continue to have problems with users who enter their passphrase incorrectly the first time they try to connect. On both OS X and Windows, Cyberduck appears to save the passphrase (if the user has checked the box to do so) even if the connection attempt is unsuccessful. This creates a problem when the user tries to connect again—the stored passphrase is then tried and fails (since it is incorrect), and Cyberduck automatically falls back to password authentication (which we do not permit for security reasons). Although a savvy user may figure out what's going on and can delete the stored passphrase as described in the thread above, the average user simply perceives that he or she is unable to connect, despite having followed our instructions for setting up key-based authentication. Of course, users should remember their passphrase and type it correctly, but many simply don't.

In sum, I believe that when using key-based authentication, Cyberduck should not store a user's passphrase in the system keychain until the connection has been successfully established. This would avoid storing an incorrect passphrase, which can then cause confusion on the part of the user. I believe that this is the standard behavior for web browsers that store credentials.

If you would like me to create a new ticket for this, please let me know. Thanks very much.

Yes, please create a new ticket. We should only ever save passwords in the credential manager upon successful login.

@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.
Projects
None yet
Development

No branches or pull requests

1 participant