I've been looking for this for quite a while now but couldn't find a satisfying answer.
My scenario:
I'm using encfs to encrypt a few directories in my home folder. To make it easier to access I set up auto mount with gnome-encfs which stores the encryption passwords in my gnome keyring. So theoretically without my user password the data is safe.
But what happens if someone steals my box and logs in as root in recovery mode? He could just change my account password, log in, and all my encrypted folder would get mounted and decrypted.
My question is: do I need to change the root password to prevent this from happening? People in forums keep saying that anyone with physical access to my machine can do whatever they want anyway, but that is what I set up encryption for in the first place. I don't care if they read my unencrypted data but I want the encrypted stuff to be safe.
Edit: I also don't get why changing the root password is discouraged. Even if I forgot it I could still recover anything from my regular account and set up a new box.
Best Answer
It is true that someone who has physical access to your hardware can't be stopped from accessing the system. In most cases, I'd think all you have to do is replace
/etc/passwdand now it's cracked. I imagine this is a little trickier if the entire filesystem beyond the kernel is encrypted. I believe that is possible but I have not done it; maybe someone else will chime in.Gaining root access to the system, however, does not necessarily allow you to decrypt anything and everything.
I'm not a user of keyrings, but if, as you say, your encrypted folder is mounted and decrypted by a login, that is not very secure at all from this perspective, since gaining root access will circumvent that mechanism.
I do encrypt things; unfortunately I do it programmatically, so I don't have any end user software to recommend, but I can outline some concepts (and I'm sure there is end user software for this if you look; hopefully this info will help you understand what it's for and how to use it). Strongly encrypted data requires a key, which is sort of just a really big password -- e.g., if you have generated SSH keys before (exact same idea), they are usually 2048 bits, which would be 292 ASCII characters. That means there are:
possible such keys. Now, if you had a house full of computers and could somehow attempt to brute force something encrypted with a key like that 1000000 times per second, there are 60*60*24*365=31536000 seconds in a year and so the longest it should take to crack the encryption is: 1024765540059329252305773613922816842987192499673880138005147939736322144180234997881697152826069046920621447264139333444131137720398621292969563431838162199411176983996099571656208705935744929819763370065451153230491889226364147519084160779378366643536962387494809266961173766220860787944176572777902409485093681297237073262959315537372037338116951294879703261608251067330385153244179994740939199418574870520229058971285573863444899516498656960438980771601765830518363954994635344042527812713309592956293713298473385906108764499884354345453308129324880686692782919058638686093522275450436077758547560046
years. Of course, there are I believe much better strategies than brute force, but even if you cut that time by a factor of a billion, don't hold your breath.
That's on purpose -- these are hard core encryption algorithms, some of which were commissioned (and I guess are used) by the US military (which is why there is sometimes weird "export regulations" regarding them). They're effectively unbreakable, period. In war your opponent can potentially gain physical access to your hardware, but if your tish is encrypted and they don't have the key, they're stuck.
So one obvious and easy way to secure encrypted data on your laptop in case it gets stolen is to not leave the encryption key on it. Instead, you put it on a USB stick.
But what if someone gets the laptop and the whatever with the key on it (since it does have to be somewhere, you can't memorize it)? You password encrypt the key. You now have a weak link in the chain, though, because a 16 character ascii password only has 2^(7*16) = 5192296858534827628530496329220096 possibilities, meaning the brute force max @ 1000000 attempts/second is a measily 164646653302093722365 years. I think the number of attempts per second has to slow down though, because in order to test the cracked key they have to apply it to the encrypted data.
What I'm trying to say is: if the decryption is tied to a user login, yes anyone who grabs the hardware can easily crack it. I don't know if that is actually what gnome is doing, but probably, since it cannot get your password (those are one way encrypted, see NOTE) and use that (if it could, that would be smarter, because now if someone changed the password, your login would simply fail to decrypt the folder, and that would be that). But there are options, if you have stuff you really need to protect. [lightbulb: It may be that what gnome does is encrypt using the scrambled form (anything will do) when you logout, then decrypts it when you log in. A way to test this might be to log the user completely out, then log in as root and change the user password with
passwd username. Or you could just ask the gnome people about this issue.]NOTE: One way encryption means a method that is not reversible, but always produces the same result. So, you enter your password and it is transformed and the product of that transformation is compared to what is on record (ie, what is on record is not your password!). If they match, good. But if they don't, there is no way to take what's on record in
/etc/passwdand turn it back into your password. That's "one way" encrytion. Obviously it is no good for data, because whatever you encrypt that way is irretrievably lost, but it is the standard way of storing passwords (although I think some big companies that should know better, such as Apple, have actually been caught, post hack, as having not done this for some absurd reason, and stored customer passwords in plain text).