undefined

points

[-]

Usually rotating a credential means that you invalidate the previous one. Never heard of rotating credentials that would only create new ones and keep the old ones active.

by simlevesque17 hours ago|

parent|

[-]

But then every rotation would break production, wouldn't it ?

by cortesoft16 hours ago|

parent|

[-]

rotations are usually two phased. Add new secret/credential to endpoint, and both new and old are active and valid. Release new secret/credential to clients of that endpoint, and wait until you dont see any requests using the old credential.

Then you remove the old credential from the endpoint.

by NewJazz4 hours ago|

parent|

[-]

Note that you risk reinfection if the attacker can somehow retain access while you rotate out secrets...

by kstrauser17 hours ago|

parent|

prev|

[-]

Ideally, you can have a couple of working versions at any given time. For instance, an AWS IAM role can have 0 to 2 access keys configured at once. To rotate them, you deactivate all but one key, create a new key, and make that new key the new production value. Once everything's using that key, you can deactivate the old one.

by oasisbob15 hours ago|

prev|

[-]

> What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live.

That statement in the report really confuses me; feels illogical and LLM generated.

An old deployment using an older env var doesn't do anything to control whether or not the credential is still valid. This is a footgun which affects availability, not confidentiality like implied.

Another section in the report is confusing, "Environment variable enumeration (Stage 4)". The described mechanics of env var access are bizarre to me -

> Pay particular attention to any environment variable access originating from user accounts rather than service accounts, or from accounts that do not normally interact with the projects being accessed.

Are people really reading credentials out of vercel env vars for use in other systems?

by trollbridge10 hours ago|

prev|

[-]

We have multiple Google accounts for this very reason. Of course, a lot of orgs don’t do this due to the Google Workspace per user “tax”. I tried and failed at a past employer to get some account other than my primary for doing OAuth grants like this.

by wouldbecouldbe18 hours ago|

prev|

[-]

When you rotate them, you supposed expire your old vars

by nulltrace12 hours ago|

prev|

[-]

Preview deploys are even worse. Every PR spins one up with the same env vars and nobody ever cleans them up. You rotate the key, redeploy prod, and there are still like 200 zombie previews sitting there with the old value.

by kevinqi17 hours ago|

prev|

[-]

yeah not redeploying on credential changes seems like a design flaw. Render redeploys on env var changes, for instance.

by treexs16 hours ago|

parent|

[-]

Vercel very clearly highlights that you need to redeploy once you make a credential change