Keychain pass phrase

[richardschneider]

The keychain (#1133) requires a pass phrase to protect the private keys at rest.

Currently it is hard coded, which is not secure.

I suggest we add the --pass ... option to ipfs.

If the 'pass' option is not specified, then all access to the keychain should return the error 'Access to the keychain is not allowed, please use --pass'. This is something like pubsub when --enable-pubsub-experiment is not specified.

[richardschneider]

@diasdavid @whyrusleeping any comments?

[whyrusleeping]

Hrm... In the past i've made that sort of argument accept a filename. That way you never expose your password to your shell history.

[richardschneider]

@whyrusleeping Good point, but storing the password in a file is worse. If an attacker has access to your machine, then she can get your password.

What about if no value to --pass then prompt for it.

[whyrusleeping]

I would argue that if the attacker has access to your machine, youre screwed already.

[richardschneider]

No, you are not screwed. Because all the IPFS keys are encrypted via the pass phrase. So if we don't store the pass phrase, the attacker has to use brute force.

[whyrusleeping]

attach gdb to the process, read memory, ???, profit

[richardschneider]

Good point, the pass phrase should be a buffer and when done with it should be set to some random value.

In C#, this is a SecureString

[whyrusleeping]

what i'm saying is that if someone has user level access to your user level process, nothing is safe. Even if we clear the passphrase out from memory they can still inspect the keys themselves. The threat model there is the same

[richardschneider]

They keys are safely encrypted with PKCS #8. So just looking at them will not help.

The only way to decrypt the keys is to produce a stretched password from the pass phrase. And I don't store the pass phrase nor the stretched password.

[richardschneider]

@whyrusleeping what about following the openssl conventions for a pass phrase.