Suggestions for Company Wide Password Vault?

androidtopp asks: "My company, an IT and business consulting firm of around 150 people, is looking for a Password Vault/Manager/Database solution to manage the numerous passwords we've developed in the course of a major internal network and server upgrade. Our must haves are multiple privilege levels (I don't need to see network passwords, and the network guys don't need to see database passwords, and so on) and it would be nice if we could view when people last retrieved each password. Does anyone manage passwords in this fashion at their work/home? A lot of the free password managers are one user, full access, which is a little less secure than we need. How do other companies (small or large) manage the hundreds of server, network, database, and application passwords that must crop up?"

Comments

Isn't that idea flawed?

[neoform]

Seems to me, saving every password in a company in a central location would be the first place any hacker would go after.. and should they gain access.. you can say goodbye to that company.

Re:Isn't that idea flawed?

[QuantumRiff]

Um, no. That idea is the central idea behind Active Directory and Novell eDirectory. Its much easier to secure one thing, than lots of excel spreadsheets, stickies on monitors, etc..

At my company, we have been working to get everything integrated with Active Directory, so there is only 1 password to manage. Redhat boxes will authenticate against an AD domain now. Just a few more apps to go.

Another solutions is the Microsoft Identity Management server (I think thats its name) that you can actually script password changes. For example, a user does Ctr-alt-Delete and changes their password, then the IM server grabs that, and you script it to connect to your DB, log in as the user, and change password, do the same for web pages, etc. Looks pretty sweet, but we can't afford it.

Re:Isn't that idea flawed?

[Allador]

There are certain industries or business types that need this, however, and his (and mine) are of this type.

Take an IT services & consulting company, particularly one that specializes in small businesses.

You build out everything from domains, to webservices, to firewalls, to wifi, to email hosting, and beyond.

Just take the wifi situation, for example (though it generalizes to most of the other cases). You've built the wifi, and you have the admin password to the wap, and documentation about how it is configured. You have this documentation because you only are there once or twice a year, so wont remember, but you need the access information when you do go.

The business owner, given that this is a small business with no IT shop, doesnt have a clue, and doesnt need or want to know the password to the wap (though you give him a sheet with it anyway).

So when you go there to deal with wifi issues, or anything and just need to get on the wap, you need the login.

The same applies to their DC or SBS server. You dont want their domain connected to yours, but you need to be able to get into it when you do need to service it.

And if they choose to retain us for continuous monitoring and management of their IT infrastructure, then we need to be able to VPN in to their office and access their equipment for service.

But the GP's situation is not unique. For example, how do you give just enough information to your contract employees (or other young, not fully vetted staff) to let them do the work, but not really put your client at risk?

We're looking at Smart Cards for this, as we deal with a nearly 100% MS homogenous client-base, but its not an easy problem to solve generally, while providing audited and progressive disclosure of sensitive information necessary for these people to do their jobs.

Re:Isn't that idea flawed?

[styrotech]

This isn't really a single sign on need as far as I can tell.

Sure SSO helps out heaps with access control on all the machines on your LAN, but there are a ton of other passwords a typical IT team will need to keep track of that it can't help out with. eg passwords for domain registrars, CA logins for SSL certs, logins for supplier or partner extranets, DMZ or externally hosted servers, any lower end network devices that can't integrate with your SSO system, AD recovery accounts, local admin accounts, all those unix services that can't/won't integrate with SSO etc etc.

Re:Isn't that idea flawed?

[yancey]

And at my business, we use Novell's eDirectory 8.8.1 product running on SuSE Enterprise Linux 9 and Novell Identity Manager to synchronize passwords in real-time (event driven) to Active Directory, other Novell eDirectory systems, Oracle and MS-SQL databases, PeopleSoft and other systems, some in different cities, all secured with SSL connections. Our system holds over 300,000 accounts, with about 60,000 of those being active. I think we expire about 300 passwords a day on average.

A recent Infoworld article ranked it very highly. Novell Identity Manager is very flexible and powerful product and I highly recommend it, especially if you're not a huge fan of Microsoft. Storing passwords in a centralized system is a valid solution as long as your "identity vault", to borrow Novell's term, is properly secured. Personally, I could never feel safe storing all our passwords in Active Directory. Besides all that, I don't have to worry about the critical security patch of the week since it runs on Linux.

Re:Isn't that idea flawed?

[Dadoo]

get everything integrated with Active Directory, so there is only 1 password to manage.

That's fine for your internal passwords, but having a single password on systems that are less secure - say, those in your DMZ - is risky, especially if it's the same password on your internal systems. If someone hacks just one machine, they'll be able to access them all.

Re:Isn't that idea flawed?

[Nurgled]

Indeed. At my (relatively small) company we attempted to go down the "single sign-on" route as a solution to the plethora of passwords. We quickly discovered that this isn't a magic bullet: as a company that does IT support for other companies, we have accounts on a lot of systems that aren't our own, and thus won't integrate with our directory service. In some cases, we are issued a password and offered no ability to change it. There's also our off-site hosting servers which, since they aren't in the office, can't reliably authenticate against the directory.

These alien accounts were, for ages, getting stored in clear text in the company's CRM system. This seemed really distasteful to me, so eventually I just rolled a simple password storage system myself. It's not brilliant, but it's certainly better than what it replaced: each account is associated with a "master password", and that password is used as a key to encrypt the account details. There are multiple master passwords, in an attempt to limit what each person has access to; we only issue a particular master password to those users that need access to the information it protects. Everyone still knows the one master password, which is a flaw in the system, but it's certainly better than storing them in Excel spreadsheets, Post-it notes, or in the CRM system in clear text.

One thing I would like to add is individual access control per-user rather than the shared passwords, especially since we've recently let go a disgruntled employee and changing all of the passwords was laborious. However, I've not yet figured out the best way to approach the problem of encrypting it so that the right people can decrypt it but the wrong people cannot, in a way that allows us to simply revoke one person's access without affecting everyone else.

How everyone keeps their passwords..

[JDark]

Buy bulk post-it notes and a novelty sized keyboard.

Several lockable closets

[TubeSteak]

Each closet will have a whiteboard.
Each whiteboard will have post-it notes covered in [database/network/other] passwords.

Hand out keys.
Key the locks so that only the people who need to have access to the closeted passwords can open the door.

Problem solved. Right?
And you don't even have to get rid of the post-it notes.

ACL

[larry bagina]

you can fake it with Linux and sudo (or multi-group support), or Windows ACLs.

That's exactly what it was designed for.

PHB to the max.

[no_pets]

Sounds like a PHB came up with that. It's the same thing that a PHB I used to work for did. CIO puts all passwords into an Access database that is password protected then places it in his own, higher level private share on the network. Each password is actually entered in a "secret" code that all IT employees are aware of just in case it is hacked. The CTO also has access to this database.

It's current for about 30 minutes at which point it begins to become outdated as passwords are changed.

Good luck.

Re:PHB to the max.

[MyLongNickName]

And, he is aware that there are about five million products that can crack an access database in 10 seconds? Can you name your company?

First, make sure security policies are sane

[LunaticTippy]

If you are requiring complex passwords that expire every 30 days, maybe a more relaxed approach will enhance security. It's more secure to have a sane policy than to have stickies with passwords on every monitor.

As far as a "vault" I suggest an encrypted piece of paper kept in your wallet. I abbreviate made-up words to the first character. If someone can figure out that 23T~ is 23Trimble~ they deserve to get in to my shit.

Re:First, make sure security policies are sane

[Control Group]

That reduces the complexity of the password to the complexity of the word, and defeats the purpose of including numbers and non-alphanumeric characters.

Re:First, make sure security policies are sane

[LunaticTippy]

Well, assuming I lost my wallet, I have lost unencrypted credit cards and cash and have real problems.

Along with getting new credit cards and so forth I could change passwords. At least there aren't plaintext passwords written down. My personal algorithm shifts special characters and handles numbers differently so anyone finding the paper list in my wallet gets exactly one character from the actual password.

Don't.

[David McBride]

Use Kerberos instead.

Re:Don't.

[Twylite]

Single Sign-On and Trusted Third Parties don't solve all your problems. As the original poster said, these include database passwords, and will probably include things like passwords for network devices (routers, firewalls, switch management interfaces). These require a password management solution, not SSO or TTP.

There are a couple of enterprise password management products available that can provide ACL controlled access to passwords. They are mostly expensive, and some are inflexible.

A cheaper solution is to use something like Password Safe with a network-accessible database. Identify a limited set of users and share the safe password between them. Then keep that password locked in a dual-access-only safe or vault for disaster recovery.

If you have different classes of users that only need a subset of passwords (network admins, DBAs, account system admins) then use one password safe database per class. Obviously each database will have a unique password ;)

For more complex environments where you need the flexibility of ACLs, you'll have to get an enterprise product.

Separate GPG files encrypted to lists of users

[cblack]

This is what we do for a much smaller group of admins and systems:
Create a simple text file with the systems, usernames and passwords. GPG/PGP encrypt this file to a list of recipients. Now you have a single encrypted file that can be decrypted by any of the recipients. You could break this out into multiple levels by having multiple files, one for each group of "only these users have these passwords" and each file is encrypted to different sets of users.
No logging, nothing fancy, but it just plain works and doesn't require lots of money or time to set up.
One bit of advice: include your web passwords for vendor support or ordering in here as well, not just your internal systems.

Re:Separate GPG files encrypted to lists of users

[kahanamoku]

the issue here is when you dont have a person who know's all... a typical sccenario, most DBA's are precious about their systems and passwords, and dont want sysadmins knowing the passwords they control, and vice versa..

for our company I wrote a php/oracle system that has minimal permission to view the php source code, and the passwords are encrypted before being sent to the database. the tool is fairly clunky, but it works. took all of 4 hours to write too. people have the ability to create password entries and then assign the passwords they own, to selected users of the system.

Re:Separate GPG files encrypted to lists of users

[crunch_ca]

And as a handy way of editing these files, you can of course set up your .vimrc to include:

http://www.debian.org/doc/manuals/reference/exampl es/_vimrc

which will automatically encode/decode .gpg files. If you're daring that is.

Re:Separate GPG files encrypted to lists of users

[mengel]

There's a script wrapper for this, it's called escrow... We've used it for a while and it's really quite handy.

Re:Separate GPG files encrypted to lists of users

[WuphonsReach]

I'll second GPG. Although I prefer to keep each system in a separate file (makes it easier to look at the change dates and see when things were modified).

And once you're using GPG ASCII blocks inside regular text files, you can simply dump those individual files into a version control system or central network share. Backups are also dirt-simple, e-mail everything to yourself at some other location or print out the sheets and rely on OCR in the worst-case scenario.

And yes, I'll be looking into "escrow". Our system works because there are only half a dozen of us that need to share passwords. Often I'll change a password and then e-mail the ASCII-encrypted text block to the group. I should really move towards putting these text files into our VCS.

Re:Don't. (Kerberos can't be used for everything)

[cblack]

Sadly, Kerberos can't be used for everything. Especially logins to systems you don't control such as support and vendor ordering logins that should be available to people.

Anyone else get a 404 on this story?

[Anonymous Coward]

CmdrTaco -- I got a 404 from the link on the homepage to this story for a couple of minutes. Probably a bug.

First question

[Todd Knarr]

The first question I'd ask is, do you need this for distributing passwords to the people who need to use them, or for escrowing passwords so you can get access to them in an emergency when the people who normally use them and know them aren't available?

Re:First question

[Spazmania]

Like me, he probably needs some way to make rarely-used passwords accessible to the staff who need them along with a record of which of those rarely used passwords have to be changed when an employee leaves.

For example, I have switches, routers, PDUs, servers, etc. On the servers I have root passwords, database passwords and so on. The sysadmins need the root password to do a fsck on bootup but that's about it. The rest of the time they use sudo with their own password. The application guys need the database root password once in a while, but only to their servers.

It would be awfully darn convenient if I could say, "Here's a URL and your password to the password keeper. Every password you should have access to is there." Then when an employee leaves I could go to the same password keeper and say, "Show me every password this individual accessed so I know which ones to change."

It would also be very convenient if when my sysadmins finished a new server they had somewhere to log the password in so that the next guy who needed to do an fsck knew where to find it.

Of course, we could just use the same password on everything... But then we're S outa luck when the app guy needs the password to two servers and nothing else.

Re:First question

[WuphonsReach]

GPG encryption inside regular text files (one per service) stored in a version control system. The contents of the files are encrypted using the public keys of everyone who is supposed to be able to decrypt the file contents. Unfortunately, it probably won't scale past a dozen users.

Doesn't handle keeping track of access. Although you could possibly do some fancy stuff with Subversion scripts to track that sort of thing.

Re:First question

[zippthorne]

Sounds like you're making things complicated. You've got one thing you want to do: everyone has access to the things they're supposed to, and this idea about implimenting it using some kind of password database.

The thing is, that's not really the best way to go about making the originally intended thing happen, and ends up adding another layer of beaurocracy. This used to be a common point of discussion here on slashdot; namely figuring out what you really wanted to do in the first place that prompted the question of how to do what you think you need to do to accomplish it.

I really don't think that any solution that involves keeping a non-hashed version of any passwords stored anywhere (physically OR digitally) is really a good idea.

wild speculation follows:

Perhaps if /home and any shared data are kept unencrypted on secure servers, whose only outgoing link to the workstations goes over SSH or some other crytographic protocol. Then it wouldn't really matter what the workstation's passwords are (or if they even allow root at all) you could just reimage the OS without worrying about losing any valuable data. On the matter of access to resources, some form of "group" access similar to filesystem permissions could be implimented. When an employee leaves, it's just a matter of removing their username from whatever groups they happened to be members of.

That only leaves the secure data servers to worry about, and if they're unencrypted, you should be able to back everything up before a similar reimage. Then nobody needs access to anyone else's passwords or root except whoever configures the images, and they would remove root access on any image before letting it "go live."

but I am not a Network Engineer. I'm sure there are much better solutions than this. Ones that address the problem of retaining secrecy in the face of physical access to the 'secure' servers even.

Re:First question

[Spazmania]

How does any of that help me put the root password for a boot-time fsck in the hands of the sysadmin at the console without everyone having to learn a new password every time someone leaves?

I'm not interested in a theoretical information security construct that shows how security could be implemented well. I'm interested in solving the problem I actually have with the systems and equipment that I actually have.

I have minimal control over how much of the individual pieces of equipment are implemented. They do what they do and I have to integrate that into a working system. A solution which fails to honor that constraint is no solution at all.

Re:First question

[cmarkn]

It sounds like you want to do something like this. That way, you have a separate root account for each person who needs it, and you just delete the account of the person who left. No one else ever knows or cares that anything changed.

Re:First question

[Spazmania]

Been doing that since '92. Sudo is also applicable.

Irrelevant to this problem. Understand the scenarios:

A) fsck has failed during a boot. The machine wants the password for "root" in order to continue.
B) Appliance like an APC masterswitch or an Ironport A60 supports only one password.

Re:First question

[zippthorne]

a) remove drive, insert fresh drive with the standard image, restart server.
b) write a custom 'driver' that has access to the password, allow selected people to service the APC through the 'driver?'

Assuming the controller is in a room you have some control over, why even have a password?

SecretServer

[FormulaTroll]

There is this: http://thycotic.com/products_secretserver_overview .html

Put it in robots.txt

[Anonymous Coward]

Noone pays attention to that.

Easy

[skinfitz]

Just have everyone use a blank password for everything then you don't need any fancy vaults.

Open Source solution -- using Lotus Notes

[Anonymous Coward]

http://www.openntf.org/Projects/pmt.nsf/ProjectHom e?ReadForm&Query=Open%20Notes%20Picture%20Database

It's written by Christian Brandlehner, Jason Engel and Hynek Kobelka. Encrypts the password for the chosen people. Requires the Notes ID to get to it. Very secure. You can control who gets onto the server, then another list of who can get into the application, and finally a third list of who is allowed to see each individual password. The passwords are stored in an encrypted format (for each ID file), so cracking the server does you no good. You can allow everyone in the company access to it, but without the document being encrypted for their ID, they can't tell what the password is. VERY secure.

Since the Lotus Notes client has just been released for Linux, all y'all zealots can't complain as much, though I know the "Lotus Notes UI sucks" people will swarm out of the woodwork.

Oh well. It's good enough for IBM and the CIA to use.....

Re:Open Source solution -- using Lotus Notes

[funfail]

Using a password management software disguised as a picture gallery... Very clever indeed.

Re:Open Source solution -- using Lotus Notes

[Anonymous Coward]

Hmm -- you're right. I just copied & pasted the URL out of their documentation in the application without looking at it. Still, the names are correct, and we got it off http://openntf.org/, so folks should be able to find it.

Thanks for pointing that out. I'll try to let the author know.

Re:Open Source solution -- using Lotus Notes

[SanityInAnarchy]

Since the Lotus Notes client has just been released for Linux, all y'all zealots can't complain as much

The hell we can't. You didn't say a thing about source.

Re:Open Source solution -- using Lotus Notes

[pstorry]

Looks like he posted the wrong link - try this one:
http://www.openntf.org/projects/pmt.nsf/ProjectLoo kup/Open%20Secure%20Password%20Repository

Cyber-Ark Enterprise Password Vault

[jeremymk204]

I've used Cyber-Ark's Enterprise Password Vault, it seems extensive as for what it can do. http://www.cyber-ark.com/datasecuritysoftware/ente rprise_password_vault.aspCyber-Ark's website

Physical vault

[whitehatlurker]

When I read this, I saw it as a physical vault - a locked, fireproof box in a secure location in your premises. This is a good idea, especially for important "secrets" which may cause problems if lost. (The password to the payroll system, for example. Your payroll accountant goes into a coma, you might have to get in to make sure that at least you [the IT people] get paid.)

Storing these things electronically is dangerous. Storing them on an electronic box which can be accessed over a network (any network) is just stupid.

There is thing called a two-key safe...

[queenb**ch]

If you're going to do that, it really shouldn't be on line. While I agree that someone needs to be able to get to the "God" passwords in the event of a catastrophic event, our solution to that is very low tech. They are written out on a sheet of paper and placed in a slightly special safe. It takes two keys to open and only a few of us have keys. Some of us have the A key and some of us have the B key.

That way if any of us needs a password to which we do not normally have access, we still have to convince another person to help us open the safe. It provides a secure check & balance with very little inconvienence other than filing away a new sheet of paper once a month.

2 cents,

QueenB

So...

[LordEd]

where do you store the combination for the safe?

Re:So...

[Fallingcow]

No, no, no.

You don't use a combination safe.

You get one of those kick-ass double-turnkey locks like they use for nukes in silos and subs (if movies are to be believed). Then it can only be opened both Sean Connery and one of his top officers are present (or if they've been killed and had their keys stolen by two other guys).

Re:So...

[Fulcrum of Evil]

Any safe can be opened. It's just a matter of how long.

Re:So...

[whitehatlurker]

C'mon - somebody mod up LordEd. It deserves at least a funny, if not insightful.

Excel

[Anonymous Coward]

I shit you not.

Commercial Product

[Anonymous Coward]

checkout PowerKeeper

Password Manager XP

[Zocalo]

We use Password Manager XP from CP Lab with a set of databases shared by numerous users across multiple sites via remote network shares with DBs for sites, departments and we also allow individuals to create personal databases if they wish to do so with a quite complex access schema. It's Windows based and not free, but the price is fairly reasonable and the feature set is broad to say the least! You can grant readonly access and update access on per database, per branch, or per password levels as required by to either individual or groups of users. Tip: Locate your password DBs in multiple directories and use Windows' own directory permissions for another level of security, although all common encryption algorithms are supported in combination. It's got full logging, plus a complete change history so you can view prior passwords which is very useful if you dig out a box that's been sitting on the shelf for a few years!

Seems to me it does everything you need and then some.

Shared Passwords BAD

[Fred Nerk]

As far as I'm concerned (and It's an informed opinion), shared passwords are BAD.

You'd be much better off with a distributed authentication system.

Set up RADIUS/TACACS+ for authentication for all your network devices. I'd suggest Radiator because it's extensible and reasonably quick, and cheap (not free, but you get the source).

Radiator can do it's password lookups by LDAP (and lots of other things), so you can set up LDAP to keep user's individual passwords. Configure samba, ftp, mail, apache, squid, etc all to do authentication against LDAP, and you'll never need a shared password again.

It only takes a simple web page to manage LDAP records, and I'm sure there's an open source one around.

This is probably a little more work than you were looking for, but this is one case where changing the process gives you a LOT of benefit now, and in the future.

Re:Shared Passwords BAD

[Spazmania]

As far as I'm concerned (and It's an informed opinion), shared passwords are BAD.

As far as I'm concerned, you're right. Now, try setting up multiple accounts on an old APC masterswitch, multiple enable secrets on a cisco switch and setting up your unix box to allow multiple accounts to perform an fsck during a unix boot failure.

We live in a practical world man.

Set up RADIUS/TACACS+ for authentication for all your network devices. [...] password lookups by LDAP

Sure, because putting administrative access control for critical network infrastructure behind two layers of complex servers is a winning strategy.

Think disposable vault...

[Pacifist Brawler]

Get a metal box. Put a thin slit in it incase passwords are ever updated. Weld it shut. If it's important enough that someone needs to retrieve the password, then it's important enough to break open the box.

Don't do it

[JoGlo]

Part of my responsibility is related to information security, and as such, I have been exposed to a number of propositions related to password security. The bottom lines are that: 1. No two people should EVER share a password -passwords must be individual, otherwise they have little or no meaning. 2. Every time a password is reset, it must be a "one-shot" reset, forcing the user to change it again before he/she can use it 3. Passwords must be changed every 90 days (maximum), and there must be a certain length of time before the same password can be reused. 4. The user must be the one who is forced to change the password, and it must not be shared with anyone. 5. The support point must have the ability to reset passwords, but not to use the account once the password is reset. 6. In case of requiring urgent access to someone's individual password, that must not be made available without an explicit directive from a company officer, in writing, before the support point will reset the password and give the reset password to anyone other than the user whose password it is. 7. Passwords must at a minimum be 7 characters in length, and contain at least one alpha character, and one numeric character. If you want to piss someone off, use a password generator to create a random password whenever the password has to be renewed - people like to have a password that they have at least a chance of remembering, but this is more secure. Do that, and you'll have some level of security. Use your password vault, with shared passwords, and you might just as well not use anything.

Re:Don't do it

[hob42]

I think you're missing the point.

Suppose there's a company that does contract tech support for corporate remote dialin access through a national internet company. Each company's userids are separated under a top-level account, so they have to have a different admin userid on each account.

Since these admin userids are shared with the customer company as well, they can't use the same password for all of them. But each of the techs needed to know what each of the several dozen passwords were, so they could reset the ids when someone called in for a locked password.

The solution for this particular real-life example was an excel spreadsheet that was printed out and posted on everyone's cubicle wall. It was maintained by one of the techs, saved on their desktop machine. When each password expired and forced a reset, it was recycled through seven different passwords to bypass the "same as previous password" security feature, and then changed back to the original again - to prevent us having to reprint out 100 new password sheets every couple of days.

I bet, if I still had one of my old sheets from years ago, almost all the passwords are the same today. I think a password vault is a much more secure idea.

Re:Don't do it

[Anonymous Coward]

I have 5 words (none of them english), most of them can be considered gibberish, and 5 digits that I use to create all of my passwords. Even if someone were to find out all of the words and digits they'd still have a hugely difficult time cracking any of my passwords. Because I don't put the numbers in the same places in any words, not at the beginning, not at the end. Try to figure out how many digits I put into an eleven character nonsense word.

I suppose that if you had the time, it would still be easier to brute force that limited set than it would be to brute force the entire alphabet but I don't use that method on anything requiring any more security than a yahoo mail account.

Re:Don't do it

[LurkerXXX]

Two issues:

3. Passwords must be changed every 90 days (maximum), and there must be a certain length of time before the same password can be reused.

If you want to piss someone off, use a password generator to create a random password whenever the password has to be renewed

While I change mine frequently, and make it extremely random, those two things are going to cause greater insecurity for most of your users. Why? Because they are going to put post-it notes on their desks with the passwords on them, because they won't remember them otherwise. Those two things should make the network more secure. In reality, they don't.

Re:Don't do it

[JoGlo]

Funnily enough, we could be working in the same company. Multiple clients spread over 3 continents.

In fact, I think you missed the point. NO passwords should be kept anywhere. If someone forgets his or her password, it's reset, and even the person resetting it does not have access to anything underneath it. The techs don't need to know the password (in our company, if you blurt out a password to a tech, it's an instant password reset, and they all abide by that). The techs never even see the password - it's system encrypted and automatically sent to the e-mail address registered to the user, which the tech doesn't know, and can only be used by the user to access the password change procedure, so it isn't even a real password. The beauty of the system is that if someone DOES manage to intercept the password, then they may use it to lock out the intended user, but will be stopped when the intended user tries to use it, and has it rejected. THEN the tech has the drains up to find out who's intercepting the password email. Works like a treat.

Re:Don't do it

[JoGlo]

Then your rules for the construction of passwords is not well enough described to give the user the latitude they need without allowing them to use their wife's maiden name or youngest daughter's pet name as the password.

If I used 1l9a1w6 as a password, would it mean anything to you? Could it be cracked easily? It looks random - well it's my Mother's maiden name interspersed with her year of birth. Next month it could be as6lack0by, which I would find just as easy to remember, but which would confuse most hackers. Or how about j2e5p9a1rit, also meaningless to you, but easy enough for me.

Expiring passwords frequently is absolutely essential to protection of user IDs. Don't believe me - go to Visa's site and have a look at what they insist for a company to handle transactions on their account (http://www.visa-asia.com/ap/center/merchants/risk mgmt/includes/uploads/ap_pci_data_security_standar d_1.pdf) Visa's Payment Card Industry manual - look at Requirement 8 on page 10, specifically sections 8.4 and 8.5.

Does it work? Yes, it works, and it isn't even all that difficult to deploy. The document I'm pointing to relates to financial transactions, but works equally as wll for any type of situation where password control is important.

Re:Don't do it

[JoGlo]

Yes, I can see that this may work.

Unfortunately, if someone does crack your list of words and numbers, feeds them into any sort of password constructor, and then hammers your account to get in, unless it has a set limit of login attempts (and a lot don't) then it will eventually crack it, regardless of how smart you have been in constructing it. That is why it is best to build your password using different "sources" each time, and do it frequently.

Re:Don't do it

[hob42]

Problem in our case was, we didn't have control over the network the userids were created on, nor did we have control over the terminal software we used to connect to it. We're talking stuff that's got at least 20-30 years of legacy in it.

On our few clients with only broadband connections, where we were using VPNs instead of using the unnamed national internet dialup network as the intermediary, we did have a modern setup like that. Each tech had his own password, logged into a (web-based) server, and hit a button to reset a password. (Now, we have to tell it to them over the phone, after various identification checks, since this is the password they use to get into the network and therefore, their email. But similar idea regardless.)

Re:Don't do it

[JoGlo]

Ah, so, security-wise, you started out well behind the 8 ball, by the sounds of things. Not much you can do if the architecture doesn't allow it, but even then, the next releases shoul, with the hackers and nasties out there today, move towards more modern prevention techniques.

Re:Don't do it

[turbidostato]

"Part of my responsibility is related to information security"

Information security requieres both deep technical knowledge and wide imagination. You seem to lack both of them.

See points 1 through 7.

So you read The Book and you are able to repeat it like a kakatoo. Good for you. Now what?

About point 1: What if the system doesn't allow for multiple administrative passwords (like i.e. a router or a network device)? Do you really want the one password to be known by just one person that can be on vacation or under the mythical overuling bus?

About point 2: If it's going to be a one-shot change, then why "reset" it; just give it a new one and don't change it; it doesn't add nothing. On the other way, what about devices that just can't apply a policy regarding their default password? Remember the military addagio: Mandate only what you are sure you can enforce.

About point 3: how is it that you are able to stablish a max for password life? Doesn't it depend on the strengh of the security system? On it's sensibleness? On the awareness of a breakeage? On sociological aspects like the fact that people WILL choose weak passwords or they WILL write down on easily accesible places if forced to change them too frecuently (for a variable range of "frecuently")?

About point 4: Just redundant. If only one can know a password, it's obvious you can share it with an administrator, not even when/if she sets it, thus, only the user himself can set it (and change it).

About point 5: If the password is to be used, even if it's only a one-shot, it can be used by whoever happens to know it... like the support personnel that resets it.

About point 6: Simple naivety. So you really think that when you are in a hurry/critical situation you should wait for a "security officer" to produce a "written permission" to access the resource? What kind of "urgent access" is this?

About point 7: Tell it to any device with just a numeric pad, for instance. And of course you will piss somebody if you use a random password for anything which is to be used in the real world. You will piss the user that will have to memorize a ten random alphanumeric char string and you will certainlypiss the company that tried to secure the resource since its obvious that unmemorizable password will be written down somewhere near the resource.

I'd be very worried if you were doing something "related to information security" on my company.

Re:Don't do it

[Anonymous Coward]

"I have 5 words (none of them english), most of them can be considered gibberish, and 5 digits that I use to create all of my passwords."

So you have six roulettes of, say, half a dozen chars each and you use them to form a cipher by moving then around more or less randomly.

That's called an Enygma Machine, and the Germans from the IIWW thought it was unbreakeable, more or less like you do.

Oh! The Germans lost the war, remember?

Re:Don't do it

[turbidostato]

"If I used 1l9a1w6 (...) Next month it could be as6lack0by (...) how about j2e5p9a1rit"

I can bet you *used* all of them, and I almost sure you are using at least one of those three *currently*.

I bet more: I bet you don't use more than a dozen of them and then rotate.

Re:Don't do it

[JoGlo]

"About point 1: What if the system doesn't allow for multiple administrative passwords (like i.e. a router or a network device)? Do you really want the one password to be known by just one person that can be on vacation or under the mythical overuling bus?"

No, but at what level is the security of your one-password box? If it requires real security, then if it only offers single password access, it probably isn't the one you want to use.

"About point 2: If it's going to be a one-shot change, then why "reset" it; just give it a new one and don't change it; it doesn't add nothing. On the other way, what about devices that just can't apply a policy regarding their default password? Remember the military addagio: Mandate only what you are sure you can enforce."

Yes it does. The person who sets it could possibly tell someone about the new password, but the only way to actually use it is to immediately change it, so the person who's password it is will still not have access, at which point it is pretty good policy to declare a security breach, and change it again immediately. Indeed, until the owner of the password has actually changed it, it must be treated as "at risk"

"About point 3: how is it that you are able to stablish a max for password life? Doesn't it depend on the strengh of the security system? On it's sensibleness? On the awareness of a breakeage? On sociological aspects like the fact that people WILL choose weak passwords or they WILL write down on easily accesible places if forced to change them too frecuently (for a variable range of "frecuently")?"

Programmatically, it's not difficult with modern systems to start prompting for a password change a certain number of days before the password expires, and to block the user if the password isn't changed by the expiry date. If someone writes down their password and puts it on the base of their PC (or where ever) that is their responsibility. The system has provided all the security it can, and if that userID is breached, it will be pretty obvious why it was breached, and action can be taken to rectify it - such as re-education of the person involved.

"About point 4: Just redundant. If only one can know a password, it's obvious you can share it with an administrator, not even when/if she sets it, thus, only the user himself can set it (and change it)."

Not sure I understand your reasoning in this one, but if you meant "you can't share", then yes, this is reiteration of a previous point, I suppose.

"About point 5: If the password is to be used, even if it's only a one-shot, it can be used by whoever happens to know it... like the support personnel that resets it."

But once the support person has reset it, what can they do? The user still doesn't have a password, and it soon becomes obvious that any activity using that userID (and you DO log all activities against users, don't you?) must have been carried out by someone else. How many occurrences like this would it take for even the most dim witted to notice a pattern, and do something about it? Anyway, a well secured shop will be using an automatic password generator, and the only person able to see the password will be the person who opens the e-mail that it is transmitted in (automatically, by the system). And because those automatically generated passwords are so horrible, there is yet another reason to force the change as soon as it is used.

"About point 6: Simple naivety. So you really think that when you are in a hurry/critical situation you should wait for a "security officer" to produce a "written permission" to access the resource? What kind of "urgent access" is this?"

No mention of a "security officer" - I said Company officer, and in our company, that means one of the VPs, and yes, that's exactly the way they say that they want it. One is available 24 hours a day, as we are a world wide corporation, on three continents.

"About point 7: Tell it to any device with just a numeric pad

Re:Don't do it

[JoGlo]

"law" interspersed with 1916, my mother's maiden name interspersed with her date of birth

"aslackby" (my place of birth)interspersed with "60" - my current age

"Jeparit" (where I lived for many years, interspersed with the year we moved there.

No, I don't use any of them, but just give them to you as suggestions of how you can generate seemingly random passwords that are easy to remember, but hard for a third party to crack.

And no, I don't rotate passwords - where they really count, I always generate a new one when the old one runs out - I have absolutely no idea what length of cycle my company uses for passwords, because I've never attempted to find out - I do know that you just can't reuse the last one when it runs out, and i also know that it is cyclic in some manner, because I've asked.

And why don't I know? Because I have no need to know, and good security uses "need to know" as a guideline, always.

Re:Don't do it

[turbidostato]

"Sorry, we're talking real applications with keyboards here, not POS machines"

This single sentence resumes it all: No, we are not talking about what you think we are talking about.

Specifically, we are *not* talking about just PCs under a single administrative control; we are talking about *any* kind of electronic device under securized authentication/authorization: PCs under the companie's administrative control, yes, but the electronic alarm in the door too, and the whole bunch of routers within our networks, and the hugher bunch of routers, firewalls... under our clients' control; and our DNSs regitrar's, and those of our clients', and...

Well, and yes: POS software is "real applications" too.

Re:Don't do it

[JoGlo]

Ah, now I understand your comments. Thank you.

In all the companies that I have been involved with, I have always been involved on the application software side, and my responses are, of course, application software oriented. The type of hardware (generally) that you are talking about would not fit the same sort of security mould as does the software, and for that stuff, you are, of course, quite right. I have no hardware security responsibilities, and tend to overlook them as "not my worry", I'm afraid. You blind sided me, and quite rightly so.

Having said that, and NOW putting the caveat that what I am referring to is software security, on big iron, on midi's, on PCs, on client-server applications, on web-based application, do you still have a problem with my statements?

One password to rule them all

[Colin Smith]

And single sign on.

http://en.wikipedia.org/wiki/Single_sign-on

MS Identity Integration Server (MIIS)

[Anomalyst]

MIIS with foreign export (LDAP, flat file, Novell, etc) is like $25K per processor. However it is free between AD stores including Active Directory Application Mode (ADAM). One drawback is that you cant debug it with VS2005, you have to use older version. Even then I was not successful, the project has been de-emphazised so I haven't had a chance to set it all up again and reporduce the issue with M$ support.
What you might be able to do is combine the free MIIS and the *ix support in 2003 Server R2 to push passwords from AD to a *ix LDAP and sync the non-MS with the LDAP.
I wonder if they are thinking about this in the SAMBAv4 development. It'd be a kick to see them outfox M$ highway robbery.
MIIS FAQ http://www.microsoft.com/windowsserversystem/miis2 003/evaluation/faqs/default.mspx

If you use an encryption product, use open source.

[Futurepower(R)]

Quote from the CP Lab About Us page: "Our company is located in Kiev, Ukraine. CP Lab's employs high-class experts, ..."

It's difficult to imagine that it would be acceptable to use an encryption product without having the source code. If you have problems, will you go to Kiev and discuss them with the "high-class" experts? Do you speak Russian?

Suppose a database becomes corrupted, and you need to recover your passwords? Will you send the entire database to the Ukraine?

Suppose the company is now selling an entirely acceptable product. However, suppose that later the company is sold to someone else, without notifying the customers, as is usual with software companies. Possibly the new owner will decide to build a back door into a "minor" a version upgrade.

The Ukraine? Isn't that one of the places that the U.S. government's break-the-law department, the CIA, holds prisoners illegally? Is CP Labs owned by the CIA, perhaps? Is CP Labs owned by the CIA, but most CP Labs employees don't know that?

If you use an encryption product, it should be open source. That at least provides some protection. One advantage of open source, free software is that the users can hide the fact that they are using the product from the developers. Paying creates a connection between your company and the developers.

Possibly there is some way of using TrueCrypt and GnuPG that would work for you. Need passwords for your department? Someone in your organization who acts as password manager sends them to you encrypted with your public key. Only someone who has your department's private key can decrypt them.

Passwords Max for Groups

[Anomalyst]

Search for it, authord.com is apprently dead or broken. Not affiliated with them, have used it for a couple years. Does NOT integrate with AD. Keeps a local list of users/categories/groups you can assign access levels and if they (or their group) are not assigned to the category or their access level is too low, they do not even see the entries. Windows only, written in VB, $129 for 10 users. I haven't found any viable open source alternatives.
We put the the executable and database on a network share (no registry keys!!), it stores the personal preferences (window size, position, etc) in My documents.
Individual logins, radius, MIIS sync are all superior alternatives, of course, but this is quick, affordably priced and reasonably secure.
Alternatives you might want to look at:

pGina http://www.pgina.org/?page_id=3 Master your passwords on a platform other than AD for your central identity store.

AcctSync, doen not appear to be actively developed, it has not had any news posted in about 18 months. https://sourceforge.net/projects/acctsync/

PSync http://www.psynch.com/, commercial, no pricing on their site (schmucks).

Strongbox

[sorphin]

I actually borrowed an idea from a previous employer (tho wrote my own implementation), called StrongBox. it's a mysql database AES encrypted messages (containing passwords, messages, etc), the key is a SHA-1 has of a request ID and their employee ID.. it works rather well, it's all php/mysql and a little bit of javascript

Depends on security requirements.

[scuppy]

Dont forget not all paswords are for the directory login eg routers etc. Generally users would not store their user password using this system. If a user loses their password a reset is the most common remedy. I have worked in security with classified and highly classified networks. The most highly secure networks will have a paper filing system stored in a physically secure location with all access fully audited. The less secure networks use LAN accessible password database applications, which is also highly audited of course. Seperation of duties between audit and access are essential. I would not recommend integration with directory if seperation of duties is not possible.

Guaranteed not to lose it...

[RealGrouchy]

One problem my organization has is we keep forgetting passwords that are rarely used.

My suggestion is to post it to http://en.wikipedia.org/index.php/List_of_%5BCompa ny Name]'s_Passwords

You'll never lose your password again--guaranteed!

- RG>

Re:Don't. (Kerberos can't be used for everything)

[mengel]

Yeah, especially the root password for your KDC...

All you need is...

[JuzzFunky]

Lots of little yellow postit notes stuck on your monitor.

Re:All you need is...

[Lord Bitman]

But don't forget: write them /backwards/. Nobody will ever guess!

They don't speak Russian in Ukraine

[tepples]

If you have problems, will you go to Kiev and discuss them with the "high-class" experts? Do you speak Russian?

They don't speak Russian in Ukraine anymore. They speak Ukrainian. It's like assuming that the Portuguese spoken by a Brazilian is Spanish. But the rest of your argument appears valid.

Re:They don't speak Russian in Ukraine

[sco08y]

They don't speak Russian in Ukraine anymore.

There are about 11 million Ukrainians who speak Russian, out of 47 million.

Re:They don't speak Russian in Ukraine

[Futurepower(R)]

My understanding is that almost all educated Ukrainians speak Russian as a second language.

However, the point is valid, no matter what language they speak. It is difficult for a company in the U.S. to evaluate such a company.

You're asking the wrong question

[Anonymous Coward]

You're asking, "How can I build a metel boot to protect my toes for when I keep shooting myself in the foot."

This is a very straight-forward identity management problem. Lots of good solutions, that have already been posted. And in the long run, implementing some combination of policy and idm technology will cost less than the solution you have envisioned now.

Do it by hand

[davidwr]

I did this informally but there's no reason it can't be done formally.

Whenever you change your password, WRITE IT DOWN, put it in a sealed envelope with your name, the date, and what the password is for. Put it in a secure location where some "keeper of the keys" has access. Preferably the "box" would require two keys to open and would be emptied and the contents put in a vault daily. Just for good measure have 24x7 video recording of the drop-box and the vault.

Re:Do it by hand

[Zambarra]

Two envelopes. One contains the list of devices+username. The other contains the number of the correlating entry in the first envelope and the password. Envelopes are kept in two seperate locations. Fact of password retrieval is logged and/or requires authorization from PHB, etc.

Physical safe

[cdl]

Greetings,

We did this with a physical vault. Each machine's (routers, servers, kerberos domain key (actually stored on a usb key), etc) was generated randomly and printed out and put in a sealed envelope in a fireproof, keyed safe kept in the NOC. They key for the safe was then put in a key lockbox and locked with an "electricians lockout tag" which allows multiple padalocks to lock the same hasp. All padalocks need to be opened to open tke keybox. We used two keys (enforcing a two-man rule) and a security seal. The only way to open it was to open the two padalocks and break the security seal. The security seal number was recorded in the site log. Every shift change, the keys were passed to the site supervisor and another senior person and the security seal checked to insure that the keybox hadn't been opened.

Any time a root password was required the safe was opened (and the fact logged), and the correct password recovered from it's envelope. After use, a new password was generated and placed in a new envelope. At each safe closing, an inventory was taken to insure that all the envelopes were there.

A bit paranoid, but we certainly passed our auditors requirements.

It's generally a bad idea - don't do it

[Anonymous Coward]

What's more important, is first be sure there's a known way to get
around the password(s). This is generally the case with physical
access to the hardware. This is yet another reason why it's also
quite important to protect physical access to the hardware.

There are some exceptions, however. E.g. with good encryption, there
isn't a "back door". If the key / passphrase is lost, the data
generally won't be recoverable, period. For cases like that, one can
effectively (e.g. via software and/or procedures) effectively escrow
the encrypted data, e.g. by ensuring that there's some backup means
of getting to the data (e.g. there are multiple "passwords" (or at
least one "backup") which can be used to retrieve the
encryption/decryption key, or which can be used independently to
decrypt the same data (e.g. similar to using gpg to encrypt something
to multiple distinct recipients - either can decrypt the data, as the
data is encrypted to session key(s), and that(/those) key(s) are then
encrypted to the recipients keys.)

Vaults also fail in various ways - expect it. E.g. building blows
up, vault gone, upon testing "passwords" in the vault, 20% are found
not to be correct and current, bad guys crack the vault or steal it,
etc.

Re:If you use an encryption product, use open sour

[Zocalo]

Yes, open source would be better, but since so few people *really* understand encryption to the point that they could take a look at the source code and say "yes, that's secure" most people would still be relying on someone with the necessary skills monitoring the code. You can't just assume that because the code is available that all the specific code versions in your compliation has been checked and found to be backdoor free by someone capable of doing so. If you need the open source comfort blanket though then clearly this is not the product for you, but that's just another one of the decisions that individuals need to make for themselves when choosing a product.

If the DB becomes corrupted I'd restore from a known good backup, which we have. As the web page states "there are no backdoors" which, true or not, is what I would expect from *anything* involving encryption. Even if there was a magic back door safety net, I still wouldn't be sending my password data off for recovery, regardless of who the company was or where they were based.

On the subject of them based in the Ukraine, so what? I think it more likely that if the CIA/NSA/whoever have backdoored any encryption programs it's more likely that they will have done the ones in their own country first, so I guess that's PGP out then. Personally, when it comes to security, I assume everything is as secure as wet tissue paper and factor that into my risk analysis and installation - hence this tip about using Windows' file permissions for an additional (independent) level of security. You could also add another layer by using something like TrueCrypt to scramble the partition that the databases were secured on if you wished.

Shared Password = Oxymoron

[boyfaceddog]

I know this first part is off-topic, but stick with me.

Isn't the FIRST rule of security that you don't ever share passwords?
And the second, and the third?

Structure your access so that the people who would need to access everything in an "emergency" (whatever that might be) have the proper passwords. Then create one MASTER password changed every week and encoded and writen on paper and kept locked in a keyed vault. Then hand out the other passwords structured UP from the users, through the managers, to the VPs and so on. Make your DB about who has what access, not what their passwords are and you will be more secure. This way you can have certain people responsible for changing passwords without giving them access to anything the passwords control.

Of course I could be talking out of my ass, too.

Token protected database

[jgercken]

Just a thought: If you've implemented an RSA tokens for dialup/vpn access you may be able to use them to authenticate to a ssl webpage tied to a database containing the passwords. Don't know if Java, .net, etc can hold them in protected memory, you may have to write a client side app for that. Or I suppose you could just risk other processes reading that memory segment.

Re:Ahhhhhhh

[Anonymous Coward]

Fag.

Re:If you use an encryption product, use open sour

[Control Group]

Don't fall into the trap of the technical mind; we're talking about a business, here. For business and audit purposes, whether the product actually works as advertised is nowhere near as important as whether the purchasing authority did his due diligence (and can convincingly say he had every reason to believe it didn't have a back door built in), and whether the vendor officially supports the featureset the purchaser will be using (which means they, not the purchaser, can be blamed when the product fails to perform).

Now, purchasing security software from a company in Ukraine makes boths those goals harder to meet, but not impossible. Purchasing closed source software doesn't have any material impact on either of those goals.

Enterprise level Password Vault

[snuffin]

Here is a product that was demo'd to a network security company I used to work for. IT is an enterprise level PW fault that would accomplish what you are looking for and might add some levels you didn't think of. http://www.cyber-ark.com/networksecurity/passwordv ault.asp No I don't work for them I saw the post and remembered the demo.

Cheap solution

[Avatar8]

I did something like this at a previous job though we only had three of us in IT that could access this. You could adjust it for your tiered environment.

First, though I would repeat what someone else posted: using shared passwords is a high risk. It's better to structure your group access appropriately and have people log on as themselves. This way you have a record of who did what and when. Only downside is the number of profiles that get created on servers (Windows), but that's minor.

1. Create a secure network location that only those who need to have passwords can reach.
2. Create a spreadsheet for each group/level of passwords needed to provide separation.
3. Password protect each spreadsheet with a different password and provide that password to the appropriate people.
4. Keep a master password list that only two people can access (top forest/domain admin/superroot and IT manager/VP/CIO). Most likely the head of the department and his/her supervisor. This list would only contain the passwords to the other lists and possibly some top level passwords no other group can access.
5. Encrypt the directory.

From your description I get the impression that you have a different password per server, service, application, etc. While that separation may provide an extra degree of security, it may not be worth the effort. You might consider using "themed" passwords with l33t/hacker speak. SQLAdmin password might be 5QL.@dm1n#, webadmin could be W3B.@dm1n! and so on. Add your own twist to it so it's not an easily identified pattern. Add other factors to differentiate but be well known to those who understand the environment. i.e. all servers in rack 1 have passwords ending with ! or all IBM servers have passwords starting with an "e".

You may be restricted by standards or other outside forces. Regardless of what you use to keep up with passwords, having some obscure yet memorable system for passwords sets a good foundation.

MOD PARENT UP

[Anonymous Coward]

Yes. An LDAP database, Kerberos, perl (or expect) scripts managing access to systems you don't control (so the end user does not know the password of the system at your partner's site, and all access is logged) for example.

But stop trying to find a right way to do it wrong, and work towards doing it right... it's already technically possible (Novell, for example, has an SSO product that leverages their eDirectory/NDS system) you just need to transition towards a better infrastructure that includes identity management coupled directly into access controls.

I use OpenLDAP, perl, Kerberos, samba, and linux. That's the hard but cheap way to do it. It took us five years to implement but we are a large complex shop (and we started implementation seven or eight years ago, so now it's pretty damn solid). If you have more money than expertise use Novell.

Re:Ahhhhhhh

[neilsly]

the crypt rocks!!!

-- neil @ proslink

Vendors for you

[John Harrison]

The following companies will be more than happy to sell you a password storage/single sign on solution:

Encentuate
ActivIdentity
Passlogix

Another product: ID-Archive

[Anonymous Coward]

Another product that tackles the problem of admin passwords id ID-Archive:

    http://mtechit.com/products/idarchive.html

It basically randomizes passwords every 24 hours or so, and uses a central server cluster to archive the newly-randomized passwords, and act as a central point of control through which IT staff retrieve just the ones they are allowed to access, after suitable authentication, with proper access controls and logging.

To those who say use sudo or endorse avoiding passwords entirely: what would you do to deal with 10,000 workstations, which may be offline and/or remote? Most of the privilege-escalation and strong-authentication technologies require a live network connection, which isn't always feasible, especially for workstations.

This product also supports lots of platforms - not just Windows/Linux. It will manage mainframe passwords, SAP, DB passwords, etc. etc.

I do work for the company, so of course you can take what I say with a grain of salt. :-)

- Idan