Slashdot Mirror


Cross-platform Password Management?

Martin Blank writes "I work in a NOC, and one of the debates you will find in any strongly-mixed environment like this is preferred OS. We have people who prefer Windows, some who like Linux, and some who do almost everything on Solaris boxes. However, this also means that much software is not available over all three. With all of the servers, routers, and various other protected systems we have, the sheer quantity of passwords is mind-bogglingly difficult to keep track of in a secure fashion. Are there any packages out there right now running on at least Windows and Linux, and preferably also Solaris, that can access a central password file?"

104 of 318 comments (clear)

  1. Doesn't that defeat the purpose? by jroos · · Score: 2, Insightful

    It seems to me that a centralized password system just defeats the purpose of having different passwords. If you can compromize the password system, you've compromized everything.

    1. Re:Doesn't that defeat the purpose? by ltsmash · · Score: 4, Insightful

      Security experts always say: 1.passwords should be 8+ characters 2.passwords should look like they were randomly generated (esp. no English words) 3.never write your passwords down (WHICH INCLUDES USING A PASSWORD MANAGEMENT SYSTEM). Personally, I usually follow rules #1 and #2, but there is no way I can memorize a 10+ randomly generated strings. Aren't security experts being a little hypercritical?

    2. Re:Doesn't that defeat the purpose? by vipw · · Score: 2, Insightful

      Having passwords written down isn't a bad thing; having them written on a post-it note on your monitor is. :)

      Passphrases for things like signing keys and such are often kept in a bank vault. Passwords like those are very long though and nearly impossible to remember. The ideal solution is for no unauthorized parties to have the password, but that can't be guaranteed just because it's a long random memorized password. Usually the best you can do is make it so your password can't be found without you knowing about it, and that can be done with written passwords that aren't left laying around.

      My method is to have the password in written form in my wallet for about 10-20 uses, after which I'm confident I won't forget it and then I eat or burn the paper.

    3. Re:Doesn't that defeat the purpose? by Radical+Rad · · Score: 2

      Of course that is true, but having a dozen hard to remember passwords can be a huge impediment to efficiency. The need for a centralized system is evident in the number of systems to provide just such a thing. Unix has had NIS/Yellow Pages for a long time. Novell followed with their NDS and recently with SSO Single Sign-On which ties in third party systems to NDS. IBM also has software to consolidate passwords but I can't remember the name of it. Microsoft used "domains" for their directory system, tieing multiple servers together with the same password database. So basically, others have already thought about what you said but have decided that the benefits outweigh the drawbacks.

      For cross platform password management, chech out Novell's NDS. It is light years ahead of their competitors and you don't even need to run Netware. You can host it on Linux only if you are a web hosting service or ecommerce site. They have been developing it since 1992, I think, so it is a very mature product and free for developers too.

    4. Re:Doesn't that defeat the purpose? by mmusn · · Score: 2
      WHICH INCLUDES USING A PASSWORD MANAGEMENT SYSTEM

      What makes you say that? A correctly encrypted password management system makes security better because it allows you to choose lots of different good passwords for different accounts.

    5. Re:Doesn't that defeat the purpose? by gentlewizard · · Score: 2

      I disagree. The reason for multiple passwords is historical: each system was an isolated island that had to create its own security checking routines. With everything more and more interconnected, it just makes administrative sense to centralize authentication. Thus the term "single sign on," or SSO.

      Now IMPLEMENTING that is a challenge. There are various approaches, such as NIS, Kerberos, RADIUS and LDAP directories with X.509 certificates. We're not there yet but getting closer.

    6. Re:Doesn't that defeat the purpose? by Rob+Kaper · · Score: 2

      there is no way I can memorize a 10+ randomly generated strings

      The don't have to be randomly generated, they should look like it. It's not that hard to come up with a string that is easy to remember yet hard to guess.

  2. Kerberos by Anonymous Coward · · Score: 3, Informative

    Look into Kerberos. About the only thing that has kept us from going full Kerberos is the lack of support on the Windows commercial SSH client (the one from ssh.com). It might even be there now, I don't know. I think some of the free clients support it though...?

  3. LDAP and Novell by dadragon · · Score: 5, Informative

    My school (Mount Royal College) uses a LDAP database to store the user's passwords. It works with all their windoze boxes (95,98,NT,2000) AND their Red Hat system they teach programming on.

    Might be worth a look. They use PAM on Linux, and Novell client on Windows, and the mac.

    --
    God save our Queen, and Heaven bless The Maple Leaf Forever!
    1. Re:LDAP and Novell by crowke · · Score: 2, Informative

      The best way to learn the basics of LDAP is to read the IBM Redbook (PDF) about this subject...

    2. Re:LDAP and Novell by irony+nazi · · Score: 3, Informative
      I don't see anybody mentioning it here, but I use a disk-on-key to manage my passwords. The password files are stored in an encrypted format, and I have OS-X, Linux, and Win32 binaries stored on the key that will decrypt whichever file I choose based on some passphrase. The passphrase is the same for all password files.

      The most common passwords, you will constantly use and not need the key for. The less common passwords, however will always be in your pocket, one USB connection and decryption away.

      I didn't see any other mention of hardware implemented solutions so I figured I would throw this one out.

      -irony nazi

      --

      Bringing irony to the Slash-masses
  4. The best method might be simple ... by x-empt · · Score: 4, Interesting

    Create a box running Apache SSL and have it firewalled / protected like crazy and locked down with LIDS or the NSA patches to linux. Use this box as the "password server" and have access to each and every password logged. And have each NOC employee be part of access groups that say "router access" or "colo access" or something so they can ONLY access data available for their group.

    On the logging tables in the database, make sure they aren't readable or writeable by the web-user. They should only allow INSERT queries.

    This might be the best way.

    x

    --
    Ever need an online dictionary?
    1. Re:The best method might be simple ... by __past__ · · Score: 3, Informative

      How exactly does one use a web server as a "password server"?

    2. Re:The best method might be simple ... by pongo000 · · Score: 3, Informative

      How does this help each user keep track of a large number of passwords? What you have here is a centralized NIS-like database of passwords, but it does nothing to help a user remember what password goes with what machine. Also, this seems like an incredible security risk, putting all your chips down on the bet that you can create a super-secure password server that will never be broken. What happens if you're wrong, or make a mistake?

    3. Re:The best method might be simple ... by Anonymous Coward · · Score: 3, Funny

      ln -s /etc/passwd /usr/local/www/data.default/AUTHENT ICATION

    4. Re:The best method might be simple ... by Citizen+of+Earth · · Score: 2, Funny

      How exactly does one use a web server as a "password server"?

      Not sure, but you use one as a credit-card-number server by telnetting to port 1521 and typing "system/manager".

  5. LDAP by PatJensen · · Score: 5, Informative
    Any UNIX that supports PAM (Solaris, Linux, etc) can authenticate against Kerberos or LDAP. Both are also supported by Windows-based OS's and servers. LDAP is very scalable with an extensible schema, and can provide support for more then usernames and passwords. For dial access services, LDAP can also be integrated with RADIUS or TACACS.

    Have fun.

    Pat

  6. kerberos by gtdistance · · Score: 5, Informative

    At University of Michigan they use kerberos for (almost) everything. Basically only the kerberos server has the passwords. I believe that when you want to log into a machine you actually get a ticket from the kerberos server, and the ticket is what is used for authentication.

    As a user I find it pretty convenient. I think it's pretty straightforward from an admin standpoint too, but I wouldn't know from experience.

  7. Smartcard systems? by jspaleta · · Score: 3, Interesting

    Have you looked into using smartcard technology.
    I realise it isn't very pratical adding smart card readers to every machine..but im just starting to look into smartcards on *nix and the msucle project seems to suggest that you can roll smartcard verification into your login procedure.
    http://www.linuxnet.com/apps.html

    I'm just psyched that i got my citbank serial port smartcard reader up and running under the pscsd smart card daemon. Now i can play around with this very idea.

    -jef

    1. Re:Smartcard systems? by jspaleta · · Score: 3, Interesting

      the project name is about as relevant as the misnamed linuxprinting.org website

      read muscle frontpage
      http://www.linuxnet.com/

      Linux is the targeted development platform....but the goal is have a framework portable across the unix based OSes: Linux, MacOS X and Solaris are all mentioned right up front....they even offer binaries for Solaris 8 on sparc for the base pscs software.

      The license for the pcsc-lite package that they offer is a BSD variant i believe....perfect for a reference implementation across ALL the unix based OSes out there.

      I think the windows world already has a large collection of cardreader software supplied by vendors...so taking care of the windows boxen would probably not need any software like this at all..since you probably get the cardreeader software for windows with the device.

      -jef

    2. Re:Smartcard systems? by jspaleta · · Score: 3, Interesting

      I've looked at the keychain usb devices before...but i thought th at market was moving towards portable data storage with ~100MB type storage...and not something meant primarily for small file storage like password storage.

      And are those usb devices supported on Solaris?

      I think smartcard/usb-keychain decisions come down to price-feature ratio. If you want real portable storage for files and what not the usb devices are the way to go...if you just want to keep passwords or cyptokeys/sigs then smartcards might be cheaper to implement.

      I'd also be concerned about support for the usb devices on the Unixes...
      But i havent seriously looked into it...since I dont have a real need for this stuff personally.
      My citibank smartcard reader was FREE. so getting it working under linux was a nice bonus.

      -jef

  8. Single Sign-On by Reknamorken · · Score: 3, Informative
    I don't think it's 100% clear what the answer is yet. I've seen some attempts at this using LDAP, but it can become quite messy. For example, if you want to tie routers into it you'll need to integrate LDAP with Radius/TACACS.

    Suprisingly, it seems that almost everything out there has Kerberos support these days. I'm going to start an experiment soon to see how well this works with Windows, but some of the websites seem to indicate that there is a reasonable amount of cross-functionality.

    Does anyone else have actual experience implementing Kerberos in a mixed Unix/Windows environment?

    --

    Linux is UNIX.
  9. Samba by dousette · · Score: 2, Informative

    Samba should be able to do it, from what I've heard, though I've never personally set it up before to do that.

  10. Low-tech solution by pongo000 · · Score: 2

    Why not use one or two well-built passwords (mixed case, punctuation, etc.) and then modify it for each host you need access to...so if you have hosts moe, larry, and curly, then your passwords for each would look something like

    moe.xy3,3IkshX476
    larry.xy3,3IkshX476
    curly.xy 3,3IkshX476

    Some might argue this is inherently insecure...but I maintain if a password is sufficiently "secure" in terms of randomness, then this method would be no less secure than generating three other random passwords.

    The drawback, of course, is that if one password is cracked, you've left yourself wide open...so start with a password you're convinced is secure!

    Of course, the better way is some sort of authentication scheme using something like ssh and PKI, which is available on the platforms you mention. But now, you have to worry about securing your private key...to me, it's 6 of one half dozen of the other. Either secure your password or secure your key, because either one stands to be compromized.

    1. Re:Low-tech solution by JM_the_Great · · Score: 2

      I don't really see why you'd need to modify it for each host. Might as well just have one secure password if you're going to do this. So either having one password is inherently secure, or it's not, no need for a whole password scheme to make things complicated.

      --

      --Justin Mitchell
      "2nd Place is a fancy word for losing" --Bender (Futurama)
    2. Re:Low-tech solution by tutal · · Score: 2, Insightful

      Pet pieve alert!

      randomness != security

      Why?
      1. Your typical user (read incompetant) has a tough time either typing or remembering a random password, especially if change frequently.
      2. If they can't type it easily they will hunt and peck, and type the password in slowly, which any malicious user can pick up easily.
      3. If they can't remeber it they most likely will write it down, and equally as likely put it on a post it note on their monitor.

      Solution?
      Use long passwords (over 8 characters) with alphanumeric replacement that alternate between hands ie dismantlement (the longest alternating qwerty word) could be dism4ntl3m3nt. And no.. that is not my password on Slashdot or anything else for that matter ;-)

  11. RSA SecurID by Gunfighter · · Score: 5, Informative

    I just attended a network security seminar at a small university in Virginia this past week. I manned the booth for my company, but between rush times I spent most of my time speaking with the people (sometimes competitors) from other booths. One of the engineers at another booth was kind enough to give me an RSA SecurID demo box with two key fobs and all the software I needed to set up a server.

    Within an hour of arriving back at my hotel room, I had the software up and running (had to download the Win2K agent from the RSA website), and my login to my laptop was secured via SecurID. Once I arrived home last night, I set up the server on my home network, and now all of my workstations and server (Linux included!) are using RSA SecurID login.

    You can run the server on NT/AIX/Solaris (probably more by now because I have an old kit), and there are agents out there for just about any operating system. In addition, you can have routers access the server as if it were a TACACS+ or RADIUS server.

    Check the RSA website for more information. The part you'll care most about are the agents (client side of the equation), and I know for sure that there are agents available for Windows, Linux, and Solaris.

    Good Luck!

    --
    -- Stu

    /. ID under 2,000. I feel old now.
    1. Re:RSA SecurID by dondiego · · Score: 3, Informative

      gack, do a google search and read up about how "SecurID" has been cracked and is not nearly as secure as vendors might lead you to believe... (As far back as 1996 they started finding problems) Here's an example discussion: http://www.linuxsecurity.com/articles/cryptography _article-2336.html

    2. Re:RSA SecurID by Zeinfeld · · Score: 2
      Or, if your fob dies (and I've seen about 60% of ours fail over the last 3 years)... Or if you break it (about 10% of our fobs)... If the fobs are available in a credit card form factor (thickness, too!), they'd be easier to keep on your person than the ones we have.

      Look at the activecard tags, we switched to them because they are half the price of SecureID and more reliable to boot.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  12. LDAP is very cross-platform by Seth+Finkelstein · · Score: 4, Informative
  13. NIS/YP..Take your pick. by Bowie+J.+Poag · · Score: 5, Informative



    The thing your looking for is called NIS. A vastly oversimplifed explanation of NIS goes something like this: An NIS-capable host is a system where passwd and group information is kept, and subsequently "pushed" to other hosts. Users log into local machines, the local machines reference their latest NIS maps, and log you in based on that. Its not difficult to set up or maintain, no more difficult than handling localized passwords, at least. Look into it.

    NIS is what Sun used to call YP, or Yellow Pages. Pick up a book on NIS administration, and knock yourself out.

    I'm sorta surprised this ended up on Slashdot. You'de think that a predominantly Unix-reading crowd would have rejected this one flat out due to it being so obvious.

    --
    Bowie J. Poag

    1. Re:NIS/YP..Take your pick. by ghack · · Score: 2, Informative

      NIS works great - I would highly recommend it. I agree with the parent poster in that using NIS is the obvious thing to do - the most simplistic google search would reveal that.

      http://www.linuxfocus.org/English/July2001/article 148.shtml is a good NIS howto.
      http://www.isi.edu/~govindan/cs558/nis/ is a good basic overview.

      NIS is a solution that will work on linux, solaris, and windows 2000 - so it is perfect for your application.

    2. Re:NIS/YP..Take your pick. by Surak · · Score: 2

      NIS will work well. You can also use LDAP or Kerberos. Furthermore, you could run Samba on all your Unix boxes, setup one of them as a PDC, and make all the passwords sync between the PDC and the local passwords.

      General Motors (my former employer) uses NIS. They have a mixed environment with Solaris, HP-UX, AIX, IRIX, and Windows 2000 boxes. They have everything tied to the NIS servers so that your login on your Windows 2000 EC2K box is the same as your Solaris CEe seat.

    3. Re:NIS/YP..Take your pick. by JLouder · · Score: 2, Insightful

      The thing your looking for is called NIS...

      NIS is simple to set up, but any user on one of your systems can run ypcat passwd (or ypcat shadow, depending on how you've set things up) and see everyone's encrypted passwords.

      Another problem with NIS is that is distributes the complete maps every time a change is made. If you're looking for an enterprise solution, you'll have a passwd map with thousands of entries, and you don't need to be pushing that whole thing around the network every time a user changes his password.

      NIS+ solves both of these problems, but is more complicated. But more importantly, Sun plans to remove NIS+ from Solaris after Solaris 9. They're encouraging everyone to switch to LDAP.

  14. LDAP by mnordstr · · Score: 2

    For best support I'd say use LDAP. Everything seems to support it, Windows/*nix, Apache, PHP, Perl, etc., and I think it can be integrated into Active Directory for further customizability.

  15. PGP by eyeball · · Score: 3, Interesting

    In the past I have very sucessfully used PGP for password management. I set up a shared fileserver (in our case it was an NT server, but it could easily be Samba or NFS), then create a text file with all the passwords in it, encrypted against everyone's public key. All users were then able to access these since since PGP was (and still is) available on multiple platforms.

    --

    _______
    2B1ASK1
  16. It exists..... by ruvreve · · Score: 2

    At Purdue University students use one password to access almost every online university resource. 90% of the computer labs use some sort of Windows variant. They use PC-R Dist to verify the user and keep the computers installed with a 'fresh' copy of Windows everytime a user logs on.

    Most servers are all *nix based with the majority being sun servers. When a user changes their password anywhere, it gets distributed across the entire system.

    I apologize for the lack of details but I don't know any of the specifics on whether or not it is a central password file or different servers all keep a current copy of the same file.

    1. Re:It exists..... by cscx · · Score: 3, Informative

      I apologize for the lack of details but I don't know any of the specifics on whether or not it is a central password file or different servers all keep a current copy of the same file.

      They use a program called actmaint, which I think is custom written. What happens is when you change your password using passwd at a unix prompt, it activates actmaint to go and propagate your password though all the Sun systems, all the Windows NT domains, all the Windows 2000 domains, and the custom NIS authentication (how do they authenticate the Macs to a Sun box, hmmm?) and other Unix systems across campus (like the engineering machines) that are linked to your password. This allows the regular Purdue network to be kept separately maintained from say, the engineering systems, but allows you to have a common password for conveinence. How does PC-RDist fit into this? It doesn't as far as I know; it is activated when a reboot is initiated to keep the hard drive data in a consistent fashion (i.e., all data you added is removed, all data you changed / deleted since login is replaced). Try the new WinXP stations to prove this; you have to login to a domain controller before it can auth you to a Sun box. _That_ may be using kerberos, but as fas as actmaint goes, it's not using kerberos tickets cause there are a significant number of Windows NT 4 machines out there (like the ones running student services...) that the passwords have to sync to, and kerberos didn't come out till Win2k.

      But like I said, I think actmaint is an in-house custom written program, so your argument is moot :).

  17. Re:NIS? by lowar · · Score: 3, Informative

    NIS???
    Maybe it will solve the single logon problem, but it's a nightmare from a security POV.

    Type "ypcat passwd" on a NIS enabled box, you will see what I mean...

    CU Micha

  18. I completely agree by Mdog · · Score: 2

    I did my undergrad. at U-Missouri - Rolla, which had mostly switched to Kerberos as I left. It was great, authenticate once, do what you want.

    I'm now at U-Illinois Urbana-Champaign, and for being such a well regarded school in computer science, I can't believe how many different identities/passwords it takes to get by here...it's a really big hassle. I pray for Kerberos :)

    1. Re:I completely agree by Waffle+Iron · · Score: 5, Funny
      I'm now at U-Illinois Urbana-Champaign, and for being such a well regarded school in computer science, I can't believe how many different identities/passwords it takes to get by here

      The way I understand it, UIUC is skipping Kerberos in favor of a new authentication system that they're developing. It is based on an advanced, self-aware AI technology, and it uses a voice-only interface.

      It was supposed to be deployed last year, but they are having problems with the beta systems; one system that controls pod bay doors has been especially trouble prone.

  19. Re:LDAP by bonius_rex · · Score: 3, Informative
    When you are mixing different vendor's LDAP implementations together, be real careful about who gets to keep the passwords. IIRC Active Directory stores passwords in a goofy format that nobody else can use, so you will need a product like "Microsoft Meta Directory Services" or Novell's "DirXML" to keep things in sync.

    Linux and Solaris are pretty easy to accomodate with PAM.

    Microsoft also makes a product called "Services for Unix" which will (among other things) make your Active Directory Domain controller act like an NIS server so you can setup Linux/Solaris boxen as slaves.

    Just make sure NOTHING transmits password across the wire in clear text. If everything uses the same username/password, a simple packet sniff can conpromise the whole works!

  20. Novell eDirectory by c-town · · Score: 4, Insightful

    Novell hasn't gotten much right except their directory services. By far, Novell NDS/E-Directory is the best you can get in the industry. If you just want password management, openldap is good enough. However, if you want better user/group/server/services/application management, give eDirectory a shot. There's nothing else better to manage mid-enterprise corporations. It really does kick ass.

    1. Re:Novell eDirectory by sphealey · · Score: 2
      Novell hasn't gotten much right except their directory services. By far, Novell NDS/E-Directory is the best you can get in the industry.
      Well, I would disagree with that first sentence a bit ;-)

      However, don't you know that your second sentence violates the Slashdot Code of Posting, which states that Slashdotters can never suggest a Novell (or Lotus Notes) product as a viable solution to any problem?

      sPh

      PS I think NDS/eDirectory would be an excellent solution to the problem stated - IF enough vendors would support it.

  21. Collective Technologies Does This by ayden · · Score: 3, Informative

    I attended an event in November 2000 hosted by Collective Technologies called Shared Authentication Solutions. Collective Technologies developed an in-house solution permitting single sign-on and application control. The tools used were:

    1. Win2k password server running Active Directory (which is really LDAP, with a twist) and the M$ bastardized version of Kerberos. Collective Technologies extended the Win2k password file with Active Directory to contain the usual UNIX password fields and the ACLs for each application.

    2. Solaris and RedHat Linux boxes running Kerberos, PAM, and LDAP.

    3. NT and Win2k boxes running either NTLM or the newer Win2k Authentication client.

    Once a user logged into any session on the Collective Network, they had instant, secure access to all the resources they were supposed to have, and no other.

    The only downsides to this entire setup I could see were:

    1. The authentication server ran on Win2k and not UNIX.

    2. The weak link in this chain was the Win2k authentication server. Collective Technologies suggested that their implementation relied on physically securing this one box in a locked server room.

    I was unable to find information on the Collective Technologies web site about this presentation. Please contact me if you would like more information and I'll try to dig up the documentation provided by Collective Technologies.

    --
    "I'm The Bounty Bear. I will find him anywhere. I'm searching."
    1. Re:Collective Technologies Does This by Trepalium · · Score: 2

      Microsoft has similar software for their Win2K servers. They offer MS Windows Services for Unix which can allow your Windows 2000 server to act as an NIS+ server (along with NFS, etc), and extends the Active Directory schema to support UNIX user attributes.

      --
      I used up all my sick days, so I'm calling in dead.
    2. Re:Collective Technologies Does This by aminorex · · Score: 2

      Now this is also only a partial solution, the flip
      side of the coin from my earlier post in this
      thread. SSH is essential for network
      communication. It is the single cross-platform
      standard that interoperates perfectly, without
      any realistic competition (certainly not Kerberos,
      which has vast administrative overhead by
      comparison). Any solution that does not address
      SSH does not provide single or even uniform login,
      as far as I am concerned.

      --
      -I like my women like I like my tea: green-
  22. Our Noc by BrookHarty · · Score: 3, Informative

    We currently use 3 headed Solaris Boxes, and for windows we use citrix. We use NIS and NFS to mount a shared binary directory. We have a program we run from a command prompt that will give us the username/password. You can only see the command from the shared directory, and its not shared with non-noc people. It reads a file thats encrypted and not readable by the user. You cant copy the encrypted password file to your local workstation.

    We do regular updates to passwords on routers/servers/etc. So we just update the file. Our NOC doesnt have root on the servers, they log into with a program that controls the permissions, kinda like sudo with server based auth. I dont want to mention the name of the program on slashdot...

    For our engineers, we use a program for windows called "WinSafe" that loads a shared .dat file (encrypted) on a windows share. The share is only available to the engineers. Like any program, if you use weak passwords, you can do a dictionary attack on it. Winsafe is freeware.

    Basically, a client program that reads an encrypted password file on an authenticated non-shared resource over an encrypted channel.
    -
    I have left orders to be awakened at any time in case of national emergency, even if I'm in a cabinet meeting. - Ronald Reagan

  23. So how do you... by fm6 · · Score: 2
    Don't say "Yellow Pages." Trademark. Lawyers. Cease-and-desist. You know the drill.

    I guess NIS is an obvious choice if you have a lot of Unix/Linux boxes -- especially servers. But what's the drill for enabling NIS network logins on Windows? Does it work if you have NT servers too?

  24. Shadowed password maps by Cadre · · Score: 2

    linvilaw@dogbert-/~-16:21% ypcat passwd | grep helldraw
    helldraw:x:20750:200:Lucifer Java Drawer:/home/mathcs/users/fall00/helldraw:/bin/tcs h
    linvilaw@dogbert-/~-16:22%

    It's not so bad with if you use shadowed password maps...

    --
    All editorial writers ever do is come down from the hill after the battle is over and shoot the wounded.
  25. Paper. by dsb3 · · Score: 2

    Easy! Just print them out on little sticky notes and keep them under your keyboard like everyone else.

    Now, you say that security is important. Always remember that if it wasn't you can always relocate the stickies to the sides of your monitor for easier access.

    --

    Slashdot? Oh, I just read it for the articles.
  26. Human readable databases are needed too by Snow_Bonobo · · Score: 2, Insightful

    I think the question isn't so much about storing passwords for systems to use, such as in LDAP or NIS directories, but about storing passwords for humans to access. The other half of a password system is also very important.

    Directories like LDAP, Kerberos and NIS can reduce the number of passwords on a network and make maintenance easier (normal users can have one password for all systems they access) but there will still be many passwords. It's a very bad idea to give every workstation and server the same root password, for example.

    Ordinary users can get by with one universal password for their network identity, but for system administrators it can be a nightmare. I've got about 130 passwords to keep track of.

    The best solution I've come up with so far is to use cheap Palm PDAs to store the passwords, encrypted and locked with a good password itself, on special password storage apps. Each sysadmin can have a PDA with just their passwords on it. For about £80 each it isn't cheap, but it's a lot better than using password potected Word files, which I've seen other companies using. Don't use the Palm's own "secure" storage, it's useless for things that need to be really secure.

    I'm still looking for a better solution - some way to store the passwords centrally and distribute them to each PDA depending on the requirements of each sysadmin would be great.

    Of course, the way that passwords become so cumbersome in large quantities just shows how flawed passwords are. Hopefully Kerberos will catch on more - the advanced features of Kerberos help reduce the number of passwords needed.

  27. There are many ways of doing this.... by Fnord · · Score: 2

    It all depends on what kind of machine you want to host the passwords on, and how much functionality you want on the clients. If you're okay with using a UNIX machine for the server, then the most optimal solution is to put either an LDAP or NIS server on there (personally I'd suggest LDAP but that's a matter of preference) and have UNIX machines authenticate off of that. Then you also put Samba on the server an use it to create an NT domain. Then with a clever stacking of PAM modules on the server side you can make it so that any password change requests for either LDAP or Samba propagate to the other. This does require you to create each account twice (once in the LDAP directory and once in the smbpasswd file), but its a one time hassle.
    On the other hand, if you're forced to use Windows on the server (maybe Samba doesn't quite do the domain tricks you want it to), then there is a PAM module distributed with the samba project called pam_smb. It should work on any PAM enabled UNIX and should allow you to log into UNIX machines using domain usernames (as long as samba is installed on the unix machine and configured to be part of the domain).

  28. Yuppers: LDAP can do this. by JDizzy · · Score: 2

    It can slice, it can dice, it can keep track of your credentials across your heterogeneous environment. It can be a repository of key-pairs, a DNS cache, an address book, or a database of your favorite mp3's. However, the most common use of LDAP is for your HOST files, and your PASSWD database. NIS cannot do that, it only has a single domain. You have to write scripts to sync the various NIS domains, or use NIS+. NIS+ can handle multiple domains (aka authentication realms) but cost money, and is a bit more complex. Besides, Sun Microsystems is dropping development of NIS. Another item of interest is using an SQL server as the authentication core. For example, ProFTP can use MySQL to authenticate. Since you can have a centralized DB communicate over SSL, this can be done relatively securely on Unix. Microsoft is the wildcard. They are a closed system, and getting at the sources (aka the PAM like things) is not easy. However, this is when LDAP comes into play. Since Microsoft dropped their crappy NT4 domain structure in favor of Active Directory (LDAP). Samba + OpenLDAP can be configured on a Unix box to sync up with active directory, or it can be made to host the active directory, and push the mess out to the NT authentication realm.

    --
    It isn't a lie if you belive it.
  29. IBM Redbooks by fm6 · · Score: 3, Informative
    Karma Whore!

    Well, I shouldn't complain, since you helped me find the Redbook web site. But you have to admit you're just barely on-topic. And it would have been more useful to point to the main page for this Redbook, which includes various useful links, including an HTML version, the FTP directory for related files, a place to submit review comments, and other good stuff.

  30. Re:NIS? by typedef · · Score: 2, Insightful

    NIS isn't that bad, as long as you don't use it as the primary authentication service, and just use it to distribute user/group information across the network. On my network, I have the password field for each user in NIS set to something that dosen't map to a real password (i.e. +++) and I've configured PAM on all hosts to autheticate via Kerberos. Once they've obtained a set of credentails from the KDC, thier group, home directory, shell, etc is obtained from the NIS database. You can accomplish basically the same thing using LDAP to distribute the user/group information, and theoritically (I haven't tried this personally) you could get this all to work out of the box using a Win2k box with Services for UNIX installed. AFAIK, PAM ships on Solaris and most Linux distros, so implementing this on the client end of things shouldn't be too much of a problem either.

  31. Re:LDAP by Anthony+Boyd · · Score: 5, Interesting
    LDAP is very scalable with an extensible schema, and can provide support for more then usernames and passwords.

    I think Pat Jensen has really got some good advice here. At SST, we're slowing moving to a "universal login" system for our Web sites. There are about 5 internal & external sites, each requiring different usernames & passwords. Our solution is to set up a MySQL database with login data and nothing more, and then each Web site will check for a cookie (MD5 hash with IP addy, so the cookie is difficult to spoof). Since all our sites operate under sst.com, they should all be able to view the cookie and verify it.

    However, and as an inevitable side-effect, people are now asking why we can't use that same system for NT logins and Outlook and yadda yadda. If we had chosen LDAP, this would have solved the issue, as LDAP can be plugged into a bit more than MySQL can. We will still do this, it just means we have to revise, revise, revise. I have yet to look into how well PHP and ASP support LDAP, and just how much LDAP can do, but it appears to be much more in line with our needs. Can anyone speak definitively about what PHP and ASP and NT and Outlook can do with LDAP?

  32. cfengine also by rm+-rf+/etc/* · · Score: 2


    Here's my take... LDAP in my opinion is not ready for prime time. It's going to be a great solution, but right now different implementations don't always play nice. For example, solaris includes LDAPv3 but not ssl support (which, ssl is part of the v3 spec...). Who knows how nice these things play with NT/2000 as well.

    Kerberos is great, however it's also somewhat complex and has the added problem of needing users to switch to kerberized versions of applications (or setting up some tricks to use normal access methods but having the servers authenticate against kerberos). It's worth investigating, but it's non trivial in my opinion.

    NIS, well, let's not go there.

    So what we do is use cfengine (http://www.gnu.org/software/cfengine), which is basically a client/daemon system to sync configurations across different machines on a network. We keep our real password file seperate, and then use cfengine to copy it around to all clients when it changes. Of course the real benefit to cfengine is that it allows you to do much much more (for example, we keep all modified config files and programs in a cfengine tree and when we install a new machine, just run cfengine and it's customized automatically).

    For the windows machines, you can throw a samba server out there to act as a PDC/authentication machine.

  33. really, seriously look at eDirectory by deviator · · Score: 3, Insightful

    LDAP is a great idea, but it's only half of the problem - it specifies the cross-platform interface, but not the database to store that information in. OpenLDAP sounds like a step in the right direction.

    MS has their ActiveDirectory that fully supports LDAP, but the database is very Windows-centric and you'd be taking on all of Microsoft's security issues related to hosting ANYTHING on a Win2K server.

    Really, seriously, definitely have a look at Novell eDirectory (a.k.a. NDS) as your foundation - replicas of NDS partitions can be *hosted* on Solaris, RedHat Linux, Netware, NT and Win2K (note: you do NOT NEED A NETWARE SERVER ON YOUR NETWORK TO RUN eDIRECTORY! :) You can use the proprietary Novell client software for various OSes to access this information, or make standard LDAP calls to it.

    NDS (the database part) is dynamically extensible, totally replicated (for performance and auto failover) & almost completely automatic... very little maintenance is required. It supports hooks for almost all OSes for authentication (look at Novell Account Manager for Linux & Solaris, for example) and directly supports smartcards/biometric/SecurID/etc. It's "light" meaning you wouldn't have to dedicate entire servers to host the information. The security is awesome and the you get very fine-grained control over everything. It's relatively inexpensive these days, too. (You can practically get it for free if you're a developer - check the website for a free eval copy, too)

    These days, Novell also has all sorts of whiz-bang products (i.e. DirXML) that integrate with eDirectory - do bulk-loads or automatic synchronization of other proprietary directories using your own XML interfaces. They even have a bunch of tools & apps that let you take existing apps and set them up as "single sign on" so you don't have to keep track of multiple passwords for multiple databases.

    The other advantage is that Novell has about ten years of lead time over everyone else's directory implementation right now.. I'm lucky enough to have had a chance to play with NDS on several large networks and continue to be amazed at the technology behind it.

    more info: http://www.novell.com/edirectory

  34. what about delegation? by CoughDropAddict · · Score: 2

    Here is the situation I am in, and LDAP doesn't accommodate for it well:

    I work in the Advanced Computing Lab. We get the list of usernames and passwords from a university-wide LDAP directory.

    However, only a subset of the university-wide accounts should be able to log into the Advanced Computing Lab (this is mandate from the department head). We don't want to have to modify some property in the global directory to make this distinction, we need to be able to locally define this subset.

    From what I can tell, the only way to implement this functionality is to use the LDAP concept of "chaining," however OpenLDAP doesn't seem to support this yet.

    This seems like a very common situation, why is there no easy way to accomplish this??

    1. Re:what about delegation? by CoughDropAddict · · Score: 2

      I wouldn't call this delegation proper---the problem being that LDAP has overridden the generic term with their goofy concept.

      Sorry, I wasn't using "delegation" in a technical sense, but in a political one. I want the global directory to define the list of usernames and passwords, but I want the decision of which accounts to recognize to be politically delegated to me as admin of the local server.

      Instead, what about using LDAP for authentication and identity mapping, and then writing your own application permissions map
      (perhaps even using LDAP, but using the app to link the two, not chaining) with an admin interface? More work but it will be much
      easier to administer.


      If I understand what you're saying, we would have to write client code to support this. Since there would be a diverse mix of clients, I want to keep as much of the intelligence in the server as possible, so that client-side LDAP authentication modules will work out of the box. The alternative is maintaining 5 different versions of the client-side code.

  35. Re:Use the same password for everything by logicnazi · · Score: 2

    While this may sound stupid, why not? I mean you don't incur any additional security risk vs. using a password server (if any machine is hacked to which you later log in the hacker has access to all your machines). Yes if you try to change your passwords all the time this might get to be tiresome...but it would be alot of work to set up this server maybe it would just be better to walk around and change 15 passwords once a month.

    --

    If you liked this thought maybe you would find my blog nice too:

  36. Single Sign On by YakumoFuji · · Score: 2

    you want an SSO. I'm looking into this for my work. I want to be able to use our NT logon password for all things, so when it changes in on place, its changed for all. that covers logging into our AS400's, NT boxes, and our apps. Most people skip over the apps and just do central box logging, which is only 3/10'ths the problem.

    eg: one of our apps requires this;
    log onto box (nt/unix whatever) -> log into application -> app logs into db server (as400/db2) -> app also logs into 2nd db server (essbase).

    there is 4 passwords righ there!

    making inhouse apps support LDAP is easy, making 3rd party apps support it is hard. lucky our tivoli servers, essbase, as400's, nt boxes can all support ldap.

    I suggest you do a lot of research befor jumping into any one solution.

    (and dont buy into passport as an SSO option! licensing is $$$$ for passport.)

    --

    no sig for you
  37. good luck by Chundra · · Score: 5, Interesting

    I see many folks saying to stick with just kerberos, or just LDAP or even Active Directory. I work at a largish university and had to come up with a roll your own solution a while back mainly due to political reasons (the NT group would only use Active Directory, the UNIX guys wanted Kerberos, the dialup used Cisco Secure, other systems stored digested passwords in an oracle table, some things required LDAP, etc., etc.) What we decided on, and what I wound up writing was a bunch of perl code to synchronize ALL of these different schemes. We have upwards of 50k users, and we've been using this for 3 years now with no problems.

    Then again, this is a university where we basically provide services that faculty request and we don't have the luxury of not using software x because it uses authentication scheme y and we only support authentication scheme z. If you have a situation like this, it isn't that difficult to come up with the glue you need.

    1. Re:good luck by CowbertPrime · · Score: 2

      that works. However, our centralized system is THECICSLDAP authentication provided by our VM/CMS systems running on S/390. Our primary difficulty is lab logins to win2k. We want to have students (25000) able to log in to win2k workstations but authenticate to their accounts on the S/390, since every student has an S/390 account and university email there. How would LDAP running on VM/CMS interface with active directory on win2k? We surely don't want to sync 30,000 accounts on the win2k PDC.

    2. Re:good luck by Chundra · · Score: 2

      Well that's definitely an issue. :)

      Basically what we do is use a data warehouse that contains faculty & staff data from human resources plucked from peoplesoft, and from CICS for students. We treat that as the definitive list of who should have accounts (at least on the high volume everyone-has-an-account machines). The vast majority of our machines rely on LDAP, Kerberos, Active Directory, and NIS. So on the relevant boxes we have some perl scripts that run daily and pull a list of users from the database that should have accounts, as well as a list of users using that particular authentication scheme. From those two sets we can trivially create and delete the various accounts that should be created/deleted.

      Changing passwords on all these systems is pretty simple too. The users hit an ssl webpage which authenticates through kerberos and then goes out and hits various machines using whatever hook is appropriate (some use Net::SSH::Perl and login to a box and call some sudoed program, some use Radius, some dump an md5 digest into a table, etc.).

      Admittedly, if a user changes their password on one machine e.g. via passwd it's not going to propagate out to every other machine, but we also don't want to *force* users to use a single sign on either.

      I don't think this is the *best* scheme out there, but it works a lot better than I would have ever imagined when I wrote it. The big pluses as I see them: it's easy to integrate new software into the scheme that doesn't use ldap, kerberos, active directory, etc. (stuff I've done recently: imp/horde web based student mail, blackboard courseinfo), if a domain controller or kdc or whatever goes down your whole authentication scheme doesn't go down the tubes until it's fixed, and last but not least just about everything uses ldap, kerberos, active directory and nis. Take your pick. :)

    3. Re:good luck by Chundra · · Score: 2

      Hmmm. Thanks, but I'll leave that to whoever comes in to take my place. I hate my job and am currently looking for something else.

      Fucking economy.

      Anyone hiring? :-D

    4. Re:good luck by jonabbey · · Score: 2

      Or Ganymede, which is designed for the same purpose.

  38. Re:Use the same password for everything by cicadia · · Score: 2
    While this may sound stupid, why not?

    As long as all of your password-authenticated services are controlled by the same authority (i.e., the same company), there is no problem with having a single password for all of them. It may even be more secure to have a single properly administered password database than to have each application managing its own database.

    The reason security experts always tell you not to use the same password for everything is that most people have passwords for services from many different organisations, each with its own password database. If any of these databases is compromised, then someone may have access to all of your accounts.

    As long as you have one identity in a single security domain, there is (usually) no reason to have multiple passwords.

    --
    Living better through chemicals
  39. Two that might work! by kwishot · · Score: 2

    vi and notepad! =)

  40. use your Thumb and Retina ! by da5idnetlimit.com · · Score: 2, Interesting

    Well, get 1 thumb scanner, one retina scanner , get both systems to generate one signature and find a crative way of mixing the numbers (Prime Exponential is good 8)

    if this third number correspond, give access.

    Retina + Thumb scan supported under Linux (Unixs) and Windows.

    Just a bit steep on the budget part, but damn efficient.

    Oh yes. Get at least TWO redundant password / verification servers, if possible one offsite.

    Why ? Gess 8) a whole company unable to connect because one poor server went dead ...(actually seen at the workplace... Pass server down. Please have a cup of coffee 8)

    --
    It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
  41. Authentication vs. Authorization by Fastolfe · · Score: 3, Informative

    It sounds like you need to break out your authentication from your authorization a little. Unless you need to replicate user records for availability reasons, keep them on the master servers. On your LDAP servers maintain a group containing a list of those users that are permitted access to your systems. Link them together using LDAP referrals (main organizational server delegates to your server for your organizational unit, and your server refers unknown requests to the main server).

    When the user tries to log in, they'll be authenticated from the central servers, and authorizated to use the servers based on whether or not they're in the group.

    1. Re:Authentication vs. Authorization by CoughDropAddict · · Score: 2

      Thank you for your reply.

      Let me see if I understand what you mean. I'll call our local LDAP server A and the global LDAP server B.

      Someone tries to log onto a computer in the Advanced Computing Lab. The LDAP authentication module sends the username and password to server A. A looks only at the username, if it's not in the local group of approved users it denies access, if it IS in the local group of approved users, it refers the client to server B, saying "if the password matches, approve it."

      Is that right? Would OpenLDAP support the server side of this? Would most LDAP clients support the client side?

    2. Re:Authentication vs. Authorization by Fastolfe · · Score: 2

      It's up to your application to determine whether that authenticated user is authorized to do what it is he's requesting to do. You do an LDAP 'bind' to perform the authentication, and if you wanted, you could perform another LDAP check (e.g. presence in a group) for the authorization.

      Say you have a LDAP hierarchy like:

      o=Foo,dc=example,dc=com

      And you have your organizational unit:

      ou=Bar,o=Foo,dc=example,dc=com

      Your local servers (A) handle this suffix, and refer everything else to the main LDAP servers (B) that handle the root suffix further above. A client (your OS, C) would make a request like this:

      Step 1: Authorization
      C -> B* (who's uid=example?)
      B -> C (dunno, let's ask A)
      C -> A (who's uid=example?)
      A -> C (it's uid=example,ou=Users,o=...)
      C -> A (I'd like to bind as uid=example..)
      A -> C (OK, the password was right)

      The OS now knows that the user claiming to be 'example' really is 'example'. But we still don't know if the user is allowed on this system.

      Step 2: Authorization
      C -> B* (is 'example' in the group cn=Authorized Users,ou=Bar,o=...?)
      B -> C (yep.)

      The OS now knows that the user is allowed to use the system.

      Realistically, if you have your referrals set up correctly, where you send unknown requests to the main server, and the main server knows to delegate that LDAP suffix to *your* server, the initial request can go to either your local servers or the main LDAP servers, it doesn't matter. (In theory, it's like DNS, where your resolver can hit the local name servers, but realistically it can hit any name server in the world and it'll get referred to the right place eventually.)

      There are other ways you can do your authorization, though. My main point was that you needed to break these two concepts apart. Let your main LDAP servers do the authentication, and do authorization in a second step.

  42. Re:Use a fricken database by __past__ · · Score: 3, Informative
    First of all, using an RDBMS is not an answer to this question - just storing your password(s) somewhere will not automagically make it possible to actually use it for login

    However, directory services are better suited than classical RDBMSes, because they are optimized for fast lookups. An RDBMS in contrast focuses on concurrent updates - all this ACID stuff is basically not needed if all you want to do is providing authentication services (as long as you don't frequently try to update your password from 10000 workstations at once).

  43. Kerberos, Plain and simple. by SuperBug · · Score: 3, Informative

    It is a bit difficult to get working, but it is "strong", centralized, password and user management.

    The only thing I've found missing from kerberos, is simplified high-level documentation in a cook-book format for different ways of implementing and administering the KDC and the realms.

    Fortunately I'm working on such documentation, and it may become part of the FAQ. After I make some adjustments, maybe it will.

    --
    --SuperBug
  44. Dont use passwords.... by Llanfairpwllgwyngyll · · Score: 4, Interesting

    Password management like this is a nightmare. Some of the options suggested (LDAP, SecurID etc) rely upon the system you are accessing being able to talk to an external authentication system of some sort.... which means you're up a certain creek in a chickenwire canoe if that facility isn't working.

    SSH with RSA keys. Change the management problem into the simpler (and more scalable) one of managing RSA public keys on the boxes (which can be automated).

    Job jobbed.

    1. Re:Dont use passwords.... by aminorex · · Score: 2

      That's fine for remote logins. It doesn't address
      the central problem as posed, however, which is
      to gain access to a system via it's primary
      interface, not via network-only interfaces. You
      can't use ssh to authenticate for windows 2000
      login, for example, nor to authenticate to a web
      page. I wish that you could. SSH is essential.
      Any system that doesn't address SSH authentication
      is partial at best -- as for example, LDAP.

      --
      -I like my women like I like my tea: green-
  45. it's a losing battle by mmusn · · Score: 3, Interesting

    Even if you can control the logins on the major operating systems, your users will still encounter other passwords everywhere. I think rather than trying to control the uncontrollable, a better solution is to get them Palm Pilots with encrypting password managers.

  46. Re:LDAP by Paul+Jakma · · Score: 2

    openldap has a mysql backend. so you could write the glue to export the mysql data via LDAP.

    --
    I use Friend/Foe + mod-point modifiers as a karma/reputation system.
  47. Re:NIS/YP..Secure? by GrenDel+Fuego · · Score: 2

    Holes in Kerberos? Are you referring to Krb4 or Krb5?

    If it's krb5, what holes are you referring to?

  48. Novell eDirectory by VikingBrad · · Score: 2, Insightful
    Novell does many things wrong but their eDirectory ( http://www.novell.com/products/edirectory) product is clearly the leader

    It runs native on Windows NT4, 2000, Linux, Solaris, AIX and Netware 4, 5 & 6.

    It also is LDAP 3.0 compliant and is managed through a Java-based console that will run on any platform with a JVM.

    It also has flexible Authentication extensions and Account Management for Windows, Linux & Netware that enable administration of file system shares.

    And for all that developers can bundle a 250,000 user version of eDirectory with their Apps for free (http://developer.novell.com/edirectory/)

    Although its not open-source it should be bundled with Linux distributions targeted at large organisations to provide a scalable, cross-platform secure directory system

  49. NIS... by capsteve · · Score: 2, Interesting

    is your friend. LDAP could be your friend as well, but the adoption of NIS by the major unices, and it's strong connection with NFS make it an ideal solution for one login/passwd for multi-server authentication, and email.

    we used to authenticate via NIS+(before we were purchased and told we were going to LDAP, still waiting after three years, but that's another story...) and i loved it! we were a prepress company with 6 seperate locations and several dozen servers scattered thru out the enterprise serving appletalk, email, home directories, and data collection. no matter which location you were at, you could use your single login/passwd to login to any other server, mount you home dir, and go about your business.

    it took a bit of end user training(users wanting to save their mail on local drives instead of home directories, among other issues) but it was well adopted, and easy to maintain thru sun's solstice frontend.

    the environment was hetrogeneous(solaris, aix, irix, linux, nt, macintosh) and all machines authenticated nicely, with the exception of earlier windows machines. had we deployed samba we would have had an easier time.

    beware the difference of NIS and NIS+: NIS+ was sun's "updated" version of NIS. NIS is far more open and friendlier than NIS+... the irix and linux boxes preferred plain NIS.

    the best benefit was the ease of administering the end users. one entry change propogated thru all machines... no more rushing from box to box when someone was getting canned. user can't remember email and filesharing password? no problem.

    wan to migrate to LDAP cause NIS doesn't have everything you need? no problem with that too, tools exist for easy migration.

    --
    three can keep a secret, if two are dead - benjamin franklin
  50. Samba by Gerdts · · Score: 3, Informative

    Samba is well known for its ability to act as an NT File/Print server, but it can also act as a primary domain controller. I believe that its PDC capability along with its Unix Password Sync functionality will allow you to accomplish most of what you want. Alternatively Samba also comes with windbindd which allows you to have your Linux and Solaris clients participate in an NT domain.

    With Unix password sync, you are likely to be tempted to use NIS to distribute your passwords to your Linux and Solaris clients. While that would work just fine, NIS is known for its lack of security (search for my other post on this subject). If you use NIS initially (potentially to integrate with your existing NIS environment), consider shifting over to LDAP. Samba 2.2.x has had significant work done to provide integration with LDAP. Check the docs for the latest release and the samba mailing lists for details.

  51. PasswordCourier by kwelch · · Score: 3, Informative

    Check out PasswordCourier (Warning - Flash required). I know it works well - I work there :-).

  52. putty by morgajel · · Score: 2, Informative

    putty is a good ssh client for windows- I'm not sure if it's what you meant tho... really configurable, and we we normally reccomend to freshmen who are still using telnet.

    --
    Looking for Book Reviews? Check out Literary Escapism.
  53. SeOS by Anonymous Coward · · Score: 2, Informative

    I'm a systems administrator for a large telco. We use "SeOS" on most of our boxen. http://www.astrom.se/cai/etrust/ac/index.html

    It's not bad and it allows such functionality like allowing certain groups and users trusted su capibility. Performs scheduled required password changes and other fun stuff..

  54. P-Synch by shking · · Score: 2, Informative

    M-Tech, a Calgary company makes P-Synch, a cross-platform password management system. P-Synch supports over 60 types of systems including: Unix servers, Windows NT, Windows 2000 active directory, OS390 / MVS mainframes, LDAP directories, email, groupware and popular ERP applications, such as SAP and PeopleSoft.

    M-Tech showed P-Sync off to the Calgary Unix Users Group last year. When I saw your story, I immediately thought if them.

    --
    -- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
  55. The Passphrase Method by _Sprocket_ · · Score: 4, Interesting


    2.passwords should look like they were randomly generated (esp. no English words)

    ...

    ...there is no way I can memorize a 10+ randomly generated strings. Aren't security experts being a little hypercritical?


    Use a phrase to generate a suitable password. Try and use a phrase that has something to do with the system. For example, a server at a company office. "This building has 8 floors and 3 elevators" could generate "tbh8fa3e". Not bad. We can improve it by adding caps and some substitution: "TBh8f&3e". Now we have a password with mixed case, alpha-numerics, and non-alpha-numeric characters with a random appearance. And it has meaning to the user in the form of a phrase that can be remembered and repeated to regerate the password.
  56. Try this by crivens · · Score: 2, Informative
  57. Cross-Platform Password Database by SkewlD00d · · Score: 2

    Pencil and paper.

    To backup, simply hit [COPY] on the copying machine! Want security you say? Simply buy a safe and install your database there.

    --
    The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
  58. LDAP + non-PAMified systems by chrysalis · · Score: 2

    LDAP is a nice answer. Because it's simple, extensible, and supported by a lot of operating systems and daemons.

    But there are exceptions. Like BSD systems, that don't provide nss_* hooks (unlike Solaris and Linux). PAM isn't enough. PAM only provides authentication. It doesn't provide home directory, shell, gecos, etc.

    Does anyone know of a library (that you preload with LD_PRELOAD) that replaces getpw*() functions with LDAP lookups, and that would work on BSD systems?


    --
    {{.sig}}
  59. Re:NIS/YP..Secure? by Ewan · · Score: 2

    NIS does indeed have that security problem, and it cant be avoided as far as I know.

    NIS+ is not as vulnerable, but not as widespread either.

  60. Ganymede by jonabbey · · Score: 2

    Take a look at Ganymede.

    Ganymede is designed to provide a single multithreaded network directory store for (among other things) password information, then to write out datafiles and runs scripts to propagate your directory information into your environment whenever a user commits a transaction to change anything.

    Ganymede is useful for people who want to unify differing directory mechanisms, and who don't need a full hierarchical domain structure like those supported by Active Directory or Novell's eDirectory products.

    We use Ganymede to synchronize passwords across UNIX NIS, Windows NT, Samba, Apache, and more. We have a userKit that provides for password management across NIS, NT, and Samba 'out-of-the-box'.

    That said, Ganymede is mostly useful for people who can't force-fit all their clients to use one network authentication system, although it does provide a very high level of convenience and hand-holding for your users.. Ganymede has support for setting expiration dates on accounts, and for sending email when an account is about to expire, etc. It also maintains full auditing trails for everything, and allows controlled delegation of permissions to administrators.

    If you can live within the limitations of its orientation around a flat namespace, Ganymede's flexibility makes it hard to beat.

  61. P-Synch allows cross-platform password synching by UncleDuncan · · Score: 2, Informative

    There was review in Linux Journal back in 1999 of a product that addressed this problem:

    http://www.linuxjournal.com/article.php?sid=3040

    The company is M-Tech http://www.m-tech.ab.ca/, and they have a product called P-Synch that allows you to do cross-platform password syncing.

    I've never used p-synch. We use openldap instead of a commercial product, but we don't use it for root passwords. Seems to me to be a security risk to have root the same on all boxes. You might be better served by having some sort of password scheme/algorithm rather than a common login, especially if the issue is being able to remember the password, rather than ease of mass changing/syncing of passwords.

  62. Re:kerberos and development by cymen · · Score: 2

    This looks to be one place to start:

    http://www.lsa.umich.edu/lsait/default.asp

    Do you have anymore?

  63. Aaaaarggghhhhhhh!!!!! by juliao · · Score: 2
    Please, not NIS... I'll do anything you ask, bot _NOT_ NIS again...

    Oooohhhhhhhh, the undead are rising.......

  64. Did anyone read the article? by Diamon · · Score: 2

    The original poster is asking for a system to store passwords not an authentication mechanism. Every post rated 4 or above is suggesting Kerberos, SSH, LDAP and other authentication mechanisms, all of which are off topic for the post.

    There were a few on topic replies suggesting web servers etc, unfortunately they were never modded high enough, and unfortunately I have no mod points at the moment.

    1. Re:Did anyone read the article? by Diamon · · Score: 2
      Yes.
      With all of the servers, routers, and various other protected systems we have, the sheer quantity of passwords is mind-bogglingly difficult to keep track of in a secure fashion.
      It's kind of obvious the poster is trying to keep track of passwords not authenticate passwords.
  65. Meta-meta .... by fm6 · · Score: 2

    No wait, you're an AC. Never mind.

  66. Re:Another "Ask Google" question? by autocracy · · Score: 2

    I think perhaps it was meant more to see what was missed. And to get a view of the responses. I would have to say that kerberos/ldap seem to be popular. I now have more of a background and some actual user opinions and experiences. Very helpful in a decision.

    --
    SIG: HUP
  67. Re:NIS/YP..Secure? by GrenDel+Fuego · · Score: 2

    I'm probably wasting my time posting a reply to an old article, but kerberos dosen't trust anything, machines, users or servers.

    The user must authenticate themselves to the kerberos server to recieve a ticket. The service you're trying to use has to authenticate itself to the kerberos server as well.

    Check out http://www.isi.edu/gost/brian/security/kerberos.ht ml for information, or http://web.mit.edu/kerberos/www/

    And as an FYI, MIT uses krb5, not krb4. krb4 is broken by design and considered "DEAD" when it comes to development by MIT.

  68. eh? by jonr · · Score: 2

    Maybe I'm misunderstanging the problem, but wouldn't a secure webpage with all your passwords be enough. Only thing that I can think of against it, is that people can peek over your shoulder.
    But the web is 100% cross-platform. (Isn't it?)

  69. Re:NIS/YP..Secure? by GrenDel+Fuego · · Score: 2

    That's the same with EVERY form of authentication. If you type a password into a compromised machine, your password can be compromised. It's not really a flaw in the protocol itself.