One of the first things it found was a publicly accessible oracle db. Second thing it found was someone attempting to make an authoritative repo on standards for django, which included this all-too-familiar line in settings.py
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '(d5%@h=u0m2a5-$4f^n(d%4mkt-@f1%h#3n64%+wmhf(kmx)ga'
Leaving the tab open for a half hour turned up about five of those, a google oauth key, and what seemed to be an SSL certificate private key, among others.
If you find "real" SSL private keys (from the Web PKI, ie they would be trusted by something like a web browser out of the box) you should be able to get a CA to revoke any certificates issued for that key by proving you know the key.
The usual format of private keys makes it mechanically trivial to get the corresponding public key back and then you can ask a public monitor like crt.sh to determine if that key is seen in any certificates.
Once you identify one or more certificates, you can ask the issuer to revoke them, offering proof you know the private key as the reason. For Let's Encrypt or any CA offering the ACME protocol you can use the ACME protocol to do this without involving any humans (the Certbot software for example has a "revoke" keyword that can do this).
Other CAs should have at least an email address manned 24/7 to respond to problems, which can explain how they'd prefer you prove you know the key. Or if you're just bored of this and want them to shut up and fix it, you could just email them the private key, whereupon now _they_ know the key for someone else's certificate they issued and that's prohibited by the rules they're working under so it's now their problem.
To be fair, you should be using a separate settings file for production anyways and having a secret key defined for development is incredibly convenient. Personally I tend to set the secret key to something obviously insecure though so people don't get the idea that it's okay to use the same key in production.
It doesn't feel like full disclosure is really the right policy here. It almost certainly makes more sense to give the person some time to clean up the secret before publicizing the secrets.
Many people feel full disclosure is never the right policy, and if we listened to them I'm afraid we would be worse off.
It has done a lot of good though even though I prefer something like project zero where vendors a given some limited time before the information gets disclosed.
As for this, I'm afraid one of the first results will be that the repo services shuts down the firehose access, which I think is bad. (I think I can see a number of other ways to improve the security that would work better than that.)
I should have clarified. I don't think immediate full disclosure is the right policy here. You should give people a chance to rotate the secrets before publicizing them. As the creator mentioned, most secrets are rotated quickly so it would be much more responsible to have this website run on a delay.
Attackers can (and are) already pulling the same data sources that power this. Whether or not this site delays/obfuscates the exposed secrets, that doesn’t stop attackers.
Or really anything other than decreasing the barrier between would-be attackers and exposed secrets and then publicizing them on a website with very high viewership.
The HN community is better than many online communities, but it's still very large and this post is almost guaranteed to lead to someone using credentials found on this website.
There are already teams out their on the internet who will scrape credentials and use them - especially public cloud keys (e.g. AWS access credentials to create Bitcoin miners).
The threat models are very different. This website introduces a new set of adversaries who do not need to build infrastructure that automatically takes advantage of leaked secrets.
There is nothing quite like seeing your password in plain text published somewhere for the world (or some subset of the world) to see.
Seeing an obscured version doesn’t have quite the same effect as the raw plain text.
Nothing quite like seeing a failed login attempt for username ‘yourpassword’ emailed to the entire IT team to make you think about changing your password from your ex’s name to something distinctly less personally identifiable.
The chances of you watching this website while your credentials unintentionally show up are essentially zero. This website is a tool for watching other peoples' secrets.
To be fair the people that would use this nefariously will already be doing something similar I am sure. This may lower the barriers to entry for others but the awareness it raises probably outdoes that risk by preventing the aforementioned nefarious users from being able to still use this sort of attacks method.
I can recommend using Ansible Vaults, and 1Password in addition to that. Ansible is quite helpful because all project secrets are stored in the local vault which is actually version controlled. The password for the vault can be found in 1Password.
Although suggestions in this sub-thread are good, prioritise reducing shared secrets first. You can't eliminate them from most projects today, but try not to have more than you need.
Use public key crypto in more places so that systems can ask "Was one of these authorised public keys able to authenticate?" (that list of keys isn't a secret) rather than "Was one of these secret passwords used?"
For something like all of the engineering group need access to the same test account in your production system: Consider whether some customers might want to share access to an account too ("Disney Global Team" definitely wants this and even "Sally Smith" might if Sally's entourage of agents, managers and assistants are handling a famous person's "personal" account) -- and so add a feature for each of those engineers to have their own login credentials for the account instead of a shared secret, then it reduces to a secret management problem for individual engineers.
While considering secret management also give a thought to HR termination checklists. Maybe sharing a single password is easier than building new shared account features for the product, but what happens when somebody leaves for their dream job? Gonna just trust that they won't tell? That's not a sustainable plan.
I personally believe secrets management is not done in software.
Systems should be fully constrained by networking logic.
If you need to hide certain authentications; create expiring DNS records derived from a secret hashing function, have the source of the secret algorithm pre-installed, and then delete after connecting.
I use regpg which is a wrapper around gpg to make public keyrings easy to manage and share via git, with auditing features for checking consistency between recipients of encrypted blobs and the keyring. Plus a few helpers for working with encrypted secrets more safely.
I would prefer not to base it on gpg but there weren’t any better options that I know of.
We use EnvKey for managing server secrets. It's designed specifically for doing this so it's much less friction than trying to use something like a password manager for the job. Highly recommended.
This tool should create issues in relevant repos unless the repo whitelists itself explicitly. Or alternatively just create one master issue per repo (should there be more violations in the future)
The tool has a flag icon which will open a new issue in the repo. I've seen a few false positives while watching, so auto-opening issues would be an issue.
Author here. I released the tool a few weeks back and since downsized the EC2 instance. So this post pretty much killed the box. I've just up-sized it again but it's still running fairly slowly due to high load. It typically finds around 5 secrets/a second. Corresponding blog post here: https://darkport.co.uk/blog/ahh-shhgit!/ and you can run your own instance here: https://github.com/eth0izzle/shhgit
We created a static version of this (almost similar to shodan but for keys) using publicly accessible Github dump hosted on Google Cloud in 2017. We then hosted the processed data, website and our search infra on AWS. AWS security team reached out to us for a potential “collaboration” and asked us to send all AWS keys that we discovered and we sent them the whole list. As a tiny startup, we were elated. Few days later they call us and threaten with a cease and desist notice if we do not take down the website. Remember we are not targeting AWS keys, neither are we in violation of any licensing agreements with respect to the data. We refused to shut it down. They then ask us to stop hosting it on AWS or “anywhere” else since we were using AWS credits to host the product or they will shut our account. When their this strategy did not work out, they contacted someone at Stripe who had given us the AWS credits, who then asked us to take it down or face consequences. We eventually had to shut it down since we did not have a lot of money to fight these people.
It was a stressful week for us where we learnt that corporates can lie and bully you to get whatever they want and then can shut you down. Unless you have the means to fight back. Does not matter where you live.
It included high entropy strings including keys from 30+ API and service providers, one of which was AWS. We did not target AWS specifically. None of the other services complained. In fact, a customer service widget company even took our help and thanked us. AWS tricked us in taking our findings and then changed their tone.
50 comments
[ 3.5 ms ] story [ 99.4 ms ] threadOne of the first things it found was a publicly accessible oracle db. Second thing it found was someone attempting to make an authoritative repo on standards for django, which included this all-too-familiar line in settings.py
The usual format of private keys makes it mechanically trivial to get the corresponding public key back and then you can ask a public monitor like crt.sh to determine if that key is seen in any certificates.
Once you identify one or more certificates, you can ask the issuer to revoke them, offering proof you know the private key as the reason. For Let's Encrypt or any CA offering the ACME protocol you can use the ACME protocol to do this without involving any humans (the Certbot software for example has a "revoke" keyword that can do this).
Other CAs should have at least an email address manned 24/7 to respond to problems, which can explain how they'd prefer you prove you know the key. Or if you're just bored of this and want them to shut up and fix it, you could just email them the private key, whereupon now _they_ know the key for someone else's certificate they issued and that's prohibited by the rules they're working under so it's now their problem.
It has done a lot of good though even though I prefer something like project zero where vendors a given some limited time before the information gets disclosed.
As for this, I'm afraid one of the first results will be that the repo services shuts down the firehose access, which I think is bad. (I think I can see a number of other ways to improve the security that would work better than that.)
The cat is already out and information is contagious / wants to be free.
Or really anything other than decreasing the barrier between would-be attackers and exposed secrets and then publicizing them on a website with very high viewership.
The HN community is better than many online communities, but it's still very large and this post is almost guaranteed to lead to someone using credentials found on this website.
Seeing an obscured version doesn’t have quite the same effect as the raw plain text.
Nothing quite like seeing a failed login attempt for username ‘yourpassword’ emailed to the entire IT team to make you think about changing your password from your ex’s name to something distinctly less personally identifiable.
If I was going to be watching other peoples' secrets for fun and profit (and not just for fun), I wouldn't be using the human-friendly version.
[0] https://git.zx2c4.com/password-store/
Use public key crypto in more places so that systems can ask "Was one of these authorised public keys able to authenticate?" (that list of keys isn't a secret) rather than "Was one of these secret passwords used?"
For something like all of the engineering group need access to the same test account in your production system: Consider whether some customers might want to share access to an account too ("Disney Global Team" definitely wants this and even "Sally Smith" might if Sally's entourage of agents, managers and assistants are handling a famous person's "personal" account) -- and so add a feature for each of those engineers to have their own login credentials for the account instead of a shared secret, then it reduces to a secret management problem for individual engineers.
While considering secret management also give a thought to HR termination checklists. Maybe sharing a single password is easier than building new shared account features for the product, but what happens when somebody leaves for their dream job? Gonna just trust that they won't tell? That's not a sustainable plan.
Systems should be fully constrained by networking logic.
If you need to hide certain authentications; create expiring DNS records derived from a secret hashing function, have the source of the secret algorithm pre-installed, and then delete after connecting.
Then disable inappropriate logging.
I would prefer not to base it on gpg but there weren’t any better options that I know of.
https://dotat.at/prog/regpg/
https://www.envkey.com
Since we already used Bitwarden on our team, utilising it to also manage our server secrets was a no-brainer.
[0] https://github.com/envwarden/envwarden
Failed to retrieve signatures! Reloading...
It was a stressful week for us where we learnt that corporates can lie and bully you to get whatever they want and then can shut you down. Unless you have the means to fight back. Does not matter where you live.
The service is currently overloaded.