search

juju / charmstore-client

Client for charmstore.
Other
9 stars 22 forks source link

charm client accepts u/p/2fa at the command line #44

Open dpb1 opened 8 years ago

dpb1 commented 8 years ago

I felt pretty odd typing these things into a shell.

Why not use an auth mechansim like LP or many other web apps where I grant and revoke access from there?

As it is, I have no idea if these sensitive credentials were secured (no https logo telling me) in any way. I also don't know how to revoke them if I lose access to this system.

cmars commented 8 years ago

Opening a web browser might be convenient for some use cases, but in others it is a jarring experience that does not work correctly on all platforms, and still others, it's a blocker to being able to authenticate at all (no $DISPLAY).

Your password and 2FA credentials are only sent to Ubuntu SSO (https://login.ubuntu.com) over TLS, to establish an OAuth token which can only be used to authenticate you to the charmstore [edit: and related services]. This token is stored locally in your home directory.

Access may be reviewed (and revoked) by visiting https://login.ubuntu.com/+applications.

johnsca commented 8 years ago

Since charm is a developer-oriented command, and most developers should be familiar with OAuth and how it works, I don't agree with the "it's jarring" argument. We require an SSO account, so they're guaranteed to have used it at least once.

For the "it sometimes doesn't work" argument, couldn't we detect the cases where it won't or doesn't work and fall back gracefully? At the very least, we could make a command-line option to attempt the browser for the people who would rather use the more secure method. A third option would be to provide an easy way (or just well-documented way) to import a token that is obtained manually; perhaps charm login could just accept the token as params?

stub42 commented 8 years ago

We implemented the SSO, OpenID and oauth so we can build secure systems. Misusing oauth because it is more convenient that way lowers the security of the whole system; if one tool fails to validate the SSL certificate chain fully it shouldn't be possible to escalate that to root on unrelated systems. From my duplicate bug report on charm-tools:

Rather than redirect me to the SSO website where I can enter my password securely, 'charm login' instead requests I enter my password and posts it on my behalf to the SSO website. This requires me to trust charm-tools with my password, and the libraries it uses to correctly verify the chain of trust and refuse to continue if the SSL certificate is not valid (MITM attacks), and does not give me an opportunity to confirm the access level being requested. These are all reasons that the oauth protocol exists in the first place ("OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password.")

What should happen is it opens a browser window to the SSO website where I can login if necessary, do the 2fa dance if necessary, and confirm that I wish to grant the requested access.

urosj commented 8 years ago

@stub42 I agree with you that the default behaviour should open the browser as it used to. If you want to have pure CLI experience, we should support something like "charm login --no-browser". We can add this in one of the flowing releases.

johnsca commented 6 years ago

I don't know if this was ever implemented (I don't see the --no-browser option) or if it's not working now due to confinement (see juju/charm-tools#415). I do think it's at least being made worse by confinement because I think the tokens / macaroons are being cleared during snap upgrade (though of course that could also be fixed by using the proper $SNAP_* dirs).