You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just noticed token field usesstring data type. From the security perspective, shouldn't it be stored in []byte instead?
Since the string is immutable, once we've created it, if another process can dump memory like ollydbg, etc., there's no way you can get rid of the data before garbage collection kicks in. 1
While I agree in principal, I'm curious how to make this practical. How do you see callers effectively clearing the backing array of that slice? What shape of the library could we impose to encourage (or better yet, force) them to clear it? Even though we control this particular struct, we don't control others (e.g. the grpc internal buffers used to receive the message from the workload API), in which case are we really mitigating anything by making this change since other copies will surely exist?
To be clear, I'm not opposed to changing it to []byte, and would happy to accept a PR in that direction, I just don't think it's going to have any practical effect on the security posture of the workload. Thoughts??
Just noticed
token
field usesstring
data type. From the security perspective, shouldn't it be stored in[]byte
instead?Since the
string
is immutable, once we've created it, if another process can dump memory like ollydbg, etc., there's no way you can get rid of the data before garbage collection kicks in. 1What are your thoughts?
Footnotes
https://security.stackexchange.com/a/172578/188106 ↩
The text was updated successfully, but these errors were encountered: