Feature: Provide means to use shared memory blob as password (automation, preventing accidental leakage)

[overheadhunter]

From @heinrich-ulbricht on June 10, 2016 13:3

This is a feature proposal concerning interoperability and integration with external tools and scripts.

What about a way to pass a password to Cryptomator without having to enter it manually (=automation) while preventing the password from (accidentally) leaking to log files.

#1 one day probably solves the first requirement: automation. But passing passwords via command line bears the risk of some tools (system log, usual logging tools) capturing the command line and thus the password.

Could we instead provide a pointer to a more volatile location in (shared) memory? Another tool could put the password there and launch Cryptomator with a pointer to the shared memory location. A nice service of Cryptomator could be to erase the memory right after reading the password.

The password thus should be safe from accidental leakage. Only if an attacker explicitly targets this mechanism he would be able to get the password from memory. But usual key loggers, general purpose monitoring tools etc. are no danger anymore.

(Note: key files are no solution for me since even a temporary file might somehow be mirrored by backup software.)

What do you think?

Copied from original issue: cryptomator/cryptomator#290

[overheadhunter]

From @tobihagemann on June 10, 2016 15:52

I think cryptomator/cryptomator#40 would also go into the same direction. Automation is something that we would like to offer sooner than later. But we're working on other tasks at the moment (Android, FUSE/Dokany, iOS, etc.), that's why we haven't made much progress on the automation front.

I understand that it might be tempting to implement this kind of feature in Cryptomator to circumvent key loggers (or similar tools). However, we want to keep Cryptomator lightweight and your suggestion seems to add some complexity. Cryptomator's security target is the protection of cloud files. If your machine is compromised, you would have more serious problems. It's better to install other tools that are specialized in detecting/removing key loggers.

[overheadhunter]

From @heinrich-ulbricht on October 9, 2016 11:58

I understand your reasoning. Just wanted to add this as idea to see if it gains traction. This feature could increase the chance of not leaking the password for a vault if you got "only" a keylogger.

[overheadhunter]

From @dodekeract on October 9, 2016 12:24

Why not just pipe it in via stdin?

tail < /dev/urandom

Shows as tail for me.

Something like this would easily work and be scriptable/usable in every major programming language.

[overheadhunter]

From @mostolog on October 23, 2016 20:26

My 2 cents: A password file that only root can read (root:700) and -p parameter could be enough.

[overheadhunter]

From @heinrich-ulbricht on October 29, 2016 12:45

@mostolog I'd rather have my password "file" in volatile memory only for the short time needed to mount the vault.

[overheadhunter]

From @dodekeract on October 29, 2016 13:13

@heinrich-ulbricht Good point. Writing it out is quite dangerous (why use encryption locally, anyway if you write out the password in cleartext?). I'd say piping will allow that.

[overheadhunter]

From @mostolog on October 31, 2016 10:23

@heinrich-ulbricht Apart from using system keystore, I don't know how you could pass password to automated command without providing it on a file. Do you have any idea?

[overheadhunter]

From @dodekeract on October 31, 2016 11:40

@mostolog how the user is gonna do it should be only the user's business.

[overheadhunter]

From @heinrich-ulbricht on October 31, 2016 12:0

@mostolog @dodekeract On Windows there are options like memory mapped files (not actually backed by a file) (MSDN) or named pipes. Something two processes can share safely and that doesn't touch the hard drive. Could be a challenge regarding interoperability, though.

[overheadhunter]

From @mostolog on October 31, 2016 16:36

I'm not sure I'm understanding your comments. Please, correct me if I'm wrong:

• To open a vault, cryptomator requires a password
• To automatically open a vault you need to "pass a parameter" to cryptomator
• You are proposing to use a "shared memory" pointer, and let cryptomator "read it".

Please, tell me when/how do you fill that memory (and what happens if computer is restarted) and how will you achieve Java to read that pointer.

I still prefer "root-only" files as a portable solution, or keystores.

[overheadhunter]

I still prefer "root-only" files as a portable solution, or keystores.

full ack. the latter one is already implemented for win/osx. however automation as discussed here is probably most usable on linux machines, which don't have a common keychain api (see issue #40), so a protected file is probably the way to go.