-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
murmur128 allows key hashes to be reversed #5486
Comments
It always about the ballance between security and performance. Key hashing is an operation which performed on each API call. So yes, if you need add it to public reports, you may consider use sha256 hashing instead, or "hash" tyk hashes before showing them in reports. |
Thanks for confirming this.
Actually, I think even more important is that keys are not stored in Redis, and instead only hashes are there for security reasons. If the Redis DB is compromised, then the attacker could recreate all the keys if murmur is used. |
The whole point of hashing, in any way, is to be used for DB lookups, so you can turn any kind of content, to some predictable hash value, which you can use as DB identifier. So it depends on your security requirments, and if you ready to sacrifice some speed for less security. For example FIPS security framework (required for gov agencies) put some strict guidelines on crypto and hashing algorithms, and will force your company to use algorithms like SHA256. But when using SHA256 key hashing algorithm, as mentioned above, it will be stored in redis as sha256 keys which is crypto algorithm,. |
Hi @jakub-bochenski, As @buger has explained, you can use SHA256 with Tyk for cryptographic hashing of keys, for info please see the docs here: https://tyk.io/docs/basic-config-and-security/security/key-hashing/#custom-key-hash-algorithms I'll close this issue as resolved, but if you have further questions please don't hesitate to reply and I can reopen it, or you could open a new issue. Thanks for supporting Tyk! |
@andyo-tyk well I can't if I use the official Helm Chart Can you act on this PR? TykTechnologies/tyk-charts#110 |
Hi @jakub-bochenski, I've highlighted the PR to my colleague who looks after that repo - they will take a look and pick it up there. |
@jakub-bochenski in meantime while it gets reviewed, you can unblock yourself just by setting his env var like this:
This example assumes tyk-single-dc umbrella chart. But key here is this MY_CUSTOM_ENV env option. |
Nice idea So if an ENV entry is specified multiple times in k8s config the last value is the effective one? I didn't know that |
@jakub-bochenski When the same environment variable is set in multiple places in a Kubernetes deployment, the last entry will take precedence and override any previous settings. So in the case of TYK_GW_HASHKEYFUNCTION, if it is already set as part of the base Tyk Gateway chart values, and you also specify it in extraEnvs, the extraEnvs value will override the base chart value. The order of precedence works like this:
So the extraEnvs value is always the last one applied and will override anything set in the base chart or umbrella chart values. But in summary - yes, extraEnvs would override a value like TYK_GW_HASHKEYFUNCTION that is already set in the base Gateway chart. The extraEnvs value would win. |
@buger I don't think overriding envs like that is a good idea. |
Describe the bug
https://en.wikipedia.org/wiki/MurmurHash
Reproduction steps
We would like to show key hashes in reports etc. for identification.
If I understand correctly using murmur128 to hash keys makes the hashes as sensitive as the actual keys.
The text was updated successfully, but these errors were encountered: