This is kind of related to Password Best Practices but more specific.
Do you use the same root password for all the servers in your organization? For within a class of devices?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
I'd like to say "yes, everywhere", but it's still "no" in some instances. My company is using Password Safe to manage passwords for our Customers, creating "safes" on a customer-by-customer basis. Many Customers have unique randomly-assigned passwords for root, local administrator, devices, etc. Unfortunately, some (either because of work done by prior vendors, or by laziness on our part) may have the same password used in multiple devices or on multiple server computers.
For my personal passwords I've gotten intereted in moving to a utility like Passwordmaker, which takes a "master passphrase" and some other fact (web site name, username, etc) and creates a random password from a secure hash function. As long as you know your "master password" and the "other fact", you can use the software to regerate your password each time you need it (i.e. the password is never stored anywhere, encrypted, plaintext, or otherwise).
I have yet to find a corporate password "vaulting" tool that does everything I want:
I'd be willing to throw money or development time at such a project, but I've never found anything that comes close or wanted to spend the time to get it off the ground.
I use SSH keys, use the same one for all servers, and maintain a good password on my keyfile. Saves a lot of aggravation.
For devices where this wouldn't work, I'd use a password that had a hard-to-guess core, then use the devices dns name, IP, or other common characteristic (such as OS or brand), to make the password unique for the device. This worked especially well for groups of similar devices. Just keep the pattern/mnemonic secret, along with the core, and you have a difficult, unique password that was easy to remember.
No, never. What I do to help mnemonics is to have a long (12 chars or so) common prefix that is modified by a medium length attribute (6 chars) of each server if they are in the same rack (or whatever you consider a group of servers, which should be determined on a need to access basis (see Ernie's comment and my answer)).
For example, if the server group is composed by mercury (10.0.1.1, smtp), mars (10.0.1.2, firewall), bacchus (10.0.1.3, web), and the common prefix is R%%SDO23jfida, then
- mercury: R%%SDO23jfida11001mersmtp - mars: R%%SDO23jfida21001marfirewall - bacchus: R%%SDO23jfida31001bacweb
The one used in the organisation where I was working:
Desktop/Local PC Admin password is all the same (but since we're ghosting all our machines, that is the only way to do it, and if someone ever found that password, we can still change our initial ghost image, and update all machines to receive the new image and we'll be fine.
Each servers has different password. Then again we don't deal with too much servers, if I remember correctly about 6 that I had access to (but I'm sure we had more), and instead of making overly complex password, they opted for simple, easy to remember password, adding reasonable |eet5peak to them, and making them really really long (but again, easy to remember) :)
Personally I believe for desktop PCs, you want to keep the root / admin password the same ensuring easy management using Local Admin Account.
For servers, it is best to be different, to ensure if there is a breach, it is contained purely on that server, and does not go any further. Also the password complexity will change depends on the importance of the server (ie. Server that keeps users/pass will be on highest complexity, server that keeps logs will be on lesser complexity, etc).
We do use the same root password everywhere, although it follows the best practices (randomly generated, actually). It is only needed in the case where we have to physically lay hands on a machine, for instance to do a filesystem check or forensics after a compromise. Like Geoff, ssh is the only remote access protocol, and it is disabled for the root user.
We use a randomly generated, retarded long password on each box and we never save it anywhere. normal user auth is managed through LDAP, as is Sudoers, so the only time we EVER need a password is when network access is not working, in which case it's totally acceptable to just down the server and go single-user, fix the network config, and bring it back up.
I've seen many people do this, but no-one could explain how this is more secure than using the same password. What keeps anyone who sees one of the passwords, from figuring out the others? The only advantage seems to be different hashes, but different salts on different machines solves that as well.
Can someone enlighten me on this?
Considering that the password is the last line of defence, I'd say that it's not as important as it once was.
However, the last thing you need is some yahoo in your office running amok, which is much more common.
Our password policy is to use a hard-to-guess common prefix, then use a common password for each class of server. This reduces the number of passwords I must remember while protecting other servers from "mistakes". Unlike Vinko however, we do not use any system that integrates anything related to the machine. I would recommend against that, since once anyone within the organisation has access to one password (because they need it), they can figure out the other passwords quite easily.
I log all root logins and let the error filter (logcheck in my case) pass them through to my e-mail, so that I know when someone is trying to crack the root password. Restrictions on where it can be done from, ensure that my e-mail is not filled to overflowing with these logs.
I noticed no one talked about changing passwords frequently. Yes, it is a pain... somewhere, but sooner or later any password would leak out (someone who quits?). I think that any kind of password must be changed after a while, no matter what you use as a rule to build it. Our policy is to guess a totally random password about every year, and then proceed to change it gradually on our devices. The gradual change let us have, ironically, a little more security, since at any given time we don't have the same password everywhere (which is not a good thing).
No. A policiy in my last work was to share a common generated password for devices in the same network and add a separator and some characters related to the IP address or the type of device. For example:
But still is insecure. What I do now is generate a different root password for every server or device.
i'm surprised no one mentioned this yet but i would be using ldap with kerberos to create a single login that would use SSH keys to specific devices. This of course assumes that the devices I'm attempting to connect to support LDAP authentication. With LDAP, I can create groups of users that have access to specific devices. Also, all my users are logging in via a centralized kerberos server so logins can only happen locally and I can immediately revoke an account in case it gets compromised for some reason.
If you have passwords or keys on 100+ machines, have fun changing all those passwords or authorized_keys files. I don't have to worry about that.
Using the same root password for more than one account or device is a bad idea. This will never hold up in an IT audit since there is no accountability. Once someone has the password, they can access multiple accounts and you can't prove who did or didn't do something. I have sometimes seen people try to bring accountability through logging of IP addresses but this is cumbersome and easy to hack.
To bring accountability and pass SOX, PCI, HIPAA, etc you need to limit access to generic accounts to a single person at a time, track what is then accessed and then change the password when they are done.