Hey,
If my environment token have been compromised, is that mean that my whole environment has been compromised?
Because even after using the closed permission on my services, I worry about some one will try to enable his environment while brute-forcing tokens (I know it can take a lifetime, but it is possible as much as I know)
Is there any way to hardened the environment enabling? Maybe with some kind of a passphrase?
I am aware that I can apply authentication on my services (ssh, web login and so on), but I am afraid that an attacker will have a foothold in my environment.
Thanks ahead.
Hi @Operator, welcome to the community and to zrok (and OpenZiti)!
Yes, if someone were able to brute force your enablement token that would be bad. I don't know if there's any extra hardening on the roadmap. I didn't see it when I looked.
@michael.quigley will know what the situation is better than myself.
In general, you want to treat your account token like it's a password or any other secure material.
If someone were trying to brute force a token, they would need to make many, many hits against the zrok API with invalid tokens. Unless they got infinitesimally lucky and got it within a handful of hits, we would see that activity and/or they would get throttled by rate limiting.
There's a facility in the web console to allow you to re-generate your account token if it were to get compromised.
Beyond that, there's not currently anything on the roadmap, as I believe we've got a pretty solid blend of security and ease of use.
Maybe at some point we might consider making the account token longer?
Indeed! Here's what it would take to brute force a 12-character enable token from the [0-9A-Za-z] class. That's 62 possible bytes in any order, so 62^12 is ~3.2 sextillion permutations. If we assume a correct guess will require, on average, traversing 50% of the keyspace, then the attacker needs to make ~1.6 sextillion guesses.
Assuming there are no rate limits, fail2ban, etc. intermediaries, the time to crack is a function of how many unsuccessful enable attempts they can make per second.
Let's say the zrok API was able to respond to each unsuccessful attempt within 1 ms (1000/second), which I'm guessing is extremely conservative (i.e., it probably takes much longer on modern hardware).
((~1.6 sextillion / 1000) / 86400 ) / 365.25 = 51,117,112,225 years.
So, I guess we'll find out if your zrok account was worth cracking some number of billions of years after the sun burns out, unless I got the math or assumptions wrong.
@Operator, i think it's a good idea to harden this a bit. I've added two new issues to zrok.
The first issue asks for single-use tokens or time-based, expiring tokens:
The second is for knowing every time an environment is enabled. This way, if someone did compromise my enablement token, i'll at least be notified and can take the appropriate action
Thanks everyone for the quick response,
@qrkourier, Brute forcing the env token was just one of the scenario I could think of, I am aware of the fact that brute-forcing account token will not be easy as you already mentioned, but when thinking of an attacker / unwanted person getting into my environment, I'd better be safe than sorry, that is the reason it came up in the first place.
@TheLumberjack That's sound like a perfect idea, especially the email notification of new enablement's. I'd love to use it in the future.
At the same time, I want to say that I am very satisfied with zrok and I really like its simplicity.