On 9/27/19 6:56 PM, Sage Gerard wrote:
I got sloppy here in a Stripe integration: https://github.com/zyrolasting/stripe-integration/blob/master/main.rkt#L31

I'm not an InfoSec expert, but I know I'd like to secure the secret key used here in memory instead of using a parameter.

I'd probably encrypt the value provided by a client module and store it (write-only from the client's perspective) using set-box!. But I have several other questions:

1. Does the garbage collector keep a clear text copy of the secret in memory before I encrypt it? If so, how can I make it easy for a client module to set the secret key AND make it such that a garbage collection pass will remove the clear secret from RAM?

If the secret ever exists as (or within!) a Racket string or byte string, then I think you should assume that the GC might leave old copies in memory when it moves objects around. Memory allocated by a foreign library or using Racket's malloc in 'raw or 'atomic-interior mode shouldn't get copied by the GC.

2. Are there any existing /cross-platform/ Racket projects that can proactively keep secrets away from the garbage collector and swap space? Nothing relevant comes up for "secret", "security" or "swap" on the package index.

I thought about this briefly when I was working on the crypto package, but I decided it was way too difficult to address at the time.

3. Are there any other intermediaries in a Racket process that might keep a copy of a cleartext secret?

If you read the secret from a file, it might occur in an IO buffer that is not securely erased. If you read it in encrypted form and then decrypt it, the decryption implementation might use intermediate storage that isn't securely erased.

Ryan

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/373ac5e4-ebff-f00f-eb1d-e097f4017fd3%40ccs.neu.edu.

Reply via email to