Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Keychain pass phrase #1135

Closed
richardschneider opened this issue Dec 7, 2017 · 11 comments
Closed

Keychain pass phrase #1135

richardschneider opened this issue Dec 7, 2017 · 11 comments
Assignees
Labels
exploration kind/wontfix-migration-available P2 Medium: Good to have, but can wait until someone steps up status/ready Ready to be worked

Comments

@richardschneider
Copy link
Contributor

richardschneider commented Dec 7, 2017

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
Copy link
Contributor Author

@diasdavid @whyrusleeping any comments?

@whyrusleeping
Copy link
Member

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
Copy link
Contributor Author

richardschneider commented Dec 9, 2017

@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
Copy link
Member

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

@richardschneider
Copy link
Contributor Author

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
Copy link
Member

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

@richardschneider
Copy link
Contributor Author

richardschneider commented Dec 9, 2017

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
Copy link
Member

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
Copy link
Contributor Author

richardschneider commented Dec 9, 2017

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
Copy link
Contributor Author

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

richardschneider added a commit that referenced this issue Dec 21, 2017
Allow the pass phrase to specified on the jsipfs command line.
richardschneider added a commit that referenced this issue Dec 22, 2017
Allow the pass phrase to specified on the jsipfs command line.
@daviddias daviddias added status/ready Ready to be worked exploration P2 Medium: Good to have, but can wait until someone steps up labels Jan 25, 2018
richardschneider added a commit that referenced this issue Jan 27, 2018
Allow the pass phrase to specified on the jsipfs command line.
@momack2 momack2 added this to Ready in ipfs/js-ipfs May 10, 2019
@momack2 momack2 added this to Ready in ipfs/js-waffle May 10, 2019
@whizzzkid
Copy link

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments before 2023-06-05. We will do a final pass on reopened issues afterward (see #4336).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exploration kind/wontfix-migration-available P2 Medium: Good to have, but can wait until someone steps up status/ready Ready to be worked
Projects
No open projects
Status: Done
Development

No branches or pull requests

4 participants