I don't believe that's possible. You could have two entries in /etc/passwd
with the same user names but different UIDs, but the system would probably just ignore the second one (or misbehave in some way); arguably such an /etc/passwd
file would be considered corrupt.
When you login to the system, you're first prompted for your user name. Once you've done that, the system prompts for your password, and checks whether the entered password matches the password for the account corresponding to that user name. By the time you're entering your password, the system has already determined what account you're trying to access.
I suppose you could modify various pieces of the system to get the behavior you want, but you'd have to replace several different pieces of software, including anything that authenticates and authorizes users (console login, su, ssh, and whatever other methods are enabled). Any mistakes would likely open huge gaping security holes.
EDIT : Based on the comments, PAM is probably the way to do this. I'm not familiar enough with PAM to go into more detail. (It's still a really bad idea.)
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/passwd
and 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:
2^(2048) = 32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656
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/passwd
and 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).
Best Answer
Once they have the hard disk drive they hardly need your password. They simply mount all partitions according to (your)
/etc/fstab
. The next step issudo su - "your account id"
(if your id is 501, justsudo su - 501
).Short on using encrypted disk with a good password and all, there is little if any you can do to make your data safe.
This "little" include:
...=pop("me@google.com","avreyclverpassword")
, access to remote hosts, etc.)