5

This would be the ideal circumstance for programming monero-wallet-cli - however, this raises the same concern that running the client with the password supplied via an argument monero-wallet-cli --password="somethingPublicThroughTop":

If you ran {,h}top you would be able to see the forked processes' full invocation arguments.

If the Json-RPC server is just using http, which is not encrypted, than anyone using wireshark on the same computer (with read access to the process? I'm not sure how that part goes) could sniff the packets and read the User Agent header, defeating the recently added --user-agent flag.

Improve this question
2
  • 1
    Authentication and encryption will be there with the 0MQ change. The user agent thing is a quick fix. If you intent to run a wallet on a multiuser system where you're worried another user might attack you, you might want to reconsider regardless of whether there is password ablity inRPC.
    – user36303
    Commented Sep 28, 2016 at 11:37
  • 1
    Yeah that makes a lot of sense, for some reason I thought it would be easy to encrypt the http layer locally. Awesome, can't wait for the next release!
    – Athan Clark
    Commented Sep 29, 2016 at 20:08

1 Answer 1

Reset to default
2

No, you can't.

The Wallets RPC - Interface opens the connection only after opening the wallet and its lifetime is completely dependant on the wallet. If you close a wallet, it will shut down the RPC interface as well. This is caused by the design of a wallet instead of a dynamic daemon.

Your described problem with a visible password when listing the running processes is known and has been discussed already. While it is faster for an attacker to just read the password from the window title, your wallet is compromised anyways as soon as an attacker has access to your computer. This cannot be stopped by encrypting a connection or not having the password in the window title, as he would be able to read the password from your computers memory, trick you into entering it again, running a keylogger etc.

While a possible attacker in your network could sniff your user-agent, this wouldn't be much use to him as he can't modify your browser user agent to perform the CSRF attack the user-agent was established against. Keep in mind that the user-agent is not a password protection and trying to protect a public wallet in RPC mode like this will lead to a compromise by anybody who can take a look at your connection to it. The user-agent is only a temporary solution against CSRF, a more secure solution is worked upon (since some time, the priority is considered very low due to the very limited attack opportunities).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.