Password Keeper App???

Hey All,

I've recently taken a new position in which I am one member of a team and not the only admin. My boss asked me if I knew of any apps in which our team could store all passwords and share amongst the team. Previously, since it was just me, I stored that stuff in a spreadsheet that I kept offline burned to a CD and locked in our server room. I was wondering/hoping that some of the other AO'ers our there might know of an app that would help out? Obviously given the nature of the content it needs to be secure.

TIA

i dont have time to look for a free one right now but in about 30 seconds on google i found you this

http://www.download3000.com/download_7945.html

so go ahead and google yourself;) you'll find something

how many passwords are we talking? I would strongly suggest you not store passwords anywhere but in your head if possible. I would certainly not use a program for the passwords. Unless Im mistaken password programs are made to auto log you in, not just store the password. So if you MUST have them written down, I would put them in a text file then use a GOOD encryption program. What ever you do, just lock that file away, and in my experience when hiding passwords security through obscurity is a helper, so dont name the file "passwords" or anything remotley related to it.

Check out PasswordSafe. Written originally by crypto-god Bruce Schneier. I use it for my stuff and it has import and export capabilities. http://passwordsafe.sourceforge.net/

A collegue of mine likes this app, KeePass, but havent checked it out. http://keepass.sourceforge.net

Downside to these is you cant have multiple user accounts so my team and I just share the passphrase and when someone leaves we change it. Not the most elegant but it keeps your passwords safe.

We have been using Password Agent here. We purchased the product so that various groups can use it and store their master passwords in their own encrypted container. We have had no issues with it to date.

Cheers:

We use a word doc placed on a server with the password feature of Word with strong AES encryption enabled. The word doc is compressed and encrypted with winzip 9.0 using the AES 256bit key encryption included in the US domestic version of Winzip. This way the file is encrypted twice and you need two seperate passwords to open the master password document. Both of the passwords are passphrases that are atleast 14 characters in length and meet most complexity requirements.

Auditing of the file is enabled for all access and NTFS permissions for both the file and the directory are limited to only those who have a need to know.

Of course we don't name the file passworddocument.zip. The name is very cryptic and you would never know what is in the zip unless you have a need to know. Access to the server that contains this document is restricted only to administrators, and no shares exist for the volume that contains the password document. You must term server or login locally to the machine to access the password document.

A written policy exists stating that the master password document must never be copied to another machine or anywhere other than the winzip archive it is normally stored in. Violation of this policy can result in immediate termination.

I would never rely on just a single program to protect this type of file regardless of who wrote the program. Also if the program doesn't generate some type of audit trail so that you know who used the file and what they did to it, I would not use it.

There is no need for a password file of this type. No exceptions.

No two users should EVER have access to the same account, otherwise accountability goes right out the window.

Regular user passwords can be reset by an administrator. Administrator passwords can be reset by lateral administrators, and if the need really arose any password can be reset with local system access.

cheers,

catch

some times a list like this is absolutley neccessary. We have several lists (not one big one) becasue we have the usernames/passwords for every admin account on every one of our clients computers. combined this is probably close to 1000 machines if we include all of the servers. the list is secured VERY well, both physical security and technological. so I think under the right circumstnaces list are neccessary.

I should add, the lists are in different locations, none of which are in anyway available online. So you need physical access to the machine to get them. but under normal circumstances a list should not be made. I have to remember ~50 passwords and ~20 usernames, and I generally dont have a problem (except for monday mornings before coffee, lol) and the same seems to hold true for my co-workers(some with well over 100 passwords)

XTC46... your company needs to look into SSO technology.

Password lists only make bad architecture usable, which is in and of itself bad.

Again, multiple users having access to the same account is TERRIBLE! This alone can make your company fail a SOX or ISO17799 audit.

cheers,

catch

Catch:

Down here at "scrub" level you will quite often find apps that only allow for a single password, that have security implications, that have no self auditing and multiple users must have access to.... Honest...

We have one where I work that Property Management got when they implemented a key fob system for certain access points. Of course they never came to IT before they made the purchase decision because the software that came with it "seemed more like an addon rather than an auditing system".... If I can access it I can delete the records of my entering the building :rolleyes:. The computer it runs on now sits in a "Special Grand Master" locked room but it still has five people using the same authentication credentials because we can't afford to replace an entire $X,000 system for this "little inconvenience".

There are a couple of others within my organization that have similar issues, especially those where we report to funding sources etc. via their web sites where they give us only one login. We need several people to know the authentication credentials so the situation is the same. You may say that it isn't our problem but that of the provider, but that would be wrong. Since we can only access "our" information there, and let's say it's billing information, and someone accesses it and deletes it all we don't get paid by the provider. That means I don't get paid because we, as a company, don't have the money. Can you say "Denial of Service" ;). Worse yet, if they divulge that information publicly... the loss of credibility, through no fault of our own could cripple the reputation of my company to the point we don't get funded by anyone. Please don't tell me to call them and ask for multiple logins - it will prove you never worked in the "provider/funding source" world - it's their way or the highway, period and they don't care if my stuff is compromised from their box.... The fact will remain that no matter how much we "squawk" about our network being uncompromised and the lost data originated from their systems people will still see that _my_ organizations data was leaked.... Sucks? Yes. Fact of life? Yes!!!!!!

This is a similar argument to those we have engaged in in the past, real world vs. Catch's world. I utterly agree with you, as I have said before about the ideal world, but this is a perfect example of the real world "trumping" the ideal and us "scrubs" having to work around it.

Its true that multiple people accessing the same account is HORRIBLE. and the lists we have arent becasue of bad archetecture. its becasue things are just so spread out (several networks that have nothing to do with eachother) and very few of them are "mission critical" machines which need to be very secure. the ones that do are locked down with a minimum number of people having access and their passwords being only help in memory. the lists are for accounts that we probably will never access (becasue we have domain admin accounts and what not) they are there "just in case" and the accounts are generally never used.


Im just arguing for the sake of arguing. It will generally bring out better points than just asking questions. ;) Im sure you will agree.

Quote:

---

Down here at "scrub" level you will quite often find apps that only allow for a single password, that have security implications, that have no self auditing and multiple users must have access to

---

Such applications should have their access limited and audited, such as via a terminal server and should require no password of their own.

Quote:

---

There are a couple of others within my organization that have similar issues, especially those where we report to funding sources etc. via their web sites where they give us only one login.

---

Authentication to these sites should be controlled by a proxy server, and again with access controlled and audited.

Your arguments about the way things are, should be considered as a starting point, not and ending one. And one someone asks for adivice it should be used only as comparison, not as a target.

cheers,

catch

Ahhh.... Here we go again.... :D

Quote:

---

Such applications should have their access limited and audited, such as via a terminal server and should require no password of their own.

---

There are many apps out there that run a "Single" user or "Multiple" user.... Guess what? We can't afford the multiple user version and, in real terms, it isn't really appropriate within our risk assessment..... but we still need a "solution". This is what we get and it is my job to secure it....

Funny, I just thought... This is why my job is so much more _fun_ than yours.... I have to be creative.... You just follow "procedure".... :cool:

Quote:

---

Authentication to these sites should be controlled by a proxy server, and again with access controlled and audited.

---

Silly statement.... C'mon, don't just throw random, "I could care less" statements at me - you know better than that.....

I have no control over access to those sites. They are publicly available. A simple piece of SE could glean the required credentials and be used from South Korea or anywhere else. So your suggestion would be????

Quote:

---

Your arguments about the way things are, should be considered as a starting point, not and ending one. And one someone asks for adivice it should be used only as comparison, not as a target.

---

Hmmm... Fun statement.... It doesn't mean much really. I have my starting point - It's called "no _actual_ control over my data". That's my starting point. Could you enlighten me as to how I can achieve my endpoint?

It's a problem.... I know.....

Your points aren't making sense.

Quote:

---

here are many apps out there that run a "Single" user or "Multiple" user.... Guess what? We can't afford the multiple user version and, in real terms, it isn't really appropriate within our risk assessment..... but we still need a "solution". This is what we get and it is my job to secure it....

---

Yeah, and I just gave you a viable option... use a terminal server to control access to such applications. One terminal server, with correct ACLs can audit and authenticate many single user applications.

Quote:

---

I have no control over access to those sites. They are publicly available.

---

If a site gives you an account, and you plug that accoun data into your proxy server, agian making use of availible ACLs, you now control access to that account. The trick is, don't give the password to anyone... make them authenticate via the proxy... now you do control access.

Quote:

---

It's called "no _actual_ control over my data". That's my starting point. Could you enlighten me as to how I can achieve my endpoint?

---

And I'm the one that isn't creative? No one is tellin you to have control over the data... merely the methods availible for accessing the data. If you can't do that, you are not in information security, you are a lame duck.

If someone asks for advice on being a lame duck, I'll direct them to you. ;) If someone asks how to make a system more secure... well the one thing you need to keep in mind with procedures and standards... they exist because someone else tried a zillion and one ways to do something and they finally found a method that bypasses most of the pitfalls. The idea is to take that procedure or standard and apply the IDEAL approach to it and viola! You constantly get better and better ways to do something.

cheers,

catch

I think the point tiger is trying to make is that in certain situations, the "ideal security" cannot be had or is not needed becasue it would cost more than the protect data. When doing security analysis cost is a HUGE factor, especially when you are working for companies like non-profits, or start ups. They just cane afford the security. And i have worked in many places where there really was very little they needed to secure (aside from employee info, etc) so the security didnt need to be so hardened and there are only a few people so they throught (and I agreed it would be reasonable) that they shared certain passwords.

Of course... I've made a number of posts here (and even a tutorial) on proper risk management. The poster never said they had a minimal budget.

My point, and a point that NO ONE else made is that what the original poster is trying to do is bad and perhaps the reasons why you have so many passwords should be looked at rather than ustilizing isolated systems and multiple encryption schemes and armed guards and whatever else was suggested.

If something is important enough to have a password, it is important enough to utilize a secure portal that your organization already most likely has and isn't using. (proxy server/terminal server)

If people just assume no budget and minimal security... hell what is the little tag line of this site? "Maximum Security" not "Ghetto-rigged security for stuff that doesn't even really need it." As soon as the site owner changes this, I'll change my answers. Otherwise many users here will never even be exposed to the "right way" to do things.

cheers,

catch

ol jeb:

I probably should have clarified the use of that password safe type of application I use. I have a separate database which I use it for my personal passwords to the millions of websites and apps I have accounts on. My team at work uses separate databases by functional area for ONLY applications which only allow 1 account (similar to what Tiger Shark is talking about) OR for the service accounts used by various applications.

We have siloed the functional areas off with separate dbs (thus separate passphrases) so that the network engineers dont see the system administrators stuff and so on. We also only use these databases if all else fails at using individual accounts.

catch: Your points are well spoken...and taken. However, like Tiger Shark, I have very little budget (if you actually call it a *budget*) and am faced with what I have tool-wise. Also, there are soooo many applications that dont allow multiple user accounts it's incredible. We ARE working toward moving as many of these bad applications over to point to our newly installed single LDAP directory. And these are only the ones that now have the multiple account functionality gained with recent upgrades.

As a security professional I am trully frustrated (and strong words than that at times) with the lack of security features in this software and/or lack of understanding of what security *means*. There are applications we have that cost tens of thounsands of dollars (US) that dont have basic password strength controls...that's udderly ridiculous...and we (I/S and Security) weren't given veto powers either!

sigh.

Quote:

---

I have very little budget (if you actually call it a *budget*) and am faced with what I have tool-wise. Also, there are soooo many applications that dont allow multiple user accounts it's incredible.

---

I understand this, but there really are so many better ways to control access to such applications. Even something as simple as a script that logs a user into the application in question. The ACLs on the script prevent viewing the source and audit and control access.

Suffice to say, there are ALWAYS better methods than just giving users multiple passwords.

Quote:

---

As a security professional I am trully frustrated (and strong words than that at times) with the lack of security features in this software and/or lack of understanding of what security *means*. There are applications we have that cost tens of thounsands of dollars (US) that dont have basic password strength controls...that's udderly ridiculous...and we (I/S and Security) weren't given veto powers either!

---

I have said this many, many times on this forum... never ever ever ever ever ever never ever never rely on application security. All authentication and access should be controlled by the operating system. InfoSec shouldn't have veto power over anything other than security tools and perimeter defense... to give them more than that and IT procurement will grind to a halt. ;) Securing a great application that has multiple user accounts built in, with all kinds of great encryption and whatever else should be no different than securing a single user application with no internal protections whatsoever.

cheers,

catch

Catch:

You are missing the point...... My data is held out there on a web site that _anyone_ in the world could locate. I am given one set of credentials and told to enter our data into the forms provided. Your suggestion that I enter the account information into a proxy server and control access from there does absolutely nothing to stop _you_ from getting to my data from _your_ house.

Remind me again please, how do I control access to my data? Controlling my users isn't so much the issue. It's what I said, "no actual control over my data".... Some idiot in government who can't even decide what a HIPAA form 837's format is even though it is set in stone by the law is securing the very data I am supposed to protect. I am bound by thier arbitrary decisions and idiotic implementations of things they don't understand. Protest? Yeah, right.... all that gets me is people laid off because the contracts/grants aren't renewed because some incompetent had it pointed out to them that they are a know-nothing and are now pissy enough to get the contract cut.....

Ahh... The real world.... :rolleyes:

Quote:

---

You are missing the point...... My data is held out there on a web site that _anyone_ in the world could locate. I am given one set of credentials and told to enter our data into the forms provided. Your suggestion that I enter the account information into a proxy server and control access from there does absolutely nothing to stop _you_ from getting to my data from _your_ house.

---

And how does a password list help this issue?

The use of irrelevant examples could be why I was confused, I was under the impression you wanted to control user access to the website.

If you have data on a website beyond your control and you disaprove its security... your company needs to have negotiated a better arangement. ;)

None of this addresses why educating the original poster about why password lists are bad was incorrect or not real world viable. (I'd hardly call a non-profit real world, everyone knows non-profit means "too disfunctional to be profitable." I've done some work for them in the past... never again)

cheers,

catch

Quote:

---

And how does a password list help this issue?

---

1. We don't just have one funding source/reporting entity, (FS/RE), so we get numerous sets of authentication credentials.

2. We can't place the burden of all the work on an individual becuase the volume is too great for an individual to complete within the billing/reporting cycle - so we need mutiple people to have access.

3. Since we have multiple people that have multiple FS/RE's we find it wise to keep a list of them in a location accessible to only those that require it.

Quote:

---

If you have data on a website beyond your control and you disaprove its security... your company needs to have negotiated a better arangement.

---

Negotiate.... Hah.... You have more chance of negotiating with a pack of starving lions... at least for the proper disposal of your bones when they are finished..... and my "negotiators" are social workers not MBA's from harvard...... This is my world.... ;)

Quote:

---

"too disfunctional to be profitable."

---

LOL.... I can't disagree in many I have to deal with.... Fortunately, some have smart enough people at the top to know when they need professional help, how to go about finding it and then actually listening to it when they get it. I am fortunate that my CEO is like that. Of course, that doesn't make the CEO perfect.... Just a lot better than most of the other ones in town....

The list of passwords that we keep are service account passwords. They are not accounts that are used except for in certain circumstances, like if you need to login as the service account in order to install an update to that piece of software. A proxy server or anything like that isn't going to help out at all. Neither will single-sign on.

The passwords have to be maintained somewhere. If you think having one person know the password is the answer you haven't worked in the business world that long to realize that people come and go way to much to rely on one person to be the keeper of anything. In three months when that person has been layed off or outsourced to XYZ corp. you'll need that password.

Quote:

---

The list of passwords that we keep are service account passwords. They are not accounts that are used except for in certain circumstances, like if you need to login as the service account in order to install an update to that piece of software. A proxy server or anything like that isn't going to help out at all. Neither will single-sign on.

---

Clearly neither a proxy or SSO (alone) would be appropriate for this situation. In this situation you'd want to utilize a RBAC with a hierarchical login system (like the Argus PAM for example). This way you define what level of authentication you'd like at the login time and you can use the same credentials to authenticate to different levels of your role, however of course some levels are only available from some paths. (eg you can only login as say level 2, to do admin stuff from a local system or such and level 1, normal user from anywhere.)

Quote:

---

The passwords have to be maintained somewhere. If you think having one person know the password is the answer you haven't worked in the business world that long to realize that people come and go way to much to rely on one person to be the keeper of anything. In three months when that person has been layed off or outsourced to XYZ corp. you'll need that password.

---

The organization should NEVER EVER EVER EVER need an internal password. There should always be ways to resolve this as every password must be secret and non-recoverable.

Nowhere did I say that one person should have all the passwords or even be a unique for any one account. Everyone in the company should know and use one password. Having common passwords is terrible and will assure than you fail every single security audit that measures such things.

Now, if your organization doesn't care about such things or the risk doesn't justify the costs, clearly don't worry about any of this. I am merely stating a "correct" way to handle this issue that will ensure compliance will all relevant standards know and afford the highest level of security with the highest level of usability.

I just don't understand the value in assuming users who ask questions here have no money or desire to follow industry best practices.

cheers,

catch

Quote:

---

Clearly neither a proxy or SSO (alone) would be appropriate for this situation. In this situation you'd want to utilize a RBAC with a hierarchical login system (like the Argus PAM for example). This way you define what level of authentication you'd like at the login time and you can use the same credentials to authenticate to different levels of your role, however of course some levels are only available from some paths. (eg you can only login as say level 2, to do admin stuff from a local system or such and level 1, normal user from anywhere.)

---

Doesn't really exist for Windows2k based servers. Also seems like overkill for what the original poster was asking. He's not trying to meet any high security certification level, nor trying to beat an audit. Just because you would fail an ISO audit doesn't mean it is bad security. Just not appropriate for this situation.

Regarding what does and does not exist for Windows, I've attached a file for you and here is a link to the Windows 2000 RBAC API

Second off... the original poster asked about protecting passwords... other people gave completely retarded answers involving safes, razor wire, retinal scans, attack dogs, whatever.

I merely stated that pooling such passwords is in and of itself a bad policy. People chose to argue with this statement, which I still hold to be true. The rest has just been my giving answers to situations.

If you are going to criticize me for telling a poster that, although what they are doing may be working for them, it is overall a bad approach... and it might be a good idea to look at using a solution with the long term goal of migrating to a better system... you know all that pesky continual process improvement stuff.

You want a better answer more focused at the user?:

Odds are if:
A. You have such an authentication architecture.
B. Someone who asks such questions in a place like this is responsible for security
... you most likely don't even need to worry about security because clearly your risk is so minimal or your budget so small that a full compromise either doesn't matter or is unavoidable.

That better? People for some reason don't like me as an optimist nor as a realist. ;)

catch

edited to add Windows 2000 RBAC API link

Quote:

---

Originally posted here by catch
[B]Regarding what does and does not exist for Windows, I've attached a file for you and here is a link to the Windows 2000 RBAC API

---

Yes the ability exists, but readily available software that uses it doesn't exist. You can find an API to do just about anything, that doesn't mean that any software developers are actually using that API. Exchange doesn't use it, clustering doesn't use it, SQL doesn't use it. I can't think of any MS server based product that uses that API in the manner to which you are referring. It really isn't even supported by AD in windows2000, you have to be running a windows2003 based AD to integrate it with AD. MS still has server based products that require a service account and in some cases you have to install add-on products using that account. Which for all intensive purposes makes it impossible to have a service account password that is completely secret. Blackberry enterprise server is another server application that requires that certain commands and functions be run as the service account. I'm sure we could come up with a list of atleast 10 other server products that rely special permissions onto their service accounts.

Quote:

---

I merely stated that pooling such passwords is in and of itself a bad policy. People chose to argue with this statement, which I still hold to be true. The rest has just been my giving answers to situations.

---

I don't think anybody ever said it was a good idea. But in some cases it is needed, and there are very valid ways to make it secure that you seem to think are "retarded."

Quote:

---

If you are going to criticize me for telling a poster that, although what they are doing may be working for them, it is overall a bad approach... and it might be a good idea to look at using a solution with the long term goal of migrating to a better system... you know all that pesky continual process improvement stuff.

---

I didn't criticize you. I merely said that what you are proposing is probably overkill for what was originally stated. Would it be the most secure? Probably, but is the cost justifiable? Probably not. You even said this yourself. Without knowing exactly what kind of configuration exists now you can't say for certain that what you are proposing is even possible without some intense and custom development. Which is why I said it could be overkill.

Quote:

---

Now, if your organization doesn't care about such things or the risk doesn't justify the costs, clearly don't worry about any of this.

---