Private key shouldn't be string

I don’t know why do we have this?. I’m expecting these key to be a Uint8Array. https://github.com/ethers-io/ethers.js/blob/master/packages/hdnode/src.ts/index.ts#L76

Since the string won’t be wipe off from the memory easy and I don’t thing people willing leave their unencrypted private key floating in the memory.

[ricmoo]

I’ve added a short note here, but I think that is all that really makes about sense. The JavaScript world is one with a lot of environments and while I think security is very important, there is only so much detail I can go into.

Feel free to suggest expansions to the security section though. 😃

[chiro-hiro]

Yes, everything make sense. Just remind that with Uint8Array we are able to zeroed memory area what was allocated. You are right about encrypt/decrypt private key is annoying according to user experience but the person who’s using this package not only using it in front-end of dApp, some of us try to bring into the back-end (helping our customer to deal with blockchain easier without knowledge of blockchain stuffs), at this point I hope we would have some thing sort of feature that alternative to mist wallet.

.unlock(address, duration); and .lock(address), I think this approach make sense too, unencrypted private key only appear for a short duration instead of living in the memory like a zombie.

I will certainly reference this issue (and any other research you come up with) to indicate the security issues in the documentation. But in JavaScript, the additional security gained by using a Uint8Array compared to s string is likely very minimal. These problems should be fixed in the node and browsers though, by zero-ing out free-ed memory.

Just check and garbage collector won’t fill the memory with zero that’s even worser than the thing we talk here. In my experiment I need debug permit to read node’s memory.