[fierro]

>The one service token and three accounts were not rotated because mistakenly it was believed they were unused.

This odd to me - unused credentials should probably be deleted, not rotated.

[pbhjpbhj]

This smells weird, surely? I'd be looking at who chose not to rotate those particular credentials.

1: "what are these accounts?"

2: "oh they're unused, they don't even appear in the logs"

1: "we should rotate them"

2: "no, let's keep those rando accounts with the old credentials, the ones we think might be compromised ... y' know, for reasons"

?

[pphysch]

More likely: "no one has any idea what these old credentials do, so let's not touch them and potentially break everything"

[sodality2]

Sounds like the perfect time to revoke the credentials and find out what uses them, so we can find why they weren't registered as credentials in use. Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys.

I'd definitely consider a "silent" credential - a credential not registered centrally - to be a huge red flag. Either it could get stolen, or break and no one knows how to regenerate it. And it's pretty easy as devs to quickly generate an auth key that ends up being used permanently, without any documentation.

[pphysch]

> Personally I'd rather do that, have a team ready, and break production for x minutes in order to properly register auth keys.

Sure, but you aren't going to do all that when your team is juggling N other priorities. At least, it will be very difficult getting mgmt and others on board. Unless it's explicitly in the context of a recent breach.

[sodality2]

Very true. Ideally the culture would be that we’re experiencing some pain now to avoid more later, so we should do it - I’d hope management was on the same page. Real world, unfortunately, often differs.

[fierro]

this is more plausible to me

[mparnisari]

Agreed. This whole post reads as "I'm the victim" but they don't admit on the one mistake that snowballed