Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The passwd/shadow files in a unix-like OS contain sensitive info such as a user's password. In addition those files aren't necessarily secured: with a live CD we can access those files on the hard drive and potentially gain access to the sensitive information.

My question is: is there anyway to make those two files more secure -- perhaps "lock" them or even change their location on the filesystem?

share|improve this question
    
Nothing important yet....but a challenge was to break the root password :)...so we did it and are searching how to make it harder :) –  wisdom Jan 3 '12 at 19:18

3 Answers 3

up vote 9 down vote accepted

If someone has physical access to the machine they can modify these files to create a new root account or crack existing password hashes which is useful due to the prevalence of password reuse. Renaming or changing the location would be "(in)security though obscurity" and will provide no appreciable protection against this attack pattern.

Steps to protect your self:

1) Set a bios password, and force your hard-drive to be the boot drive. This however does not prevent someone from removing the drive from the machine.

2) Consider full disk encryption. Even if you just encrypt /etc/ someone could replace /usr/bin or /bin with malicious binaries that could be run as root. Even your /home/user/.bashrc file can be used to hijack your PATH and obtain root if you are a suoder.

But this isn't a prefect solution. You should think of security in layers and try and prevent physical access to the machine. (@dr jimbob has a good point.)

share|improve this answer
4  
+1 -- Full disk encryption. If the system is booted, files can be read or altered. Changing the location of those files makes things harder for legitimate programs. If the system can use the files when booted, there must be a reliable way to find them. A bootdisk system would play by the same rules and find them. FDE is your best protection against an offline attack. –  Jeff Ferland Jan 3 '12 at 18:58
    
@Jeff Ferland Good point. –  Rook Jan 3 '12 at 19:02
    
using FDE to protect the drive means even if I boot from a live CD the Drive will keep encrypted/not accessible ?? –  wisdom Jan 3 '12 at 19:06
    
@wisdom Correct, unless the attacker has the passphrase to decrypt it... –  Rook Jan 3 '12 at 19:07
    
Your best first bet is to restrict physical access -- anyone with physical access can easily put in hardware keyloggers for example even when the drive is encrypted -- wait for you to use it and then replay your keystrokes. Also, for the BIOS solution; you don't want a BIOS password (stored on the motherboard; easily worked around e.g., move to another machine) but hard disk password: en.wikipedia.org/wiki/Parallel_ATA#HDD_passwords_and_security . Note, a determined adversary can work around this (unlike disk encryption), but this will keep out the casual attacker. –  dr jimbob Jan 3 '12 at 19:22

The passwords are of course securely hashed. If the passwords are complex enough, then this should be enough to keep your passwords unknown.

I assume you want to keep someone from clearing the password and then booting up. This is not simple, but you could have a root startup script so when the computer boots, it checks to see if the shadow file is incorrect, and if it is, it deletes, crashes, or otherwise disables the machine or makes the private information inside unreadable. This does not stop the clearing of the password, but gives you an opportunity to take action on the next boot.

But remember, if the machine never boots, the hacker can still read all the files, regardless of the shadow file.

Caveat is of course that you need to write some program to detect malicious changes to the password file, while not ruining you when you make authentic changes. Probably you just want to detect if there were changes since the last known copy but only if that occurred while the machine was offline.

share|improve this answer
2  
No sane operating system encrypts passwords, they are always hashed. –  Rook Jan 3 '12 at 19:00
    
I consider hashes to be a form of "one-way encryption". Sorry if that is against established terminology. Yet this "one-way encryption" is not truly one-way (at least not from a password point of view) because of the brute force possibility. In that sense, it can be decrypted if the password and hash combination is not strong enough. –  George Bailey Jan 3 '12 at 19:36
2  
Saying you encrypt passwords makes me think you are violating CWE-257. Proper nomenclature is important, as it provides a predictable medium for communication. I absolutely detest the term "one-way encryption" because it causes nothing but confusion. Calling this process "decryption" is also bothersome, as hashes are always cracked. Hash functions and encryption functions are very different, and they are used in very different ways. –  Rook Jan 3 '12 at 19:47
    
@Rook, I will keep that in mind. Edited. –  George Bailey Jan 3 '12 at 19:52

Security by obscurity -- in this case, asking to change the location of the password file(s) on the system does not actually enhance the security. The original Unix designers knew this and ensured that all passwords were hashed within the passwd file even though the /etc/passwd file was completely readable by all. The shadow file -- moving the hashed password tokens outside of the /etc/passwd file -- only became vogue when another layer of security was deemed beneficial.

Rook's answer is also spot-on. If you cannot secure the physical machine, then any "locks" in place on the sensitive files will not be adhered to. Even if some form of "lock" was created on those files which was mutually recognized by all POSIX operating systems, I could certainly extract the data using some tool which ignored the "lock". Physically encrypting the disk is the only way to "lock" the file to prevent accessing the file from a Live-CD environment.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.