I want to encrypt my access tokens at rest, but th...

# squarelibraries

[ursus]

I want to encrypt my access tokens at rest, but the decryption being somehow expensive I'm thinking of caching the plain text of access token in memory.
Then I remembered to use ByteArray instead of a `String`so I can deterministically clear the value from memory, because GC blah blah.

But, when using okhttp interceptor to attach a token as

val tokenString = String(tokenBytes, Charsets.UTF_8) <-----
val newRequest = request.newBuilder()
    .header("Authorization", "Bearer $tokenString")
    .build()

then it's a moot point right?

Or -- the question -- is there a smarter what of doing this in okhttp?
Or do I just need to accept the transient token in memory (and therefore holding it as ByteArray is mostly pointless)?

[jessewilson]

I think if your attacker has access to your program's memory, you're in trouble

[jessewilson]

The ByteArray trick limits the trouble, but you probably still have a password in a string somewhere elsewhere

[jessewilson]

One extra hazard to be aware of is Okio doesn't clear buffers after they're used

[jessewilson]

So if you have an Okio Buffer containing a secret, it's underlying storage will be memory-resident until either its GC'd or recycled

[Colton Idle]

yeah. i remember having this convo on reddit years ago (i basically posed the same question you had OP) and basically everyone generally agreed that the only way someone would be able to grab that string would be to have root to dump memory, and if they have root, then they can do anything anyway and so trying to protect against that is futile

[jessewilson]

My preference is to find ways to prevent attackers from seeing your process memory

[ursus]

okay so if someone can dump the ram, it's even pointless to hold ByteArray as the cached thing -> just keep it simple with String?

[ursus]

My preference is to find ways to prevent attackers from seeing your process memory

I can do something about that in user space?

[jessewilson]

There's not too much you can do in user space that's not otherwise invasive. In Cash App we check if a debugger is attached, but that's just used as a signal for our risk system

[ursus]

Out of curiousity what did you mean by that then? Other when having sort of custom virtual memory layer or something like that

[jessewilson]

Trying to stay secure when an attacker can read your process memory is a difficult solution to a rare problem

[jessewilson]

I think your effort is better spent doing boring security best practices

[ursus]

yea I agree - I'm mostly looking at if it's materially better to not cache the token in memory, i.e. to pay the cpu cost for more security - but it seems the answer is not really, unless I could control okio as well

[ursus]

gotcha, thanks!