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

dockercfg insecure #10318

Closed
rafaelhbarros opened this Issue Jan 23, 2015 · 62 comments

Comments

Projects
None yet
@rafaelhbarros

rafaelhbarros commented Jan 23, 2015

After a docker login, the CLI stores the password encoded in base64 in a file called dockercfg, and that is not entirely secure. I'd like to suggest changing that to keep either a token returned from the index, or another security mechanism to be implemented instead of saving passwords in plaintext.

This is particularly unsafe in case of open/shared workstations or in case the authentication happens against a custom index with higher security concerns about the password.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jan 23, 2015

Member

So many +1s; this has bothered me for a while.

As I mentioned in #10151 (comment), I'd be +1 to removing this file entirely in favor of using the new ~/.docker directory appropriately instead, but if fixing this particular issue required some transition, switching to a new file at the same time would be perfect timing to kill two birds with one stone IMO.

Member

tianon commented Jan 23, 2015

So many +1s; this has bothered me for a while.

As I mentioned in #10151 (comment), I'd be +1 to removing this file entirely in favor of using the new ~/.docker directory appropriately instead, but if fixing this particular issue required some transition, switching to a new file at the same time would be perfect timing to kill two birds with one stone IMO.

@nathanleclaire

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Jan 23, 2015

Contributor

Huge +1 to this issue and to @tianon comment.

Contributor

nathanleclaire commented Jan 23, 2015

Huge +1 to this issue and to @tianon comment.

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Jan 23, 2015

Contributor

+1 ugh base64

Contributor

jessfraz commented Jan 23, 2015

+1 ugh base64

@dmp42 dmp42 added the Distribution label Jan 23, 2015

@zfogg

This comment has been minimized.

Show comment
Hide comment
@zfogg

zfogg Jan 23, 2015

+1 wow, this should be top priority.

zfogg commented Jan 23, 2015

+1 wow, this should be top priority.

@daidoji

This comment has been minimized.

Show comment
Hide comment
@daidoji

daidoji commented Jan 23, 2015

+1

@pfultz2

This comment has been minimized.

Show comment
Hide comment
@pfultz2

pfultz2 Jan 23, 2015

+1

This is a pretty big deal. HTTPS might make basic http auth secure for network communications, but its not secure when the basic auth token(which is USER:PASSWORD with base64 encoding) is stored on the machine.

pfultz2 commented Jan 23, 2015

+1

This is a pretty big deal. HTTPS might make basic http auth secure for network communications, but its not secure when the basic auth token(which is USER:PASSWORD with base64 encoding) is stored on the machine.

@netroby

This comment has been minimized.

Show comment
Hide comment
@netroby

netroby Jan 24, 2015

And we should migrate the current dockercfg into new .docker file if we would like to made this change.

netroby commented Jan 24, 2015

And we should migrate the current dockercfg into new .docker file if we would like to made this change.

@SEJeff

This comment has been minimized.

Show comment
Hide comment
@SEJeff

SEJeff Jan 24, 2015

There isn't really a need for everyone to +1 this, just subscribe to this issue with the subscribe button to the right. That being said, clear text in the file is a very poor design.

For tokens, perhaps json web tokens would work? I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

The way django-rest-framework does json tokens it is pretty decent IMO. They require passing the token with a header like:

Authorization: Token {TOKEN_VALUE_HERE}

SEJeff commented Jan 24, 2015

There isn't really a need for everyone to +1 this, just subscribe to this issue with the subscribe button to the right. That being said, clear text in the file is a very poor design.

For tokens, perhaps json web tokens would work? I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

The way django-rest-framework does json tokens it is pretty decent IMO. They require passing the token with a header like:

Authorization: Token {TOKEN_VALUE_HERE}
@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jan 24, 2015

Collaborator

Hi all, this is a known issue and the distribution maintainers are working on rolling out token-based auth. Meanwhile there is work underway to switch to keypair-based authentication and authorization for all components of Docker, including but not limited the registry.

Ping @dmp42 @dmcgowan @jlhawn

Collaborator

shykes commented Jan 24, 2015

Hi all, this is a known issue and the distribution maintainers are working on rolling out token-based auth. Meanwhile there is work underway to switch to keypair-based authentication and authorization for all components of Docker, including but not limited the registry.

Ping @dmp42 @dmcgowan @jlhawn

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jan 24, 2015

Collaborator

I suppose a few haters are already busy writing another vitriolic blog post... Yes, storing user credentials in plaintext, even with proper permissions, is not ideal, and as explained above we are working on something better. But it's not unheard of, either: see for example .netrc from the standard gnu toolchain: http://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-File.html

A reminder: one way or the other, you'll still need to store some private credential on your machine, and who can access them on the filesystem will still be crucially important. The reason passwords are worse than private keys in that regard is that they are more likely to be re-used across domains and tools, and can't be additionally protected by a passphrase.

Collaborator

shykes commented Jan 24, 2015

I suppose a few haters are already busy writing another vitriolic blog post... Yes, storing user credentials in plaintext, even with proper permissions, is not ideal, and as explained above we are working on something better. But it's not unheard of, either: see for example .netrc from the standard gnu toolchain: http://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-File.html

A reminder: one way or the other, you'll still need to store some private credential on your machine, and who can access them on the filesystem will still be crucially important. The reason passwords are worse than private keys in that regard is that they are more likely to be re-used across domains and tools, and can't be additionally protected by a passphrase.

@pfultz2

This comment has been minimized.

Show comment
Hide comment
@pfultz2

pfultz2 Jan 24, 2015

But it's not unheard of, either: see for example .netrc from the standard gnu toolchain

Thats not really the same thing. The .netrc file lets you optionally store the password in a file, plus, the password is for a protocol that is entirely insecure as well(ie it sends the password over the network in plaintext). Should we assume that docker is insecure like the telnet protocol?

pfultz2 commented Jan 24, 2015

But it's not unheard of, either: see for example .netrc from the standard gnu toolchain

Thats not really the same thing. The .netrc file lets you optionally store the password in a file, plus, the password is for a protocol that is entirely insecure as well(ie it sends the password over the network in plaintext). Should we assume that docker is insecure like the telnet protocol?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 24, 2015

Member

I hope this gets top priority to find a better alternative;

For the 1.5 release (I know it's in freeze, but to prevent negative reports); at least output a message that the password will be stored as (what I consider to be) plain text. As an example, this is what SVN will output;

ATTENTION! Your password for authentication realm:

http://domainname.com:80 “domainname.com”

can only be stored to disk unencrypted! You are advised to configure your system 
so that Subversion can store passwords encrypted, if possible. See the 
documentation for details. You can avoid future appearances of this warning by 
setting the value of the 'store-plaintext-passwords' option to either 'yes' 
or 'no' in '/root/.subversion/servers'.

Store password unencrypted (yes/no)? no

The warning should also mention where the password is stored, allowing people
to remove the stored password afterwards.

I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

I don't know if this is what's currently happening, but if these tokens are actually included in the logs on the registry, that's a serious issue. If a registry server gets compromised, all passwords are in the open. If possible, something should be put in place to scrub that data from the logs, also going back to existing logs (and backups).

For a future release, I really hope for a per-host token, including a way to revoke tokens from within the registry control-panel. That gives users control over each host that has access to the registry, eve if they don't have access to that host itself.

Once a new system is in place, people should be notified to reset their password, in case dockercfg are left behind on hosts where they have logged in in the past.

Member

thaJeztah commented Jan 24, 2015

I hope this gets top priority to find a better alternative;

For the 1.5 release (I know it's in freeze, but to prevent negative reports); at least output a message that the password will be stored as (what I consider to be) plain text. As an example, this is what SVN will output;

ATTENTION! Your password for authentication realm:

http://domainname.com:80 “domainname.com”

can only be stored to disk unencrypted! You are advised to configure your system 
so that Subversion can store passwords encrypted, if possible. See the 
documentation for details. You can avoid future appearances of this warning by 
setting the value of the 'store-plaintext-passwords' option to either 'yes' 
or 'no' in '/root/.subversion/servers'.

Store password unencrypted (yes/no)? no

The warning should also mention where the password is stored, allowing people
to remove the stored password afterwards.

I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

I don't know if this is what's currently happening, but if these tokens are actually included in the logs on the registry, that's a serious issue. If a registry server gets compromised, all passwords are in the open. If possible, something should be put in place to scrub that data from the logs, also going back to existing logs (and backups).

For a future release, I really hope for a per-host token, including a way to revoke tokens from within the registry control-panel. That gives users control over each host that has access to the registry, eve if they don't have access to that host itself.

Once a new system is in place, people should be notified to reset their password, in case dockercfg are left behind on hosts where they have logged in in the past.

@sardaukar

This comment has been minimized.

Show comment
Hide comment
@sardaukar

sardaukar Jan 25, 2015

No wonder people are jumping ship to other projects - the passive-aggressive is strong with @shykes in this thread :/

sardaukar commented Jan 25, 2015

No wonder people are jumping ship to other projects - the passive-aggressive is strong with @shykes in this thread :/

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

@sardaukar I don't think it's fair to directly jump to conclusions here; also, you need to be logged in to a host in order to have access to that file. If you're logged in to the host, you'll also have access to all your private keys, and I don't think anyone has a problem with that?

The registry logging is something that I would like to have confirmed but until that becomes clear, please don't draw conclusions and start spreading rumours that have not been confirmed.

Member

thaJeztah commented Jan 25, 2015

@sardaukar I don't think it's fair to directly jump to conclusions here; also, you need to be logged in to a host in order to have access to that file. If you're logged in to the host, you'll also have access to all your private keys, and I don't think anyone has a problem with that?

The registry logging is something that I would like to have confirmed but until that becomes clear, please don't draw conclusions and start spreading rumours that have not been confirmed.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

I just had a short chat with @shykes on IRC; he's famously bad at responding to issues like this and decided to not respond further to prevent posting foolish comments 😄

He also thought that the distribution team (@dmp42 @stevvooe @dmcgowan @jlhawn) should be able to provide more information on progress on this issue and provide answers to some of the questions being raised here (wrt the registry, logging?).

I know a lot of work is currently going on with changes to the registry (V2) (see the distribution repository) including the way the docker daemon communicates with the registry (a complete new API), so chances are this is a thing of the past soon.

Member

thaJeztah commented Jan 25, 2015

I just had a short chat with @shykes on IRC; he's famously bad at responding to issues like this and decided to not respond further to prevent posting foolish comments 😄

He also thought that the distribution team (@dmp42 @stevvooe @dmcgowan @jlhawn) should be able to provide more information on progress on this issue and provide answers to some of the questions being raised here (wrt the registry, logging?).

I know a lot of work is currently going on with changes to the registry (V2) (see the distribution repository) including the way the docker daemon communicates with the registry (a complete new API), so chances are this is a thing of the past soon.

@dmcgowan

This comment has been minimized.

Show comment
Hide comment
@dmcgowan

dmcgowan Jan 25, 2015

Member

@thaJeztah you are right, this will soon be a thing of the past. We cannot simply rip this out since many users are relying on it, but we are adding the building blocks to replace it in 1.5. This includes adding a public key identity to the client and a new authorization server for the registry which relies on token authentication and will soon be able to be authenticated using the public key identity. The initial version will continue to use basic auth credentials with added public key support once the authorization server has seen more use. PTAL at #9081 for the proposal of how authentication now works with the registry.

Another possible short term solution is now that we have the public key identity of the client, we can use the key pair to encrypt the dockercfg file. It is worthy of a proposal.

As for the logging mentioned, is this referring to adding a warning when storing the user's credentials in plain text? It is worth generating a PR to discuss, I think it sounds reasonable to address a real concern.

Member

dmcgowan commented Jan 25, 2015

@thaJeztah you are right, this will soon be a thing of the past. We cannot simply rip this out since many users are relying on it, but we are adding the building blocks to replace it in 1.5. This includes adding a public key identity to the client and a new authorization server for the registry which relies on token authentication and will soon be able to be authenticated using the public key identity. The initial version will continue to use basic auth credentials with added public key support once the authorization server has seen more use. PTAL at #9081 for the proposal of how authentication now works with the registry.

Another possible short term solution is now that we have the public key identity of the client, we can use the key pair to encrypt the dockercfg file. It is worthy of a proposal.

As for the logging mentioned, is this referring to adding a warning when storing the user's credentials in plain text? It is worth generating a PR to discuss, I think it sounds reasonable to address a real concern.

@sardaukar

This comment has been minimized.

Show comment
Hide comment
@sardaukar

sardaukar Jan 25, 2015

@thaJeztah not jumping too much, just mirroring the mood from Reddit (www.reddit.com/r/programming/comments/2tga5a/docker_stores_usernamepasswords_in_essentially/) :/ comments like these are not cool

sardaukar commented Jan 25, 2015

@thaJeztah not jumping too much, just mirroring the mood from Reddit (www.reddit.com/r/programming/comments/2tga5a/docker_stores_usernamepasswords_in_essentially/) :/ comments like these are not cool

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

@dmcgowan wrt the logging; concerns were raised if the authentication being sent the way they are now end up in log-files on the registry-servers. I don't think that's the case, but the possibility was raised here #10318 (comment).

Member

thaJeztah commented Jan 25, 2015

@dmcgowan wrt the logging; concerns were raised if the authentication being sent the way they are now end up in log-files on the registry-servers. I don't think that's the case, but the possibility was raised here #10318 (comment).

@dmcgowan

This comment has been minimized.

Show comment
Hide comment
@dmcgowan

dmcgowan Jan 25, 2015

Member

@thaJeztah basic authentication is not handled directly by registry. In the case of private registries it is handled by the proxy (nginx, haproxy) and the v1 public registry uses an index to issue tokens as described in #9081. I can confirm there is no possibility of the username/password getting logged in the new v2 registry, I am not as familiar with the v1 codebase but I can let @dmp42 confirm it is not.

Member

dmcgowan commented Jan 25, 2015

@thaJeztah basic authentication is not handled directly by registry. In the case of private registries it is handled by the proxy (nginx, haproxy) and the v1 public registry uses an index to issue tokens as described in #9081. I can confirm there is no possibility of the username/password getting logged in the new v2 registry, I am not as familiar with the v1 codebase but I can let @dmp42 confirm it is not.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

@dmcgowan thanks for the additional info. I'm interested to hear from @dmp42 for a final confirmation.

Member

thaJeztah commented Jan 25, 2015

@dmcgowan thanks for the additional info. I'm interested to hear from @dmp42 for a final confirmation.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

@sardaukar thanks for that link, yes, that was to be expected.

It always makes me sad that, apparently, this is the world we live in. I understand that Solomon (being the "Steve Jobs" of Docker) will be watched closely and anything he says will be used both to praise Docker and to discredit Docker if people get the opportunity.

However, Docker is more than just Solomon (in fact, most of the time nowadays he's quite absent in this repository, probably because of other obligations). Most people working on the project are not even related to Docker (inc.) and a huge majority of the contributors is doing this in their spare time, just to "give back" to the project.

Over the (almost) two years I've been following this project, I've seen all kind of contributions, ranging from fixing typos to major changes in networking to support IPv6. I've seen people being really patient, trying to explain to absolute "Git newbies" how to clone a repository and do a rebase or amend a commit. At the same time, having to keep track of almost 900 open issues, feature requests and support questions, not to mention answering question on IRC and the mailing lists.

Does that make it right to have issues like this one? Nope, it shouldn't happen. It also shouldn't be taken out of proportion; like I mentioned in an earlier comment; SSH keys (as an example) are also accessible if you're logged in. That's not a problem, but people should be made aware that this is the case.

I also think that any developer will admit that looking at your TO-DO list, you'd rather pick working on "that new feature" than the less fun stuff. Replacing .dockercfg with something better has just been on the TO-DO list for too long.

Having said that; (see #10318 (comment)) People on the distribution team are actively working on this (regarded by many as) "un-cool" feature, and it will be replaced with something way better in the near future.

In the mean time, just take the regular precautions; don't give (untrusted) people access to your computer/account, change your (docker) passwords frequently, and monitor access.

Finally, to stop rumours up front; No, I am not affiliated with Docker, have not been asked or paid by docker to write this. I use Docker at work (and for fun), and contribute (where possible) in my spare time and during my daily travel to/from work (standing on the train, typing...).

Just wanted to get it off my chest 😄

Member

thaJeztah commented Jan 25, 2015

@sardaukar thanks for that link, yes, that was to be expected.

It always makes me sad that, apparently, this is the world we live in. I understand that Solomon (being the "Steve Jobs" of Docker) will be watched closely and anything he says will be used both to praise Docker and to discredit Docker if people get the opportunity.

However, Docker is more than just Solomon (in fact, most of the time nowadays he's quite absent in this repository, probably because of other obligations). Most people working on the project are not even related to Docker (inc.) and a huge majority of the contributors is doing this in their spare time, just to "give back" to the project.

Over the (almost) two years I've been following this project, I've seen all kind of contributions, ranging from fixing typos to major changes in networking to support IPv6. I've seen people being really patient, trying to explain to absolute "Git newbies" how to clone a repository and do a rebase or amend a commit. At the same time, having to keep track of almost 900 open issues, feature requests and support questions, not to mention answering question on IRC and the mailing lists.

Does that make it right to have issues like this one? Nope, it shouldn't happen. It also shouldn't be taken out of proportion; like I mentioned in an earlier comment; SSH keys (as an example) are also accessible if you're logged in. That's not a problem, but people should be made aware that this is the case.

I also think that any developer will admit that looking at your TO-DO list, you'd rather pick working on "that new feature" than the less fun stuff. Replacing .dockercfg with something better has just been on the TO-DO list for too long.

Having said that; (see #10318 (comment)) People on the distribution team are actively working on this (regarded by many as) "un-cool" feature, and it will be replaced with something way better in the near future.

In the mean time, just take the regular precautions; don't give (untrusted) people access to your computer/account, change your (docker) passwords frequently, and monitor access.

Finally, to stop rumours up front; No, I am not affiliated with Docker, have not been asked or paid by docker to write this. I use Docker at work (and for fun), and contribute (where possible) in my spare time and during my daily travel to/from work (standing on the train, typing...).

Just wanted to get it off my chest 😄

@TheDong

This comment has been minimized.

Show comment
Hide comment
@TheDong

TheDong Jan 25, 2015

@thaJeztah comparing this to ssh or netrc is disingenuous. If someone has physical access to my computer, they do not in fact have access to my ssh keys because they're encrypted and ssh understands to prompt me for a password for them. Someone can have root on my machine, and they still won't have my ssh credentials. I can temporarily decrypt them only in memory with ssh-agent + ssh-add for convenience of course. netrc is totally optional... with docker, even if you just "push" or "pull" a private repo, not explicitly type login, it still saves the credentials. There's no way to tell docker to encrypt them or not store them on disk. You still can't force a registry to be v2 only (they do that for the IndexServer, but for any other if someone MITM's the /v2/_ping, it'll fallback to plaintext). SSH allows pinning known hosts, setting allowed ciphers per server, etc etc etc... These things shouldn't be compared as even being in the same ballpark.

In your comment you say "It also shouldn't be taken out of proportion", and that's true, but saying that it's being taken out of proportion now shows a deep lack of understanding of how security works.

So yes, this issue should not be taken out of proportion and, imo, isn't. If anything, it's under proportioned. Hardly anyone is discussing how the keys are being sent as plaintext over the wire (thank gosh registries have to be https or --insecure-registry now), how little the daemon actually allows in terms of verification or security configuration, and how the v2 registry doesn't even solve most of these problems.

Perhaps part of the reason this happened is because docker is such a friendly project. Even for security sensitive things, early on, there was no need for a proposal or discussion, you just did it. I'm hopeful rocket, with their carefully made specifications, will cover this sort of critical scenario. I'm also hopeful that they'll not just say "it's not a big deal" when talking about severe security flaws.

TheDong commented Jan 25, 2015

@thaJeztah comparing this to ssh or netrc is disingenuous. If someone has physical access to my computer, they do not in fact have access to my ssh keys because they're encrypted and ssh understands to prompt me for a password for them. Someone can have root on my machine, and they still won't have my ssh credentials. I can temporarily decrypt them only in memory with ssh-agent + ssh-add for convenience of course. netrc is totally optional... with docker, even if you just "push" or "pull" a private repo, not explicitly type login, it still saves the credentials. There's no way to tell docker to encrypt them or not store them on disk. You still can't force a registry to be v2 only (they do that for the IndexServer, but for any other if someone MITM's the /v2/_ping, it'll fallback to plaintext). SSH allows pinning known hosts, setting allowed ciphers per server, etc etc etc... These things shouldn't be compared as even being in the same ballpark.

In your comment you say "It also shouldn't be taken out of proportion", and that's true, but saying that it's being taken out of proportion now shows a deep lack of understanding of how security works.

So yes, this issue should not be taken out of proportion and, imo, isn't. If anything, it's under proportioned. Hardly anyone is discussing how the keys are being sent as plaintext over the wire (thank gosh registries have to be https or --insecure-registry now), how little the daemon actually allows in terms of verification or security configuration, and how the v2 registry doesn't even solve most of these problems.

Perhaps part of the reason this happened is because docker is such a friendly project. Even for security sensitive things, early on, there was no need for a proposal or discussion, you just did it. I'm hopeful rocket, with their carefully made specifications, will cover this sort of critical scenario. I'm also hopeful that they'll not just say "it's not a big deal" when talking about severe security flaws.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 25, 2015

Member

@TheDong I apologise for using SSH keys as an example, my main point was to illustrate "there's more that can be found when you are able to get (physical) access to ones computer/account".

I fully agree that more options should be provided wrt storing credentials (as stated in my earlier comments), and according to earlier statements, work is being done to accommodate that.

Wrt communication with privately hosted registries; I guess that really depends on how those are configured. I've seen many requests from people that saw "no need" to use TLS/SSL (or even authentication) for an in-house registry on their private network. Having said that, I'm really not an expert on setting up and configuring those.

I'm also hopeful that Mercedes Benz, with their expert design team will make their new model a lot safer and Eco-friendly than the current version. But I saw no reason to mention that in my earlier comment.

Member

thaJeztah commented Jan 25, 2015

@TheDong I apologise for using SSH keys as an example, my main point was to illustrate "there's more that can be found when you are able to get (physical) access to ones computer/account".

I fully agree that more options should be provided wrt storing credentials (as stated in my earlier comments), and according to earlier statements, work is being done to accommodate that.

Wrt communication with privately hosted registries; I guess that really depends on how those are configured. I've seen many requests from people that saw "no need" to use TLS/SSL (or even authentication) for an in-house registry on their private network. Having said that, I'm really not an expert on setting up and configuring those.

I'm also hopeful that Mercedes Benz, with their expert design team will make their new model a lot safer and Eco-friendly than the current version. But I saw no reason to mention that in my earlier comment.

@dmp42

This comment has been minimized.

Show comment
Hide comment
@dmp42

dmp42 Jan 26, 2015

Contributor

All,

Thanks a lot for the feedback on this.

A couple of words:

  • the current situation with dockercfg is not ideal, and we are well aware of that
  • we are currently working on it
  • using keys a-la-ssh is certainly something we are considering (and/or retrieving credentials from a keystore)
  • JWT are (already) used as part of the v2 protocol: https://github.com/docker/distribution/tree/fdea60af05c0b46026b81d8df49d53017661bd72/auth/token and will be the recommended workflow in the future
  • the discussions on authn/authz against the registry are being held in the open, on irc (weekly distribution meeting is monday morning 10AM) and on github. "distribution" maintainers definitely welcome feedback and constructive discussion
    • specifically the question of basic auth and the use of reverse proxies: docker/docker-registry#623
    • JWT based auth proposal: #9081
    • auth as part of the new registry protocol: #9015
  • a couple of things need to be set straight with regard to the discussion so far:
    • the registry does not dump plain text credentials into log files
    • the registry never sees plain text credentials (though an index or reverse proxy does)
    • tokens are sent in headers, not in urls

To sum this:

  • sure, things need to be fixed
  • there is an open effort in doing that (#distribution), and people are certainly welcome to join if they want - either way, the issue here is definitely something being worked on
  • we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

While this answer is not "a fix", I hope it will help.

Contributor

dmp42 commented Jan 26, 2015

All,

Thanks a lot for the feedback on this.

A couple of words:

  • the current situation with dockercfg is not ideal, and we are well aware of that
  • we are currently working on it
  • using keys a-la-ssh is certainly something we are considering (and/or retrieving credentials from a keystore)
  • JWT are (already) used as part of the v2 protocol: https://github.com/docker/distribution/tree/fdea60af05c0b46026b81d8df49d53017661bd72/auth/token and will be the recommended workflow in the future
  • the discussions on authn/authz against the registry are being held in the open, on irc (weekly distribution meeting is monday morning 10AM) and on github. "distribution" maintainers definitely welcome feedback and constructive discussion
    • specifically the question of basic auth and the use of reverse proxies: docker/docker-registry#623
    • JWT based auth proposal: #9081
    • auth as part of the new registry protocol: #9015
  • a couple of things need to be set straight with regard to the discussion so far:
    • the registry does not dump plain text credentials into log files
    • the registry never sees plain text credentials (though an index or reverse proxy does)
    • tokens are sent in headers, not in urls

To sum this:

  • sure, things need to be fixed
  • there is an open effort in doing that (#distribution), and people are certainly welcome to join if they want - either way, the issue here is definitely something being worked on
  • we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

While this answer is not "a fix", I hope it will help.

@rafaelhbarros

This comment has been minimized.

Show comment
Hide comment
@rafaelhbarros

rafaelhbarros Jan 26, 2015

@dmp42 I'm glad to see so much traction on this issue and that you're already working on it. Thanks for the clarification on all the issues raised and status update.

rafaelhbarros commented Jan 26, 2015

@dmp42 I'm glad to see so much traction on this issue and that you're already working on it. Thanks for the clarification on all the issues raised and status update.

@mmdriley

This comment has been minimized.

Show comment
Hide comment
@mmdriley

mmdriley Jan 26, 2015

Contributor

What are the threats we want to protect against here?

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent. The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

I see one interesting attack here: if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

Docker has made some security decisions I would call questionable (looking at you, tarsum) but this isn't one of them.

Contributor

mmdriley commented Jan 26, 2015

What are the threats we want to protect against here?

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent. The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

I see one interesting attack here: if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

Docker has made some security decisions I would call questionable (looking at you, tarsum) but this isn't one of them.

@pfultz2

This comment has been minimized.

Show comment
Hide comment
@pfultz2

pfultz2 Jan 26, 2015

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent.

Yes, but for security reasons, I would like to perform authenticated commands by entering a password everytime.(just like git and mercurial).

Also, storing session tokens instead of a password allows for stricter security policies whereas requiring users to change their passwords everyday is not feasible.

The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

For private repos, the account could give you more access to services other than docker. Token based authentication allows the session to be limited to certain services, and for a certain time.

if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

When you login with Pidgin they never store the password, unless you explicitly say so; unlike docker which always stores that password, with no option to opt-out.

pfultz2 commented Jan 26, 2015

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent.

Yes, but for security reasons, I would like to perform authenticated commands by entering a password everytime.(just like git and mercurial).

Also, storing session tokens instead of a password allows for stricter security policies whereas requiring users to change their passwords everyday is not feasible.

The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

For private repos, the account could give you more access to services other than docker. Token based authentication allows the session to be limited to certain services, and for a certain time.

if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

When you login with Pidgin they never store the password, unless you explicitly say so; unlike docker which always stores that password, with no option to opt-out.

@dmp42

This comment has been minimized.

Show comment
Hide comment
@dmp42

dmp42 Jan 26, 2015

Contributor

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

You DO NEED the old password to change password on the hub.

Contributor

dmp42 commented Jan 26, 2015

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

You DO NEED the old password to change password on the hub.

@tiborvass

This comment has been minimized.

Show comment
Hide comment
@tiborvass

tiborvass Jan 26, 2015

Collaborator

Also, in case anyone finds a security vulnerability, please be responsible and send an email to security@docker.com as explained here: https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-security-issues

Collaborator

tiborvass commented Jan 26, 2015

Also, in case anyone finds a security vulnerability, please be responsible and send an email to security@docker.com as explained here: https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-security-issues

@mmdriley

This comment has been minimized.

Show comment
Hide comment
@mmdriley

mmdriley Jan 26, 2015

Contributor

I would like to perform authenticated commands by entering a password everytime

I agree this is a use case worth supporting. The initial auth could return a time-restricted, possibly-revocable token. (For example, it should be invalidated if your Docker Hub password changes.) The client will need fallback code for when that token expires or becomes invalid.

This seems like a much simpler response to a much more obvious threat than most of the discussion above.

You DO NEED the old password to change password on the hub.

Ack, yes, definitely. Sorry for my ambiguous wording before.

Contributor

mmdriley commented Jan 26, 2015

I would like to perform authenticated commands by entering a password everytime

I agree this is a use case worth supporting. The initial auth could return a time-restricted, possibly-revocable token. (For example, it should be invalidated if your Docker Hub password changes.) The client will need fallback code for when that token expires or becomes invalid.

This seems like a much simpler response to a much more obvious threat than most of the discussion above.

You DO NEED the old password to change password on the hub.

Ack, yes, definitely. Sorry for my ambiguous wording before.

@rafaelhbarros

This comment has been minimized.

Show comment
Hide comment
@rafaelhbarros

rafaelhbarros Jan 26, 2015

@mmdriley One issue that was raised before and it's bothering me is in the case of CI/CD servers.

It would nice to setup the servers to have read only access, instead of saving the account info in a text file. I want something analogous to the github deploy key. The solution to this would be to create a 3rd account with read-only access to a private repo and keeping that info on the deploy server, but that is not an ideal design.

rafaelhbarros commented Jan 26, 2015

@mmdriley One issue that was raised before and it's bothering me is in the case of CI/CD servers.

It would nice to setup the servers to have read only access, instead of saving the account info in a text file. I want something analogous to the github deploy key. The solution to this would be to create a 3rd account with read-only access to a private repo and keeping that info on the deploy server, but that is not an ideal design.

@mgk

This comment has been minimized.

Show comment
Hide comment
@mgk

mgk Jan 26, 2015

Glad to see this is being taken seriously. The planned use of JWTs and SSH key pairs looks great.

we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

Makes good sense. In the meantime making sure users are aware of the risk is important. As a user I'm happy wait for the right solution and take steps to mitigate security weaknesses, but I need to know what they are to do that.

I second the suggestion by @thaJeztah: docker login v1 should inform the user that it is saving their unencrypted creds to ~/.dockercfg.

mgk commented Jan 26, 2015

Glad to see this is being taken seriously. The planned use of JWTs and SSH key pairs looks great.

we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

Makes good sense. In the meantime making sure users are aware of the risk is important. As a user I'm happy wait for the right solution and take steps to mitigate security weaknesses, but I need to know what they are to do that.

I second the suggestion by @thaJeztah: docker login v1 should inform the user that it is saving their unencrypted creds to ~/.dockercfg.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 26, 2015

Member

I created a separate ticket for outputting a message / confirmation here; #10338 hoping that is possible to get into 1.5

Member

thaJeztah commented Jan 26, 2015

I created a separate ticket for outputting a message / confirmation here; #10338 hoping that is possible to get into 1.5

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Jan 27, 2015

Contributor

Ideally we should store encrypted keys/tokens and have an agent manager ala gpg-agent and ssh-agent to manage these. I'd prefer it actually be one of those tools, actually, rather than inventing a new one that does less, worse.

I had already suggested to @dmp42 that we use Digest authentication and store the digest. It wouldn't prevent users from stealing the secret, but it would prevent theft of the password itself. I still think this would be appropriate, if only a marginal improvement for v1 while the v2 api settles in.

Contributor

ewindisch commented Jan 27, 2015

Ideally we should store encrypted keys/tokens and have an agent manager ala gpg-agent and ssh-agent to manage these. I'd prefer it actually be one of those tools, actually, rather than inventing a new one that does less, worse.

I had already suggested to @dmp42 that we use Digest authentication and store the digest. It wouldn't prevent users from stealing the secret, but it would prevent theft of the password itself. I still think this would be appropriate, if only a marginal improvement for v1 while the v2 api settles in.

@dmp42

This comment has been minimized.

Show comment
Hide comment
@dmp42

dmp42 Jan 27, 2015

Contributor

@ewindisch: storing a HA1 is almost as bad as storing a password (MD5(username:realm:password)) and only provides a false sense of security.

Contributor

dmp42 commented Jan 27, 2015

@ewindisch: storing a HA1 is almost as bad as storing a password (MD5(username:realm:password)) and only provides a false sense of security.

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Jan 27, 2015

Contributor

@dmp42 as I said, storing the MD5 is only a marginal improvement as it only prevents revelation of the password, but not revelation of a secret. Given that the Index API now allows password and email changes, which I believe is relatively new(??), I suppose it's moot.

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

Contributor

ewindisch commented Jan 27, 2015

@dmp42 as I said, storing the MD5 is only a marginal improvement as it only prevents revelation of the password, but not revelation of a secret. Given that the Index API now allows password and email changes, which I believe is relatively new(??), I suppose it's moot.

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

@jefflaporte

This comment has been minimized.

Show comment
Hide comment
@jefflaporte

jefflaporte Jan 27, 2015

Big +1. As it currently operates users like us operating private registries can't integrate into LDAP without potentially compromising network-wide passwords.

jefflaporte commented Jan 27, 2015

Big +1. As it currently operates users like us operating private registries can't integrate into LDAP without potentially compromising network-wide passwords.

@arnauldvm

This comment has been minimized.

Show comment
Hide comment
@arnauldvm

arnauldvm commented May 22, 2015

+1

@pkill

This comment has been minimized.

Show comment
Hide comment
@pkill

pkill commented Jun 2, 2015

👍

@pfortuna

This comment has been minimized.

Show comment
Hide comment
@pfortuna

pfortuna Jul 17, 2015

+1 on using revocable host tokens

pfortuna commented Jul 17, 2015

+1 on using revocable host tokens

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Jul 18, 2015

Contributor

Another important aspect here is that by using Digest auth, which specifies realms in the auth header, we can eliminate cross-registry attacks if the user/pass were the same on multiple registries and was somehow sniffed or stolen from an attacked registry.

Contributor

ewindisch commented Jul 18, 2015

Another important aspect here is that by using Digest auth, which specifies realms in the auth header, we can eliminate cross-registry attacks if the user/pass were the same on multiple registries and was somehow sniffed or stolen from an attacked registry.

@mmdriley

This comment has been minimized.

Show comment
Hide comment
@mmdriley

mmdriley Jul 22, 2015

Contributor

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

Contributor

mmdriley commented Jul 22, 2015

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

@HuKeping

This comment has been minimized.

Show comment
Hide comment
@HuKeping

HuKeping Aug 10, 2015

Contributor

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

+1 for caching it in memory. The disadvantage is that you need to re-enter the password everytime Docker daemon restart.

Contributor

HuKeping commented Aug 10, 2015

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

+1 for caching it in memory. The disadvantage is that you need to re-enter the password everytime Docker daemon restart.

@HuKeping

This comment has been minimized.

Show comment
Hide comment
@HuKeping

HuKeping Aug 11, 2015

Contributor

So what is the most possible solution that Docker prefer or is there anything that WIP? ping @thaJeztah @dmp42 @tiborvass @dmcgowan @stevvooe

Contributor

HuKeping commented Aug 11, 2015

So what is the most possible solution that Docker prefer or is there anything that WIP? ping @thaJeztah @dmp42 @tiborvass @dmcgowan @stevvooe

@joozek78

This comment has been minimized.

Show comment
Hide comment
@joozek78

joozek78 Oct 5, 2015

Did I miss something or are passwords still stored in cleartext after 10 months (from discovery)?

joozek78 commented Oct 5, 2015

Did I miss something or are passwords still stored in cleartext after 10 months (from discovery)?

@rafaelhbarros

This comment has been minimized.

Show comment
Hide comment
@rafaelhbarros

rafaelhbarros Oct 5, 2015

Still clear text.

rafaelhbarros commented Oct 5, 2015

Still clear text.

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch
Contributor

ewindisch commented Oct 5, 2015

@HuKeping

This comment has been minimized.

Show comment
Hide comment
@HuKeping

HuKeping Oct 10, 2015

Contributor

We can use symmetric-key algorithm, like AES to encrypt it. But it'll still need to store some private credential on the machine say, the key. It doesn't make much sense.

Contributor

HuKeping commented Oct 10, 2015

We can use symmetric-key algorithm, like AES to encrypt it. But it'll still need to store some private credential on the machine say, the key. It doesn't make much sense.

@cheungpat

This comment has been minimized.

Show comment
Hide comment
@cheungpat

cheungpat Oct 10, 2015

The problem seems to be that we need to use Docker Hub password to log in and this password has to be saved in dockercfg no matter plaintext or encrypted.

To solve this problem is not to find a secure way to store Docker Hub password, but for Docker Hub to accept some kind of deploy token that we can use to login instead of using Docker Hub password.

Supposedly the deploy token can only be used to pull images (or push as well), therefore the deploy token cannot do everything the Docker Hub password can do.

This will work similar to Google Account multi-factor authentication and app-specific password for those apps that don’t support it.

Sorry if solution like this was discussed before.

cheungpat commented Oct 10, 2015

The problem seems to be that we need to use Docker Hub password to log in and this password has to be saved in dockercfg no matter plaintext or encrypted.

To solve this problem is not to find a secure way to store Docker Hub password, but for Docker Hub to accept some kind of deploy token that we can use to login instead of using Docker Hub password.

Supposedly the deploy token can only be used to pull images (or push as well), therefore the deploy token cannot do everything the Docker Hub password can do.

This will work similar to Google Account multi-factor authentication and app-specific password for those apps that don’t support it.

Sorry if solution like this was discussed before.

@superwanglin

This comment has been minimized.

Show comment
Hide comment
@superwanglin

superwanglin Oct 28, 2015

Why can't docker simply provide an option to disable saving clear-text password before proper security is implemented?

superwanglin commented Oct 28, 2015

Why can't docker simply provide an option to disable saving clear-text password before proper security is implemented?

@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Oct 28, 2015

Contributor

@superwanglin Could you expand on your proposal? Do mean having a --no-save-password flag and having the user enter password for every push and pull?

Contributor

stevvooe commented Oct 28, 2015

@superwanglin Could you expand on your proposal? Do mean having a --no-save-password flag and having the user enter password for every push and pull?

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Oct 28, 2015

Contributor

I'll reiterate that I believe the right solution here is to support Digest Authentication in the registry and support to store the password as a digest (hash). This solves a number of security complaints. This would work similarly to a token and would be simple to implement.

Contributor

ewindisch commented Oct 28, 2015

I'll reiterate that I believe the right solution here is to support Digest Authentication in the registry and support to store the password as a digest (hash). This solves a number of security complaints. This would work similarly to a token and would be simple to implement.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Oct 28, 2015

Member
Member

tianon commented Oct 28, 2015

@JonathonReinhart

This comment has been minimized.

Show comment
Hide comment
@JonathonReinhart

JonathonReinhart Oct 28, 2015

@mmdriley nailed it:

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

Look, if you don't want to re-type your password every time, something valuable has to be stored locally. I don't care if it's a hash or a token or what. This is why Linux has e.g. Gnome Keyring, so your secrets are only decrypted when you log in. It's the most convenient, and it's what should be decrypting your SSH private keys (they are encrypted, right?)

Docker should really consider following Git's lead here.

In the mean time, what @stevvooe suggested is what I wish existed. That, or an option I can specify in my docker config:

Do mean having a --no-save-password flag and having the user enter password for every push and pull?

There's no way I'm leaving my network's LDAP credentials in a base64-encoded file on disk. The fact that the JSON key is called auth instead of password frustrates me - like we're not even being honest about what's being saved.

Give me a way to prevent the creds from being saved to disk. I don't care if I have to re-type it. As a work-around, I've replaced my ~/.docker directory with a symlink to a directory in /dev/shm (mounted as tmpfs). Just add this to /etc/profile.d: docker_config_temp.sh.

...and I hope docker isn't planning on storing anything else there.

JonathonReinhart commented Oct 28, 2015

@mmdriley nailed it:

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

Look, if you don't want to re-type your password every time, something valuable has to be stored locally. I don't care if it's a hash or a token or what. This is why Linux has e.g. Gnome Keyring, so your secrets are only decrypted when you log in. It's the most convenient, and it's what should be decrypting your SSH private keys (they are encrypted, right?)

Docker should really consider following Git's lead here.

In the mean time, what @stevvooe suggested is what I wish existed. That, or an option I can specify in my docker config:

Do mean having a --no-save-password flag and having the user enter password for every push and pull?

There's no way I'm leaving my network's LDAP credentials in a base64-encoded file on disk. The fact that the JSON key is called auth instead of password frustrates me - like we're not even being honest about what's being saved.

Give me a way to prevent the creds from being saved to disk. I don't care if I have to re-type it. As a work-around, I've replaced my ~/.docker directory with a symlink to a directory in /dev/shm (mounted as tmpfs). Just add this to /etc/profile.d: docker_config_temp.sh.

...and I hope docker isn't planning on storing anything else there.

@TheDong

This comment has been minimized.

Show comment
Hide comment
@TheDong

TheDong Oct 29, 2015

@ewindisch Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.
The only thing it solves is that the settings in the webui would not be accessible, but frankly someone being able to push is scarier because that gives them arbitrary code execution in my application and any other users of my application... yeah.

As soon as you say "let them use the hash", you've turned the hash into a password and have the same problem all over again.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

However, none of that helps with the "something that can do scary security-risky stuff is stored on my disk with no option to have encryption or have it stored only in memory" like the keychain on most modern OSs.

If you want the benefit that hashes traditionally give you, of not being able to gain privileges by compromising the server, a public-private key architecture would be better (similar to what modern yubikey auth does) and also solves that problem. You know, if I could plug in my yubikey to push to repositories, I'd be so happy. And the only reasonable way to end up with something specialized like that is to allow auth-helpers so that I can plugin my own option... and that should be baked into Docker so that other tools have any hope of jumping onto it.

It would also help the enterprise where people usually already have an auth solution and would want to be able to have the same level of security and consistency around their registry servers and clients for policy reasons and simplicity.

Its been the better part of a year since @shykes said "there is work underway to switch to keypair-based authentication", which was repeated by other maintainers, and I see zero evidence. It would have been quicker for me to produce a baby than to wait for this issue to be resolved.

Bonus points for not having the "group security" label and having the "exp/beginner" label still!

@stevvooe Having that flag would certainly be a step in the right direction, especially since it was proposed in January (see "Store password unencrypted (yes/no)? no") and a couple times since, but definitely not enough to close out this issue or claim anything approaching a reasonable security story.

TheDong commented Oct 29, 2015

@ewindisch Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.
The only thing it solves is that the settings in the webui would not be accessible, but frankly someone being able to push is scarier because that gives them arbitrary code execution in my application and any other users of my application... yeah.

As soon as you say "let them use the hash", you've turned the hash into a password and have the same problem all over again.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

However, none of that helps with the "something that can do scary security-risky stuff is stored on my disk with no option to have encryption or have it stored only in memory" like the keychain on most modern OSs.

If you want the benefit that hashes traditionally give you, of not being able to gain privileges by compromising the server, a public-private key architecture would be better (similar to what modern yubikey auth does) and also solves that problem. You know, if I could plug in my yubikey to push to repositories, I'd be so happy. And the only reasonable way to end up with something specialized like that is to allow auth-helpers so that I can plugin my own option... and that should be baked into Docker so that other tools have any hope of jumping onto it.

It would also help the enterprise where people usually already have an auth solution and would want to be able to have the same level of security and consistency around their registry servers and clients for policy reasons and simplicity.

Its been the better part of a year since @shykes said "there is work underway to switch to keypair-based authentication", which was repeated by other maintainers, and I see zero evidence. It would have been quicker for me to produce a baby than to wait for this issue to be resolved.

Bonus points for not having the "group security" label and having the "exp/beginner" label still!

@stevvooe Having that flag would certainly be a step in the right direction, especially since it was proposed in January (see "Store password unencrypted (yes/no)? no") and a couple times since, but definitely not enough to close out this issue or claim anything approaching a reasonable security story.

@dbrgn

This comment has been minimized.

Show comment
Hide comment
@dbrgn

dbrgn Oct 29, 2015

Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.

True.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

That's one aspect. The other aspect is that you could generate a token for each service where you want to store the credentials, and then you can revoke the tokens if something goes wrong.

If you have a single password, changing that will break authentication on all places where you've stored the password (in either plaintext or as a hash).

I'd very much welcome pull-only scoped revokable tokens.

dbrgn commented Oct 29, 2015

Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.

True.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

That's one aspect. The other aspect is that you could generate a token for each service where you want to store the credentials, and then you can revoke the tokens if something goes wrong.

If you have a single password, changing that will break authentication on all places where you've stored the password (in either plaintext or as a hash).

I'd very much welcome pull-only scoped revokable tokens.

@calavera

This comment has been minimized.

Show comment
Hide comment
@calavera

calavera Mar 3, 2016

Contributor

#20107 fixes this problem. It will be release in 1.11.

Contributor

calavera commented Mar 3, 2016

#20107 fixes this problem. It will be release in 1.11.

@calavera calavera closed this Mar 3, 2016

@EugenMayer

This comment has been minimized.

Show comment
Hide comment
@EugenMayer

EugenMayer Jun 26, 2016

Having docker 1.11.2 this is still not fixed. In which release this is actually going to be in?

According to the changelog, it should have been part of 1.11.0: https://github.com/docker/docker/releases/tag/v1.11.0

But it is not working for me, still base64 encoding credentials.

EugenMayer commented Jun 26, 2016

Having docker 1.11.2 this is still not fixed. In which release this is actually going to be in?

According to the changelog, it should have been part of 1.11.0: https://github.com/docker/docker/releases/tag/v1.11.0

But it is not working for me, still base64 encoding credentials.

@EugenMayer

This comment has been minimized.

Show comment
Hide comment
@EugenMayer

EugenMayer Jun 26, 2016

Answering myself and leaving original comment for "google" - its just not really documented well yet, found

http://www.projectatomic.io/blog/2016/03/docker-credentials-store/

you need to add this into your $PATH https://github.com/docker/docker-credential-helpers/releases
and then add this to your config.json

cat ~/.docker/config.json                                                                                                                                1 ↵
{
    "credsStore": "osxkeychain"
}%

Also officially documented under https://docs.docker.com/engine/reference/commandline/login/ but this should be really promoted better.

EugenMayer commented Jun 26, 2016

Answering myself and leaving original comment for "google" - its just not really documented well yet, found

http://www.projectatomic.io/blog/2016/03/docker-credentials-store/

you need to add this into your $PATH https://github.com/docker/docker-credential-helpers/releases
and then add this to your config.json

cat ~/.docker/config.json                                                                                                                                1 ↵
{
    "credsStore": "osxkeychain"
}%

Also officially documented under https://docs.docker.com/engine/reference/commandline/login/ but this should be really promoted better.

@nisaea

This comment has been minimized.

Show comment
Hide comment
@nisaea

nisaea May 5, 2017

Sorry for digging up this issue but as great as the improvement it was closed for is (great job! \o/), it unfortunately doesn't solve the problem for everyone.

As several people mentioned, there's still the numerous cases of people working in teams on dockerized applications in a CI/CD environment and LDAP authenticated registries. In these cases, anyone with an access to the slaves in charge of deploying the images can easily access to the LDAP credentials that were used to docker login with, in the case of secretservice, the secret-tool command. In those cases, the provided solution is as effective as clear text and still compromises network-wide passwords.

I can't find any indication of anyone addressing this issue here, did I miss anything? In the meantime, does anyone has any advice on how to avoid the problem in this scenario?

nisaea commented May 5, 2017

Sorry for digging up this issue but as great as the improvement it was closed for is (great job! \o/), it unfortunately doesn't solve the problem for everyone.

As several people mentioned, there's still the numerous cases of people working in teams on dockerized applications in a CI/CD environment and LDAP authenticated registries. In these cases, anyone with an access to the slaves in charge of deploying the images can easily access to the LDAP credentials that were used to docker login with, in the case of secretservice, the secret-tool command. In those cases, the provided solution is as effective as clear text and still compromises network-wide passwords.

I can't find any indication of anyone addressing this issue here, did I miss anything? In the meantime, does anyone has any advice on how to avoid the problem in this scenario?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment