View leaked secrets in Git live
shhgit.darkport.co.uk
shhgit.darkport.co.uk
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.
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'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.
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.
Since we already used Bitwarden on our team, utilising it to also manage our server secrets was a no-brainer.
The service is currently overloaded.
Failed to retrieve signatures! Reloading...
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.