tooManySecrets
Wednesday, 12 Mar 2025
Exclusive insights, data, and analysis for financial market experts.
Search
Have an existing account?
Sign In
Or, failing that, a sensible error message. Don’t give me back 201 Created and put `”ErrorLines”: “Not authorized”` in the body.
(Yes this is in production, yes it’s a billion dollar enterprise. FML)
Looking at you Salesforce. Their bearer tokens are issued with an issue date, but no expiration or TTL. Apparently they are good for “about 2 hours”
I currently work with an external api where sometimes you have to manually go do a captcha for an account. No new credentials or API keys are generated, mind you. Just casually breaking the integration for fun I guess
Look at the like to comment ratio, unanimous agreement.
There are some key formats that include their own expiry time, not using those is a sin
I will take this request to my team for prioritization right now. Thank you for the PSA.
Unironically.
There are two expiration intervals that make sense:
1) Continuous. The credentials expire quickly (30 days or less). Anyone who wields the credential in production will need to create automation to refresh the credential from launch.
2) No automated expiration. Credentials are valid until manually revoked by either party.
Anything else is illogical. Suppose you have a credential expiration time of 5 years. What is the implication exactly … that it is okay for adversary to wield that credential for 4 years and 364 days … but 5 years, that’s just too much.
Multi-year expirations just cause outages, period. They don’t improve security at all.
Setec Astronomy
My Socrates Note
Not very optimal to send out two request, one to check if your key is expired followed up by the second to do whatever action you want. Better send out your request and have handling for the token being expired and retry logic.
Better yet, don’t use an API key at all. It’s 2024, there are countless SAAS services that offer standard-compliant oauth2 for pocket change, so why does your API need its own custom auth solution?
Honestly, the state of auth is absolutely dire, and I cannot understand why. Even in my company, getting people to follow established standards instead of inventing their own inferior auth protocol is like pulling teeth. I’m beginning to suspect that this is the Great Filter – there’s something baked into our DNA that makes otherwise intelligent people want to waste their lives writing an auth system.
Just put the exp in the jwt, bro
not using JWT make u stupid
As an industry we just replaced expiring certs taking down prod to expiring tokens taking down prod.
It comes with the key.
There are sliding expiration dates. But I think they should return a header in every call with the expiration date.
Meanwhile, the refresh token endpoint:
There’s no good way (that I know of) to keep track of Microsoft Entra ID App registration client secrets.
I’m working part time as a QA Engineer for free when implementing an integration for a big name company. You’d think they’d have a bounty program 🙂
fun fact: Workday’s documentation on how to request a refreshed key is to request a refreshed key.
classic programmer problem, secrets everywhere but mine
try {
var result = await apiClient.GetAsync(..);
if (result.IsSuccessStatusCode) {
return DecodeResult(result);
} else if (result.StatusCode == StatusCode.NotAuthorized) {
await RefreshToken();
result = await apiClient.GetAsync(..);
if (result.StatusCode.IsSuccessStatusCode) {
return DecodeResult(result);
} else {
LogError(..);
}
} else {
LogError(…)
}
} catch {
…
}
One of my favorites:
Gitlab has this nice API to rotate tokens that you can call using that same token – this is great, since you can easily automate pre-emptively updating your tokens.
Or at least, it _would_ have been if they hadn’t implemented a non-optional “feature” that instantly and permanently revokes all the API tokens (including the new one) if you ever, even once, accidentally re-use the old token for any reason, no grace period or anything.
Gitlab claims it’s for security, which would be fine if there was any kind of grace period or it was optional.
But instead it makes the feature worse than useless, especially in larger systems/orgs with service accounts/tokens. Because now you have to halt everything to guarantee nothing might accidentally re-use the old token even if it’s mere seconds after rotation, or else you now have to re-provision the token using a higher level account (which often means manual intervention, with everything broken until you do).
This just shows some of you aren’t as good as you think you are.
Clearly OP has not aware of TOCTOU bugs. Providing such an API is considered bad practice. We have learned from the mistakes of `man 2 access`
That’s wasteful. If it expires after a certain amount of time, just store the date/time before you last got the key, and when it’s close to expiring get a new one.
Otherwise, if there’s a sensible error from the API, just get a new key and resent the request.
If it’s random times and nonsense errors, arrange meetings with the API devs until it’s worth their time to fix it.
Hobbyist programmer here. What if the first or last few bits of the key represented the expiration date/time? Kinda like discord snowflake ids with creation time. Is there any obvious vulnerability? Because this feels like a very easy and cheap fix for a company to adopt. What’s the catch?
Well. Most of them will give you back it’s expiration date when you generate it. Unless you are not generating your key with a call
It’s a “security” “feature” to not have that function.
I you get a 401 error with your api key, it means it’s expired. Simple as that.
Isn’t it a way to secure the resource? Having generic errors on prod and specific ones on a testing environment I mean
Lol just encode the first 8 digits with the date – problem solved
isn’t that the 401 you received? 😀 j/k and agreed
True
Yes, please.
“My voice is my passport”
If it’s a JWT you can determine this yourself
I have just recently started studying on IT/programmer and im beggining to slightly understand it
Too many secrets?
I think you mean *C-Tech Astronomy*
Pff, we told you information one time.
That’s approaching “too often.”
The title ref gave me thrills
The easiest way to get over imposter syndrome is to work with a 3rd party.
If this is a Sneakers reference, I approve.Â