
Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled - lugg
Received this email a few minutes ago:<p>&quot;On Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data. Upon discovery, we acted quickly to intervene and secure the site.<p>We want to update you on what we&#x27;ve learned from our ongoing investigation, including which Hub accounts are impacted, and what actions users should take.<p>Here is what we’ve learned:<p>During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as Github and Bitbucket tokens for Docker autobuilds.<p>Actions to Take:<p>- We are asking users to change their password on Docker Hub and any other accounts that shared this password.<p>- For users with autobuilds that may have been impacted, we have revoked GitHub tokens and access keys, and ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place.<p>- You may view security actions on your GitHub or BitBucket accounts to see if any unexpected access has occurred over the past 24 hours -see https:&#x2F;&#x2F;help.github.com&#x2F;en&#x2F;articles&#x2F;reviewing-your-security-log and https:&#x2F;&#x2F;bitbucket.org&#x2F;blog&#x2F;new-audit-logs-give-you-the-who-what-when-and-where<p>- This may affect your ongoing builds from our Automated build service. You may need to unlink and then relink your Github and Bitbucket source provider as described in https:&#x2F;&#x2F;docs.docker.com&#x2F;docker-hub&#x2F;builds&#x2F;link-source&#x2F;<p>We are enhancing our overall security processes and reviewing our policies. Additional monitoring tools are now in place.<p>Our investigation is still ongoing, and we will share more information as it becomes available.<p>Thank you,<p>Kent Lamb
Director of Docker Support
info@docker.com&quot;
======
lugg
If you got an email you should:

\- Change your password on [https://hub.docker.com](https://hub.docker.com)

\- Check
[https://github.com/settings/security](https://github.com/settings/security)

\- Reconnect oauth for Automated Builds

\- Roll over effected passwords and API keys stored in private repos /
containers

Quick take:

\- Password hashes

\- Github tokens

\- Bitbucket tokens

\- Your Automated Builds might need new tokens

Checking my github logs - It looks like they've known about this for at least
a full 24 hours. Most people aren't going to have this looked at until Monday
which kind of sucks. Hopefully there is more of a postmortem coming.

Is anyone from github able to comment on this as well?

There doesn't seem to be a way for us to tell if a repo was read by these keys
over that time period.

~~~
rqs
Can I complain a bit about GitHub? Why I can only authorize my entire GitHub
account for third-party access? Could things be slightly better if the
authorization is done at repository level?

~~~
Sukram21
GitHub provides a way for more granular third-party access: GitHub _Apps_.
There, access can be set on a repository level [1]. E.g. Netlify can be
configured as a GitHub app.

It seems like Docker Hub is implemented as an OAuth app [2], where these
granular options are not available and you have to grant access to all your
repositories.

[1] [https://developer.github.com/apps/differences-between-
apps/](https://developer.github.com/apps/differences-between-apps/)

[2] [https://docs.docker.com/docker-hub/builds/link-
source/](https://docs.docker.com/docker-hub/builds/link-source/)

~~~
matthewaveryusa
I just looked at github OAuth scopes (
[https://developer.github.com/apps/building-oauth-
apps/unders...](https://developer.github.com/apps/building-oauth-
apps/understanding-scopes-for-oauth-apps/) )

honest question, what's the point of using OAuth when the Authz is so coarse?
Why not augment to have scopes per repo? Is it considered bad practice to have
have a variable (repo name) as a scope?

~~~
nickgros
IIRC the OAuth2-interfacing application needs to (or at least should) know
beforehand exactly what to request access to, so if that's read/write access
to all of the user's content, it's trivial. For the external application to
know something specific like a particular resource is more complicated to deal
with (especially with private/hidden content), so most OAuth providers don't
provide that level of granularity. It can be done, it just requires more
engineering than most (all?) off-the-shelf OAuth solutions provide, and it's
more control than most users actually need.

------
morpheuskafka
What permissions did the leaked tokens have?

If they had write access, then leaked personal data is the least of anyone's
worries. The real concern is how close the hackers came to infiltrating the
image source for virtually every modern microservices system. If you could put
a malicious image in say alpine:latest for even a minute, there's no telling
how many compromised images would have been built using the base in that time.

~~~
tiew9Vii
Yes, huge poisoning target enhanced by the fact images/tags are not immutable,
you really have no idea what you are fetching straight from dockerhub, one
pull of the same image/tag may be different to the next pull. Most people
blindly fetch without verifying regardless with multiple images of varying
quality for software packages.

~~~
elcomet
How could one verify ?

~~~
bayareanative
You can't. Not without end-to-end integrity with nonrepudiation. Checksums
aren't anywhere near enough. But that's Docker.. security optional and run
random, untrusted code from the internet.

~~~
jhasse
> Checksums aren't anywhere near enough.

Why not?

~~~
toxik
A checksum’s typical use is to detect transmission errors. A cryptographically
secure signature is what’s needed.

~~~
gtsteve
It uses SHA-256 right? My understanding is that there isn't yet a workable
collision attack on the SHA-2 family.

Regardless, I think it's certainly an excellent hardening step.

~~~
blattimwind
Infosec in 2019: The server I download code from telling me the hash of said
code is "certainly an excellent hardening step".

~~~
ithkuil
Can't the hash be verified by the client too?

~~~
subway
Sure, but who tells the client what the correct hash is?

~~~
krferriter
If you're the entity who created the image you can retain the original hash
and verify it against the downloaded copies. But that kind of defeats the
purpose of being able to download docker images across distributed hosts.

They'd really need to be signatures attached to the images, not just hashes.

------
Leo_Verto
Docker Hub being hacked was basically just a question of time.

With how much of the internet blindly pulls images from it, the potential gain
from hijacking just one high-profile one would be monumental.

~~~
ahmedalsudani
Hacking aside, Docker is an invitation to trouble. Anybody can publish a
binary blob, and users are expected to blindly trust it. It's centralized. It
doesn't have a context of "trustworthiness" yet I don't recall docker ever
warning me that the image I'm downloading could have been the work of any
person.

Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary
player...

~~~
speedplane
> Docker is an invitation to trouble. Anybody can publish a binary blob, and
> users are expected to blindly trust it

How is this issue specific to Docker? Anyone can download a random library off
github, use a shady linux distribution, or install utility tools loaded with
spyware.

I don't think Docker aims to solve issues relating to trusting upstream
software. It's a tool to help package applications, just like how tar allows
you to package files. What you put in it is up to you.

~~~
filleduchaos
Libraries off Github literally have the source available for you and the
community at large to vet. And you'll find almost no sane shop on the planet
where people are allowed, hell _encouraged_ to use shady distros or install
random utility tools in production the way they are encouraged to pull
unchecked binary blobs from Docker Hub in an often non-reproducible manner.

~~~
hk__2
> Libraries off Github literally have the source available for you and the
> community at large to vet.

Nobody read the source code for this exact reason: “the community is here to
read it so I won’t".

~~~
fock
Well, for most libraries used in Desktop Linux, a significant number of
stakeholders (developers+users) exist, which actually care for development and
the complete thing itself. Also the libraries generally are designed for
solving problems and not getting github-stars by bots/dependency-building.

For docker (and npm for all that matters) _a lot_ of important dependencies
are basically simple one-off "developments" with a single developer and no
userbase at all caring for them, because they don't really solve any
consistent problem, being basically just created to increase the visibility of
its creator on primitive metrics. The community is there for high-level
packages, but the dependencies lurk in test-scripts and seldom-used functions
carefully placed by some idiotic digital nomads for their personal CV-
polishment (ehm, not looking at you: [https://github.com/sindresorhus/shebang-
regex](https://github.com/sindresorhus/shebang-regex)). Have a look at where
this package is used (basically only in cross-spawn, where there are 10 other
similar dependencies), then think about, how much effort creating the
dependency hierarchy was, then look up who contributed the changes, where this
micro-package was required and finally decide whether this was some thing sane
people would do or if it's just for personal gain...

------
rad_gruchalski
Their hub website is pretty bad. I tried changing the password and the website
came back with an error: Failed to save password. Interesting, so I tried
again. This time it said: Current password is incorrect.

I thought, maybe I need to log out and try if the new password works. I
clicked on Log Out link, the website has refreshed and I was still logged in.

~~~
bproven
Yep - same here. :( It changes it, but reports error...

------
Kudos
Why am I being asked to change my password? Why haven't they just invalidated
it for me already? I'm astounded I was still able to login with my existing
password.

~~~
gtirloni
It looks like they have sent emails to everyone, not just the 5% affected.

~~~
logophobia
I haven't received an e-mail, I've got multiple docker-hub accounts.

~~~
tedmiston
I haven't received one yet either.

~~~
krferriter
Neither have I. I manage over 30 images on dockerhub. Maybe this means they
are certain my data was not in the data that was leaked but I'm not sure how
they'd be certain of that.

They did just post the notice in a banner at the top of
[https://hub.docker.com](https://hub.docker.com)

[https://success.docker.com/article/docker-hub-user-
notificat...](https://success.docker.com/article/docker-hub-user-notification)

------
thosakwe
Well, this is pretty disappointing. Docker doesn’t let you install it without
an account, so I registered and used it for maybe a day in all. And poof,
there goes my account data.

I’m just hoping that I was using a password manager by then.

Any word as to the cause of this? Was something important stored in plaintext,
etc.?

~~~
koolba
> Well, this is pretty disappointing. Docker doesn’t let you install it
> without an account, so I registered and used it for maybe a day in all. And
> poof, there goes my account data.

Eh? Doesn’t let you use what without an account?

Anyone can pull images anonymously. An account is only for publishing.

~~~
Andoryuuta
Downloading Docker CE for mac or windows requires an account.

[https://github.com/docker/docker.github.io/issues/6910](https://github.com/docker/docker.github.io/issues/6910)

~~~
steve_taylor
Direct links still work.

Mac:
[https://download.docker.com/mac/stable/Docker.dmg](https://download.docker.com/mac/stable/Docker.dmg)

Windows:
[https://download.docker.com/win/stable/Docker%20for%20Window...](https://download.docker.com/win/stable/Docker%20for%20Windows%20Installer.exe)

~~~
yjftsjthsd-h
True, but they deliberately obfuscate that to get people to sign up. Not a
great look.

~~~
mkagenius
This is the opposite of what it actually should be. All the startups of the
world, please ask least amount of personal information or none at all -- for
all we know these things are bound to happen.

------
Perceptes
Not a huge surprise. Here's another security issue with Docker Hub they've let
sit for 4 years with no action: [https://github.com/docker/hub-
feedback/issues/590](https://github.com/docker/hub-feedback/issues/590) (which
is apparently a dupe of [https://github.com/docker/hub-
feedback/issues/260](https://github.com/docker/hub-feedback/issues/260)).

------
jite
I've seen some failed attempts to log on to my GitHub account from 'Quito,
Provincia de Pichincha, Ecuador' (which is quite far from where I live, as I
live in Sweden...). Not sure this is related at all, but they started appear
after this leak was announced...

Luckily I use both 2fa and random password for github, would suck to loose
that account ;)

------
choward
I wonder if that will encourage them to finally resolve this issue:
[https://github.com/docker/docker.github.io/issues/6910](https://github.com/docker/docker.github.io/issues/6910)

~~~
dbnoch
Or fix this 4 year old issue where you cant use 2FA for accounts
[https://github.com/docker/hub-
feedback/issues/358](https://github.com/docker/hub-feedback/issues/358)

(Side note: this obviously wouldn't have prevented the current attack)

------
aneutron
From the same company that tried to force people to login before downloading
Docker CE.

------
rnotaro
Official Article from Docker (Same Text as the email):
[https://success.docker.com/article/docker-hub-user-
notificat...](https://success.docker.com/article/docker-hub-user-notification)

~~~
fock
success.docker.com!

------
viraptor
That's a nice summary. One thing I'm curious about is:

> Data includes usernames and hashed passwords

How are they hashed? And specifically, can we expect them to be already
cracked?

~~~
ghusbands
Yes, in particular we need to know algorithm, work factor and salting details
to know whether or not the passwords may be compromised.

~~~
trulyrandom
Just assume that it's compromised and generate a new one. There is no point in
wasting time trying to estimate how long it might take someone to crack it.

~~~
viraptor
It matters at lower extreme. If it was something trivial and people shared the
password with another account, then they may be already compromised. If it was
hard and salted per-user, they still have to change it, but the chance of
compromise on other services is significantly lower.

It may also explain some suspicious behaviour / source of compromise in the
past (we know when the issue was uncovered, not when the first dump was taken)

------
ghusbands
Knowing the hash algorithm, work factor and salting details would be helpful
in knowing whether or not passwords may be compromised. This should be
standard information given in a breach, rather than just whether passwords
were hashed.

Though, as they say that passwords need changing, we can safely assume that
their salting, hashing and work factor were insufficient and not following
best practice. Just like the lack of 2FA.

~~~
efficax
Eh, if hashes leaked I would still suggest changing passwords no matter the
crypto practices involved. If you change the password, the hash is useless. If
you don't, it's sill an attack vector, even if a technically impractical one
(for now)

------
saurabhnanda
Just wondering, genuinely out of curiosity - how does one get to this 5%
number? If the attacker had access to the DB s/he had access to 100% user data
right?

Or did the get access to a partition of the user data? How is this even
possible?

Some very old backup that had only 5% of earliest users?

Some log file which had plain-text creds of approx 5% users?

Or did they discover the attack as it was happening and kicked-out the
attacker in the middle of a data download (only 5% complete)?

~~~
torvald
Their data can be sharded whereas only a part of their databases got
compromised. Or it could be a cache layer that got compromised. Or a partial
user dump intended for something else that somehow ended up in the wrong
hands. I guess there could be a lot of reasonable explanations.

------
sambe
Why can’t these emails just come out and say it: “your account was affected”.
It’s always implicit.

Also, why rely on users to change their passwords? Is there a security log I
can check?

~~~
gruturo
Should they change your password for you? How do they communicate it securely
then? Over unencrypted email, whose password may or may not be the same of
your just-compromised docker account?

~~~
supakeen
They could invalidate the passwords making you use a 'forgot password' link to
enter a new password instead of keeping the old compromised ones :)

------
craftoman
Imagine the impact if NPM got hacked instead of Docker Hub. People would go
crazy, run the streets like monkeys and yelling why NPM is untrustworthy must
be boycotted. Last time one user got hacked and they blamed NPM for letting it
happened. Everyone went crazy...

~~~
manigandham
Both situations are bad, and people are upset over Docker Hub. It just happens
to be Friday night so it's not getting as much attention.

NPM is bad because the Javascript ecosystem is fast-moving with loose builds
that have thousands of dependencies that are all bundled and run insider
consumer's browsers.

~~~
craftoman
I never complained and whined like a baby every time I install Gnome for
example, using Debian's apt package manager where it fetches hundreds of
packages worth of 1GB. Do you know how many Linux devs required you to use Lua
libraries for example only for a single isolated piece of code just because
they were too lazy to write it down in C.

~~~
tomc1985
Most distributions' package repos _aren 't_ a free-for-all, unlike NPM

It'd be a legit criticism of ruby gems or CPAN, but linux distros are an
entirely different kettle of fish, and most of the mainstream distros take
security pretty seriously

~~~
craftoman
Yeah just like Mint one of the most popular Linux distro where you had a
preinstalled malmware on your ISO because servers got hacked. Should I mention
the ultra critical vulnerability of apt that was discovered few months ago or
that apt doesn't use https, cuase it designed to work with http only in the
first place.

~~~
dvdgsng
Wait, _designed_ to work with http only? Link?

~~~
onei
I think "http only" is a bit misleading given [1], but I'm no expert. In
essence, apt doesn't use HTTPS because it provides limited value for a package
manager. However see the link for a more comprehensive explanation.

[1] [https://whydoesaptnotusehttps.com](https://whydoesaptnotusehttps.com)

~~~
craftoman
Apt create 20 years ago, it's using HTTP protocol almost everywhere even
today. They should have redesigned the whole project and ban the HTTP
completely IMHO. I'm using HTTPS even on localhost services when I have for
example a project that needs Grafana and influxDB.

~~~
cyphar
The cryptography that apt (and other major distro package managers) use is
much more safe and useful than TLS. Even if they switched to TLS on all
transports, all of the package signing would still be absolutely required in
order for package upgrades to be safe. In addition, the package manger should
distrust the transport no matter what (in fact, it should be resilient to
compromised repo servers).

Now, should apt use TLS by default? Ideally, yes. A secure transport is better
than an insecure one regardless of what you're sending through it. But
unfortunately it's not as simple as that. Most CDNs charge extra for TLS, and
many existing free mirrors of packages don't provide TLS at all. Also, using
HTTP allows for proxies to cache packages.

Unfortunately, as we discovered recently, apt had not been distrustful enough
of HTTP metadata (which was a pretty big mistake since the entire design of
package managers is that they must distrust the transport, especially if it's
completely insecure like HTTP).

------
aerovistae
Would have made this a bit clearer to note in the post that this is an email
you received, and that you are not Kent Lamb using Hacker News as a medium to
distribute Docker announcements, which is what this looks like.

~~~
lugg
Good point, it does look wrong. Updated.

------
pavanagrawal123
I can't find an announcement of this anywhere besides HN? Will Docker be
publishing info via official mediums?

~~~
lugg
I assume they will. I only just got the email and it looks like only a small
subset of accounts are affected. Or at least that's what that PR spin is
supposed to make you think.

~~~
pavanagrawal123
I see. I originally thought this was the announcement, as that is what the
post indicated.

~~~
lugg
Yea sorry about that I was more focused on figuring out what needed to be done
today and who needed waking up so I just dumped the email.

I hope this doesn't hurt docker too badly. I really like the hub / auto build
service.

~~~
ohyeshedid
You aren't the one hurting Docker, they've done that themselves. You put the
word out there, so thank you for thinking of everyone else out there.

------
Gonzih
It saddens me that docker hub is still lacking FIDO or any 2FA support.

~~~
leowoo91
Most companies get 2FA after the damage is done..

------
bamboozled
You're probably busy, but you might want to update the splash page on Docker
[https://hub.docker.com](https://hub.docker.com) to notify users of the
incident ?

------
blcknight
I did not get any email but my github is showing dozens of failed login
attempts over the last 3 days.

~~~
lugg
Sending 190k emails takes time but please update us here if you don't receive
in a day or so. - curious if their 190k is accurate or downplay spin.

~~~
M4v3R
It takes around 2 hours to send ~200k emails if you use an external email
gateway and have good outgoing bandwidth.

------
Operyl
[https://status.docker.com](https://status.docker.com) still not a mention.
Wonder how long until it is.

~~~
ahmedalsudani
That's the wrong place to track a hack. The status page is concerned with
uptime, not security.

~~~
Operyl
I disagree, destroying a ton of keys breaks stuff.

------
diNgUrAndI
What are dockerhub's alternatives? No 2FA. That is bad.

~~~
lskillen
As others have stated you could run your own registry or use an alternative
service for private repositories, to minimise or eliminate the attack vector.

By replicating the images (or packages) that you need into your own account,
you can minimise the possibility of a bad actor replacing a well-known image
with something untrusted.

An alternative is to side-cart a service like Notary
([https://docs.docker.com/notary/getting_started/](https://docs.docker.com/notary/getting_started/))
in order to establish a chain of trust for images. If an image gets changed,
Docker will refuse to use it and you _will_ be warned that it is untrusted.

Biased opinion on an alternative registry:

\- Cloudsmith: [https://cloudsmith.io/l/docker-
registry/](https://cloudsmith.io/l/docker-registry/)

But you've got other options, such as:

\- Self-hosted:
[https://github.com/docker/distribution](https://github.com/docker/distribution))

\- Cloud-specific (e.g. ECR, GCR, ACR, etc.)

\- Sonatype Nexus: [https://www.sonatype.com](https://www.sonatype.com)

\- ProGet: [https://inedo.com/proget](https://inedo.com/proget)

\- Gitlab: [https://gitlab.com](https://gitlab.com)

\- Artifactory:
[https://jfrog.com/artifactory/](https://jfrog.com/artifactory/)

If you're missing the auto-build functionality, this can be achieved
reasonably easily with any of the mainstream and awesome CI/CD services out
there, such as:

\- SemaphoreCI: [https://semaphoreci.com/](https://semaphoreci.com/)

\- CircleCI: [https://circleci.com/](https://circleci.com/)

\- DroneCI: [https://drone.io/](https://drone.io/)

Disclaimer: I work for Cloudsmith, and still think Docker Hub is great. :-)

~~~
netsectoday
You can run your own private Docker registry but you will still depend upon
the base images pulled from hub.docker.com in your deploy chain unless you
make sure to clone the base image Dockerfile from github and build it
yourself. Even with this protected setup; you still have exposure from
poisoned Github repos after this attack because of the compromised Github
access keys. I'm not sure you can eliminate this threat, even with third-party
services. What a mess.

~~~
lskillen
It might be OK for the Docker Hub aspect at least, with a caveat later on; the
GitHub aspect is unfortunate and I completely agree. Direct access to source
is rather dangerous territory.

Back to the images bit first:

Base images are only referenced/pulled at build time. So if you've already
built your own image and stored it, it'll contain all of the layers necessary
to run it without explicitly pulling from Docker Hub.

In the case that you're building new images (likely), it'll need to pull the
base images from Docker Hub. However, if you pull the base image(s) from
Docker Hub first, you can tag them and store them in your local (or hosted)
registry, then refer to those explicitly instead.

For example (using a Cloudsmith hosted registry):

    
    
      docker pull alpine:3.8
      docker tag alpine:3.8 docker.cloudsmith.io/your-account/your-repo/alpine:3.8
      docker push docker.cloudsmith.io/your-account/your-repo/alpine:3.8
    

Now, instead of the usual FROM directive:

    
    
      FROM alpine:3.8
    

You can refer to your own copy of alpine:

    
    
      FROM docker.cloudsmith.io/your-account/your-repo/alpine:3.8
    

As you can see Docker's syntax doesn't make this extremely pleasant, and
you'll have to change existing Dockerfiles to point at the base images, but
it's certainly possible to mirror your dependencies without rebuilding.

Caveat: The downside is that you have to trust those dependencies at the exact
point you pull them down, so I concede it is still not perfect _without_
rebuilding the lot. :-)

------
lumjjb
Another reason to have Encrypted Container Images :)
[https://github.com/opencontainers/image-
spec/issues/747](https://github.com/opencontainers/image-spec/issues/747)

------
GordonS
Hmm, my GitHub account is showing failed logins starting from 2 days ago, with
none for the remaining period that GitHub shows - no email from Docker yet,
but I wonder if this is related?

------
nudpiedo
Why is this publicly posted here and not just in the platform and directly
contacting people affected? So big became the HN influence and marker? It
could have been just linked ️

------
mgalgs
Well this is fun, I'm now unable to logout. I have a feeling there's more to
this incident than Docker is currently disclosing...

------
madhuakula
This step by step checklist might help you "what should I do" to review your
accounts.

[https://blog.madhuakula.com/some-tips-to-review-docker-
hub-h...](https://blog.madhuakula.com/some-tips-to-review-docker-hub-hack-
of-190k-accounts-addcd602aade)

------
wtdata
What does this means for users? I was using watchtower to auto update the
images in my system. One of them was autoupdated after the failure.

Can this be used to upload containers with security exploits in order to gain
access to machines (i.e. does it give write access to the containers)?

------
billconan
I’m curious, how can a database be accessed without authorization? If
authorization is enabled? Also how unauthorized access can be discovered?

Say I use Mongodb and enabled authorization. Will I be fine then? How to
discover unauthorized access?

~~~
sirclueless
Authorization has a common English definition too. If, for example, an
employee's credentials were compromised, anyone who wasn't that employee who
accessed the database would be considered "without authorization". And
checking the access logs for any use of that employee's credentials would give
you some idea of what data was accessed. Enabling authorization on your
mongodb is good, but it absolutely won't stop all forms of unauthorized
access. They may gain access to your server itself, or gain some credentials
to your MongoDB database some other way (for example, if someone carelessly
ships them as part of your software, or includes them in a github commit, or
something like that).

In the worst case, if someone notifies you of a configuration problem or some
software bug that allows anonymous access to your database or the ability to
remove logs, you may have to assume the entire database was compromised since
the existence of that configuration issue or software bug.

------
aphextron
Is this affecting CircleCI? As far as I know their images pull from Docker
Hub.

------
jaequery
If the passwords are hashed, just what are the likelihood of your passwords
being decrypted? I’d also imagine it is a one way hash since that’s typically
the norm so I don’t even know how it can get decrypted.

~~~
TheDong
Hashes are not decrypted, they are bruteforced.

> I imagine it is a one way hash

All hashes are one way. If it's lossless and can be reverted, it's a
compression algorithm or isomorphism or encryption or cipher or any of a
number of other things, but not a hash.

> I don’t even know how it can get decrypted.

It is not decrypted, but brute forced. For example, even if you can't
algorithmically figure out what the input to md5sum is that gives you
'1f3870be274f6c49b3e31a0c6728957f', you could apply md5sum to every word in
the dictionary in a matter of seconds and find out that 'apple', when
md5summed, has that output. You would then have one possible password for that
hash (though technically there are infinitely many inputs that have that
output).

The only way we can know how computationally difficult it is to brute force
the password hashes is if we know the following: 1) the hash algorithm used
(and other inputs like cost factor) and 2) the entropy of the salt used. Those
two together lets us calculate the amount of computation needed to try one
brute force "guess". Individual password's difficulty to be brute forced can
then be calculated from their entropy (e.g. 'apple' has less entroy than
'2SEZb'), to determine the average number of inputs needed to be tried,
multipled by the cost of each attempt. Given that difficulty, you can then
estimate how long an attacker will take to find your password by estimating
how much computational power they have at their disposal.

In general, if you randomly generate 10+ character passwords and docker used
best practices, the answer is that any attacker will not get your password in
under a thousand years, and if you use a password which has been leaked before
or is a dictionary word (or simple variation), it can be found on the order of
minutes to days.

~~~
techntoke
Hopefully they are salted with a unique ID because of the are using a md5sum
only then you're screwed with rainbow tables.

~~~
unfunco
I'm going to go out on a limb and say Docker are unlikely to be using MD5,
salted or otherwise.

~~~
techntoke
Agreed.

------
ankushnarula
Docker has revoked GitHub and BitBucket access tokens tokens at least as of 27
Apr 2019 18:41:36 UTC

[http://archive.fo/bKGKq](http://archive.fo/bKGKq)

------
pyman
Let me get this right, Docker now forces users to register in order to
download their client and they don't secure our data? Insane!

------
zoobab
Error 500 when I try to login:

"Sorry, it's not you. It's us, but we are working on it!"

------
skilled
So, would it have been possible that the perpetrators knew about the keys and
had built a way to scan them all beforehand? Or is this more likely to be an
attempt at farming passwords?

------
villgax
hash+salt please

------
arjamizo
you guys should partner with github to disable those token which have leaked

------
gigatexal
Does this lessen the relevance that docker has these days?

~~~
viraptor
Did Docker become any less useful for you due to this, or provides less value?
Unlikely.

~~~
gigatexal
I’m thinking twice about using docker hub.

And the main usecase is k8s. So docker is just an implementation detail its
relevancy is waning imo

~~~
friedrichg
Docker hub is a centralized service. What we are seeing is the result of
having a huge centralized service: if it gets compromised, then many
dependencies are compromised.

Some organizations took the risk of running docker taking images directly from
docker hub. They were relaying the security of the images to them.

Some organizations are going to panic now and host their own registry. Which
they need to protect as well. But in general it will create a better
decentralized ecosystem.

I think this is good for the docker community in general.

~~~
gigatexal
We run our own registry that just mirrors images that we want to use and keeps
them up to date. It’s not a silver bullet but it works.

~~~
turtlebait
I'd worry about mirroring the images because of cases like this, you'd want
some sort of triage process before it gets into your environment.

------
begueradj
That is a great news. Happy security.

------
hestefisk
I think this is a very ugly incident for Docker.

