2

In their communication about the april 2022 breach (summary here), Heroku states that environment variables (other than Review apps and CI variables) were safe because they are encrypted at rest.

We also wanted to address a question regarding impact to environment variables. While we confirmed that the threat actor had access to encrypted Heroku customer secrets stored in config var, the secrets are encrypted at rest and the threat actor did not access the encryption key necessary to decrypt config var secrets.

I wonder what prevents the hacker who could download them, to try many random decryption keys for the DATABASE_URL environment variable for example, until it decrypts to something that starts with postgres, and then they would have found the key. Once they have the key, they can decrypt everything else.

What am I missing here?

5
  • 1
    This is no different from brute forcing any other symmetric encryption.
    – defalt
    Commented Jul 14, 2022 at 13:41
  • @defalt thanks for the reply. This is interesting. I am no expert in encryption, and thus don't know what the consequences mean. Does that mean that it would take years of computing power to do so? Isn't there a difference in that the hacker can expect what the start of the result would be, and thus can know when they have found the key? Commented Jul 15, 2022 at 9:30
  • 2
    You are talking about a "known-plaintext attack" and encryption algorithms are designed specifically to not be vulnerable to that (and other attack types)
    – schroeder
    Commented Jul 15, 2022 at 9:34
  • 1
    @schroeder thanks a lot, I didn't know that concept. I looked it up, now I understand. I think it solves my question. Thanks a lot! Commented Jul 18, 2022 at 13:57
  • I asked another question related to this breach here: security.stackexchange.com/questions/263499/… If you have any idea on the matter I would be very interested Commented Jul 22, 2022 at 13:36

1 Answer 1

0

What you are suggesting is attempting to brute force the decryption. If this were possible then public key cryptography would not exist, and that means no such thing as Ethereum.

Environment variables are never safe, because they actually expose themselves to every interface that interacts with the deployment of your service. Sure encryption at rest is a good idea, but almost every single service out there is using some provider that does that by default. It's a bit like saying, your money is safe because you put it in a bank.

There are tons of reasons to never using environment variables for storing credentials. The primary reasons are that it actually adds points of exposure for your credentials, and doesn't reduce them.

Amazingly this is exactly the wrong thing that Heroku suggests:

Store your secrets in environment variables. A library like dotenv can seamlessly load and make use of these variables, provided they're accessible in a secure location. Another option is to use a product like Hashicorp Vault, which allows your application to manage secrets through a configurable CLI.

I honestly can't believe there is a provider out there that people are using that has such advice. And since there are just only a handful of strategies, which environment variables being the worst, I feel obligated to share a link to this talk on the adult solutions to the problem.

4
  • 2
    Hey, you probably meant to post some other link for "adult solutions to the problem", right? Currently it's the same link to Heroku blog.
    – Cthulhu
    Commented May 2 at 21:32
  • ha, yeah, sorry. I meant to link to this: authress.io/knowledge-base/articles/2023/07/11/… Commented May 3 at 23:09
  • First of all, thanks for the talk! I have a question on scenario when we are service consumer which I think wasn't addressed (I only skimmed through the q&a though). How do you propose to deal with authenticating your requests to KMS? You have to have some secret for that, right? Otherwise having encrypted key would be the same as having original plaintext. And then if there is some secret which we deliver to production, doesn't that automatically propagate exposure to all of our encrypted secrets, as if we delivered them to the production directly?
    – Cthulhu
    Commented May 4 at 9:20
  • 1
    Access to KMS are protected with machine identities. For instance in AWS you would secure access to the AWS KMS service using IAM. Also having access to KMS can't propagate exposure because an attacker would also need to have access to both KMS AND the encrypted credential. Every "component/service" in your software should have different KMS keys along with different access, which ensures that even if an attacker compromises one service's access, having access to other services' encrypted credentials offers no compromise. It might be easier to discuss this in authress.io/community Commented May 5 at 10:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .