single use enable token and/or time-based enablement tokens

[dovholuknf]

As a user, I'm worried about the infinitesimally small chance that someone might compromise my token.

I would prefer to have the option to have single-use enablement tokens and I would obtain a new token any time I want to enable an environment.

Alternatively, I'd like to be able to support reusing the token, but allow the token to expire. This would allow me to script mutli-environment enablements, and reduce the window of time the enable token is valid for. After the expiration time, I would be able to regenerate my token and assign a new expiration.

[qrkourier]

Interesting. This sparks a few ideas for me. I like that it would be an optional inconvenience for a user that needs more security. First, a clarifying question.

Would you still be worried if the chance was significantly smaller (e.g., even harder to guess)? This could mean a 14 character token from the same class of bytes like 3YJ9OSpRvYxNcc that would require, on average, ~196 trillion years to guess at 1000/second vs. ~51 billion years.

[dovholuknf]

Yes, of course. The space of the problem is irrelevant when there are simple mechanisms to take the probability from "really, really, really small" to zero. Let's just bring the risk to zero.

[michaelquigley]

This is actually more complicated than you might think on first blush. The token isn't just used to to enable an environment, it's used to identify comms from there on out. And there isn't as clear of a lifecycle as you might think. So, "one-time' use is kind of problematic, unless that lifecycle were to be concluded when the user does a zrok disable.

Account token expiry is very doable. The problematic portion is that environments need to be manually updated when the account token is regenerated.