Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Privacy

Managing Shared Passwords? 18

What's My Passcode asks: "At the company where I'm consulting, several of our systems are being moved from the internal network to the DMZ. When we were internal, we could easily agree upon the "one" root password that would unlock all these systems, or use a logical progression where the root password was a secret word paired/mixed with the box name. Now that we no longer feel it's safe to have just one password, how do we keep track of shared passwords? I have searched Slashdot, and discovered this past question, but it was aimed more at the individual remembering their passwords. I've also tried wading through a series of Google and other searches, but gave up after several hours of useless and missing links. We can easily control who has accounts on the box, and who can use su, but in order to su you still need to know that root password. Sudo and similar won't cover what we need to do."

"I'm curious what other folks have done. I know I could create a database and store all these things in there, but I'm not real happy about storing a database of passwords in case that box gets cracked (internally, which has happened to several servers already -- and it looks like one of the new businesses that Big Corporation bought is doing a little espionage), or in case one of the hardware guys finds it. (The corporation demands that hardware work be done by the hardware guys, OS work by the OS guys, and us application guys deal with applications.) The OS guys are comfy not knowing root, but I frankly don't trust some of the hardware guys, who will be the ones taking the boxes offline at regular intervals for preventive maintenance. The OS guys all rely upon phyisical access to the box, and they keep a sheet of paper locked up with all the passwords scribbled on it.

I've also considered a Palm Pilot db, with encryption, but the ones I've tried all are aimed at personal password management, and some are cranky about being beamed around, even with L0pht's beamcrack.

This discussion has been archived. No new comments can be posted.

Managing Shared Passwords?

Comments Filter:
  • by dkusters ( 2770 ) on Monday June 04, 2001 @03:56PM (#176987)
    Try out Password Safe available through Counterpane [counterpane.com]. It's from Bruce Schneier's company. Bruce Schneier is the author of Applied Cryptography, Secrets and Lies, CryptoGram newsletter, and the blowfish and twofish algorithms (one of which was an AES finialist). He has personally code audited the software, so I trust it.

    Have one password for the Password Safe and have it store the root passwords for your other computers. If you are very paranoid, keep the database on a floppy and lock the floppy in a safe when not in use.

    One downside, only Windows. But, a Linux version is coming Any Day Now (tm) (it'll be Open Source to boot!).

    Dave
  • What is it that su will do that 'sudo bash' (or whatever your shell of choice is) can't do?

    Yes, su can simulate users other than root, but that doesn't seem to be what you're interested in.
  • In what fantasy world do you live in where you routinely use a boot/rescue "kit"? the lunix one?

    Please. Try doing something like this in a large many host real unix server enviroment with a missmatch of server types and os's. It isn't practical. It isn't real. Having a "Rescue" kit laying around is even more dangerous than having a root password. How easy is it to copy a cd or a floppy? How easy is it to login to a machine via ssh from a secure trusted host and then sudo or su root commands?

  • What about one-time passwords via S-key. The way it works is:

    The system has a root password (which everybody that needs access can know). When you log in, you're presented with a phrase. On /your/ computer (not the server), you enter that phrase and your password (from above). This program generates a password that can be used ONCE!

    So, no matter who's sniffing, anybody can see the exchange, but the password remains private. Do a search for "S-key" or "one time password".

    Personally, I don't see what's wrong with require SSH. That /should/ be fairly safe.
  • by jfunk ( 33224 ) <jfunk@roadrunner.nf.net> on Monday June 04, 2001 @06:29PM (#176991) Homepage
    check out Keyring for PalmOS [sourceforge.net]

    It used to be called GNU Keyring. I use it all the time. It's quick, stable, open source and all that other good stuff. It generates passwords for you based on settings you pick and works for encrypting notes as well.

    That way you don't have to worry about your hardware guys sticking a disk in a password server and brute-forcing any data.

    Before I had a Palm I used GPG to encrypt passwords. That's a decent solution, too, as long as you don't save a text version anywhere on your computer. I was also using loopback encryption for certain directories in my home directory. That way, even my private key, all of my encrypted passwords, and anything else sensitive is encrypted. If you're ultra-paranoid and you're the only user of your computer, you can loopback encrypt /tmp as well.
  • Not if you know enough to set a boot password in your BIOS and/or disable booting from floppy. It's also a good idea to take advantage of lilo's features to prevent adding things to the boot command (like 'init=/bin/sh') unless the appropriate password is entered.
  • And FWIW, you can disable floppy booting in the BIOS and not lose any functionality. Just add a password-protected entry in lilo for the floppy drive - it'll save you from having to enter the bios when you need to boot from a floppy, or from having to reboot if you want to boot from a floppy but don't stick it in soon enough.
  • by coyote-san ( 38515 ) on Monday June 04, 2001 @04:47PM (#176994)
    Maybe I missed something, but why aren't you already using sudo or something similar?

    In case you haven't heard of it before, sudo is a SUID program that gives you root access (or restricted root access, e.g., the ability shutdown the system or mount/umount disks, but no more) once you authenticate yourself with *your* password. You never use the actual root password.

    Sudo also logs all commands executed. This can save you a *lot* of grief when you're trying to figure out what you did wrong.

    Since each person must be named explicitly in a separate control file, it's easy to invalidate users as circumstances change. It's a lot easier to change one file on multiple systems than it is to get everyone to memorize new passwords.

    As for the root password, I've found it unnecessary to provide *any* root password - just put a "*" in the /etc/passwd and /etc/shadow fields. The *only* place you really need the root password is if you're running in single-user mode because the fsck failed on boot - and in that case you'll probably want to use a boot/root rescue kit anyway.

    If you want to keep a root password around anyway, it should never be routinely used. I personally favor the "write it on a card, put it in a sealed envelope, and (optionally) lock in in your boss's desk. Once you use it once, generate a new random password and repeat" approach.

    As others pointed out, none of this will stop anyone from getting into the system their own root disk. But if fear of immediate termination doesn't scare them off, it's easy to remove the floppy and CD-ROM drives.
  • by lizrd ( 69275 )
    I'm going to have to agree with other posters here that you probably should be able to create a list of tasks that you actually need to accomplish as root and use sudo. If you're doing things that are greatly out of the ordinary your server probably shouldn't be online anyway. The solution of generating random passwords and placing them in a sealed envalope should cover your root password needs for any production server.

    If however, you still feel that it is necessary to have the root passwords avaliable frequently you probably want to use PGP or GPG. Each person will have their own key/password to access the encrypted file. This makes it so that the "meta-password" is not shared and eliminates the need to publically post any changes to the passwords since they will always be found in 'the usual place'. You will also have the ability to easily add or remove people from the list to which the password list is encrypted. Overall, the safest way in which a database of passwords could be kept on the computer.

    ________________________

  • Having a "Rescue" kit laying around is even more dangerous than having a root password.

    I'm curious as to why you say this. It would seem to me that it's much easier to physically secure a machine in the DMZ than it would be to secure it from network attacks. If you don't keep your servers in a locked server room you need some serious help.

    ________________________

  • Unfortunately I don't have an answer for you, except maybe if you trust all your employees then sticky note it to the case. But I have noticed allot of people quick to answer without fully understanding the situation... he has multiple servers and since they are now external he doesn't want them all to have the same passwords, so using Sudo to give each admin a different account on each box really isn't going to help, either your users STILL use the same password on all the boxes (great now instead of a 1 in a million guess each box has a ton of accounts to try and break) or each admin has separate accounts on each box... and they have to remember allot of passwords still. What is funnier, that the post didn't answer the questions.... or that they all got modded up?
  • I like to write down my password on a post-it note and stick it on my monitor. You could do the same in your situation, just put the notes on each of the servers. If this method doesn't suit, you could always try an encrypted database. I would suggest Rot-13 as the encryption algorithm, or if you are real concerned about security you could use Rot-13 twice.

    Seriously though, how about going a non-password route? Biometrics comes to mind, or those credit card type login cards. Any other similar solutions I'm missing? This would allow you to forget passwords altogether while still leaving the security in-tact. If you think that such a solution is a little too complex/over budget/etc. I would go the encrypted database route (just don't use rot-13!)
  • Get a piece of paper. Write the passwords down. Lock it in a fire safe. People who need it and some other responsible authority who is easily contacted have the combination or key.

    This sort of thing is desirable for disaster recovery, anyway--I keep a copy in the company safety deposit box, in addition to the one on-site. It's not particularly good to write passwords down, anywhere, but I'm in a similar situation and there are enough of them that there just isn't much choice. But far better to keep them off-line than use some of the techie solutions presented here. They're not susceptible to remote compromise and there's little chance of your piece of paper head-crashing or getting zapped with static electricity and losing all the information.
  • You missed it alright. He clearly said in the article that sudo won't work for him.

    He did not say why sudo won't work. Maybe he just doesn'r understand what sudo is capable of.

  • Use [Open]SSH keyrings or whatever it's called. I love it. Basicly you put the public key of everyone you want to be able to log into an account on local user of the box you want them to be able to log in to (In your case 'root'). Then they can use their private key to log in. I'll admit the key system is a little confusing at first but once you use it you start to love it. Start reading at `man ssh-keygen`.

    Leknor

  • these suckers can really get you. after a friend of mine fell asleep i grabbed his lappy and popped in a boot/root disk, mounted his disk and moved his passwd file just to see him freak out the next time he booted the box :) but apart from the joke, anyone can hook up one of those and yer toast unless you do something as mentioned above. It took me only 5 minutes to do what i did to my friend so it would be easy for anyone to do this behind your back.
    -----
    Kenny Sabarese
    Left Ear Music
    AIM: kfs27
    irc.openprojects.net #windowmaker
  • yea forgot all about that kinda stuff didn't know lilo had those capabilities i'm a GRUB user myself i bet grub has great stuff like that as well
    -----
    Kenny Sabarese
    Left Ear Music
    AIM: kfs27
    irc.openprojects.net #windowmaker
  • Clearly the safest thing here would be to put it all on a piece of paper and lock it in a fire safe - but that has issues in itself (about who can see what password, what is you leave the paper out in the open, etc), so here's my multi-pronged plan.

    This may cost more than some other ones, but I see it as secure and (relatively) practical. Go out to Business Despot and buy a zip drive, a cheap monitor, and a fire safe. Go to you local used computer shop (I'd go to Tottenham Court Road here in London) and buy a basic (like P133) spec computer, whith like 128 megs of RAM. Set up the machine with a root password that you tell the hardware guys, but keep all the passowrds on the Zip disk (PGP'ed if you want, but kept in the fire safe). Use all that RAM you've got to create a 64 meg RAM disk, and set all the temp dorectories to exist on the RAM disk. That way, the hardware guys can do what they want, but only you guys have the code to the safe (with the Zip of passwords in it). Needless to say this machine would be sepaerated from the network by the old two-inches-of-concrete trick (AKA put in a spare closet).

    If you'e really paranoid, you could load the entire system into another RAM disk, booting the machine off a LAN (which would be made up of the password computer and another whose only purpose is to be booted and insatlled off of and would remain locked in a box).

    If you wanna go one step farther, link the safe with the Zip disk in it to a mechanical device that dials your cell phone number if the Zip disk is out of the safe for too long and tells you the ID code the guy that opened the safe used (which he would have had to punch in as well as the safe code). And you could have that link to the combonation used to open the door to the room, ad infinium...fun with security - when you realize the only "secure" way to keep the passwords is to make them somthing simple and unguessable like " " or "foo."

It is easier to write an incorrect program than understand a correct one.

Working...