This is the last official exercise of the workshop. But, that doesn't mean your journey ends here. There are many things we can do to further secure our bank, but let's get to that later.
You may have noticed that bank.js is dealing with very sensitive data. The secret keys are especially important to keep secure. Many people often forget that application memory can be an attack vector as well. Memory might be swapped to disk in plain text or an attacker might force an application to do a core dump and to get access to the memory.
Luckily libsodium has primitives that can help us lock down our application memory completely.
Take a look at the sodium.sodium_malloc(size) api exposed in sodium-native. This API allows you to make a node buffer that gives you full control over when memory can be accessed or written to. It also makes sure secure memory is never swapped to disk (this is actually protected by your OS kernel!).
Using the sodium.sodium_mprotect_noaccess(buffer) api you can mark a secure buffer as unaccessible. This means that if anyone is trying to read this memory (your own program included) it will immediately crash. You can then use sodium.sodium_mprotect_readwrite(buf) to make it readable/writable again. This is a very powerful construct as it gives you full control over sensitive memory in your application.
Use secure buffers for all secret keys used by bank.js, and make sure to mark them as noaccess if they aren't being used to encrypt/sign something
Again test that your application still works and try making your application crash by trying to read from a buffer that is marked with noaccess.