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?
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?
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
different password for every machine, but we keep them all in a pwsafe. PITA to look up, but stops one breach from having us pwnd.
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).
My 5c
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.
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'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.