views:

104

answers:

2

I want my application (PHP, but that shouldn't matter) to store some data in a shared repository (the APC user cache, but again irrelevant). To prevent users from reading eachother's data I'd like to encrypt it per user.

I could have the user specify the key in his configuration file for the application, but I'd rather generate it automatically so the user doesn't have to bother.

For this I would need a piece of data on the system that (almost) never changes and is only readable by the current user. I can then hash that, or something, to generate the key. Does something like that exist in a default user account on a Linux system?

+1  A: 

There are hidden folders in the home directory, simply named .appname. They can be read by the user.

How just generating a random key, and store it in ~/.yourappname?

Phil H
Eh, yeah, I can generate it myself. How did I not think of that? I even already use a .myapp directory :P
Bart van Heukelom
So-called hidden folders are not really hidden at all. One user can easily read files in another user's hidden folders ... unless prevented by the file permissions.
Stephen C
don't forget to set the file attributes of the secret to go-rwx
dz
Naturally I'll set the key file mode to 600
Bart van Heukelom
@Bart - unfortunately @Phil's answer implied that hidden folders were sufficient protection by themselves. That is not true.
Stephen C
+1  A: 

Storing a key in ~/.yourApp will work, provided that you set the permissions of the key file to 0600 and the permissions of the ~/.yourApp directory to 0700.

Of course you are relying on people not being able / willing to use root access to access other users' key files. If that is a concern you are going to need to use some kind of keystore where access is controlled by a master passphrase.

EDIT : in answer to the OP's followup questions below:

Even then the master passphrase must be stored on the system, or users will have to enter it manually for every request (I assume even storing it in memory is unsafe if you don't trust root).

It is all relative. If you are really paranoid, you don't store the key on any machine that you don't totally control. On the other hand, most people are prepared to trust that root has not been compromised and (as a fallback) that it requires some effort for someone with root access to break a keystore. An unlocked copy of your keystore in memory may count as "safe enough". Certainly, a lot of user keystore software seems to work on that assumption.

Why should the directory be set to 0700? Even if it was 0777, a file inside it with 0600 would still be unreadable to others, right?

Partly general paranoia, partly belt-and-braces, partly a sign to other users to "keep your nose out of my private stuff", and partly to protect against someone by replacing your key file. The last point could be critical ... or not ... depending on exactly how the key is used by your application.

Stephen C
Even then the master passphrase must be stored on the system, or users will have to enter it manually for every request (I assume even storing it in memory is unsafe if you don't trust root). That's no problem though, this is not meant to be used on systems where you can't trust root (and who hosts his application on such a system anyway?)Why should the directory be set to 0700? Even if it was 0777, a file inside it with 0600 would still be unreadable to others, right?
Bart van Heukelom