4 ms·

This is highly amusing. One of the first things it found was a publicly accessible oracle db. Second thing it found was someone attempting to make an authorita

This is highly amusing. 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'

cbkeller 7y ago
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.
- tialaramex 7y ago
  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.
  - souterrain 7y ago
    Sounds like a value-add for a CA. “We’ve seen your private key in public, we’re revoking your certificate for you. You’re most welcome.”
    - usr1106 7y ago
      And we sell you a new one :)
Doxin 7y ago
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.

cbkeller 7y ago

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.

tialaramex 7y ago
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.
- souterrain 7y ago
  Sounds like a value-add for a CA. “We’ve seen your private key in public, we’re revoking your certificate for you. You’re most welcome.”
  - usr1106 7y ago
    And we sell you a new one :)

Doxin 7y ago

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.