On Dienstag, 18. Juni 2013 03:05:05 CEST, David Lang wrote:
On Mon, 17 Jun 2013, Thomas L?bking wrote:
Subject: [trojita] Re: Using QtKeychain ...
This seems like familiar territory :-)
It's not the best way possible, but do you really want to drive
away users because of this? Does that really improve their
security?
I'm a bit puzzled by that mail.
Just to recap:
- i don't believe we should require a keyserver in order to avoid storing
plaintext, as this would make trojita inconvenient for users not using
keyservers w/o necessarily getting them more security
- kwallet does not provide any security beyond offline security (like an
encrypted FS would)
- users need to care about their security. they should be made aware when
sensitive data would have to be stored plaintext and preferably enabled to deal
with that situation (by choosing the path for the sensitive data explicitly)
- the target is never encryption, but data protection. this can be reached by
living alone with a dragon in a castle, keeping the sensitive data on an
external storage you keep close to you or by encryption on hardware, filesystem
or application level.
- online data protection can only be reached by authorizing to the system (eg.
with an ssl key on a usb stick or a password that is matched against a hash)
If trojita wants to provide app-level on/offline protection, it will require to
receive authorization (either by pam or having the user enter a password) and
use that to decrypt encrypted login data to send it to the server(s), ie. what
/usr/bin/openssl enc -e -aes-256-cbc -salt -in "$file" -out "$file.aes" -pass
pass:"$pass"
/usr/bin/openssl enc -d -aes-256-cbc -in "$file" -out "${file%.aes}" -pass
pass:"$pass"
would do.
Personally i would consider online protection through file/socket permissions
and offline protection by keyserver OR encrypted FS OR encrypted file OR
removable storage equally sufficient and only determined by the strength of
your password (ie. brute force)
The goal is to secure private autorization data when your device is stolen.
If a skilled attacker has online access to your box, you have inevitably lost.
He'll read the process memory or log your input to get the required passwords.
PS: The NSA reads your stuff anyway ;-P
If you encrypt the file, you then have to worry about how you
protect the encryption key. It needs to either be stored in a
file or hard-coded into the app binary. Neither is good.
Either is actually worthless.
Any authorization knowledge has to be "private" to the user, where "private" is
subject to context definition.
Therefore, if the box is not private, the authorization must not be on it.
If the box is private, any further authorization is superfluous.
FTR: Hardcoding the (same for everyone...) key in binaries is (sorry, i can't help it ;-)
of course ridiculous. See "CSS" or similar silly attempts.
Cheers,
Thomas
