Multi-user Password Database Solutions?

[beporter]

First time poster here! Let me get straight to it...

I'm currently not in a position that lets me interact with other developers face to face on a regular basis, and I am in need of some "round table" discussion on a project that has be given to me. Let me describe the functional requirements I have in as general terms as possible first:

1) The task charged to me is to investigate, and if possible implement, a system for storing a great many passwords as securely as possible.

2) The purpose of each password does *not* need to be stored in the datastore. There does not need to be a URL, a username, a description or any other associated information in the datastore. The only thing I do need is some kind of unique identifier which could be tied into other data-tracking systems by referencing the ID for a given password in the system. I.e.: sending someone an email instructing them to, "Go look up password number 432 for this." In other words; my current plan is to make the password storage as agnostic as possible. I can implement the tracking of notes, usernames, and purposes in any number of ways: posting in a wiki, writing them down on paper, or saving a Word document. The only thing I really need to lock down good and tight are the passwords themselves.

3) The system must allow multiple, concurrent user "logins" to access/update the stored passwords. There is no need for per-user permissions for subsets of the stored information: any user in the system is allowed to access ALL information stored inside.

4) A high priority is placed on logging all actions performed by each user: including when a certain password is viewed or changed, by which user, and any other available information pertainent to the action.

5) The interface for accessing the passwords (if it is different from the software used for managing the data) should ideally not be locked to a given operating system (meaning I'll likely reject a pre-existing application that only runs in Windows, for example).

6) The system should also preferably be resistant to mass-viewing: it should be impossible (using the given interface at least) to view or modify more than one password at a time, and as difficult as possible to obtain a copy of the datastore file(s) themselves.

7) The last request is that the datastore as a whole must be backed up regularly for redundancy, and hence, the backup format/system utilized must also be as secure as possible.

There it is. This is not at all an easy "problem" to solve, and repeated and varied Googlings have not turned up anything close enough to what I'm looking for. My current line of thinking is not entirely satisfying to me and I need to see if somebody more knowledgeable than myself naturally comes up with a solution I would not have considered-- especially if there's a possibility I'm grossly over-thinking this entire thing.

Anyway, I've tried to keep my description as generic as possible to prevent biasing the reader's own thought process. I'd of course like to hear any thoughts the community has on this. I'd be happy to entertain any existing applications (FOSS or otherwise), as well as suggestions for a "from scratch" implementation. If anyone has questions they need to ask to clarify the problem, I'd be only too happy to answer them.

I'm also eager to share my current ideas for implementing this, but again, I want to see what unique suggestions everyone can come up with first before artifically locking the discussion into any particular category or programming language.

Lastly, I apologize if this is not the correct board to post this under , but as I said I am not currently restricting this project to being a "database project" or a "C++ project", etc. The _method_ of implementation is not as important as the security of the resulting system as a whole. I'm hoping the power of 39,000 other minds can help come up with a more secure, reliable system than just my one can.

Thanks for you time!

[Killer42]

First time poster here! Let me get straight to it...
etc...

Hi.

I'd just like to make one small technical point - or perhaps it would be better termed "policy" than technical. As a general rule, you should avoid storing passwords unencrypted. In any location which might conceivably be compromised, you should store passwords only in an encrypted form. To check it, you take the password entered by the user, encrypt that, and then check it against the database.

[beporter]

As a general rule, you should avoid storing passwords unencrypted. In any location which might conceivably be compromised, you should store passwords only in an encrypted form. To check it, you take the password entered by the user, encrypt that, and then check it against the database.

A perfectly acceptable and reasonable point, however it unfortunately neglects the purpose the database. The passwords themselves need to be recoverable. That is, in fact, the whole point of the database: to securely store a number of passwords in a single location so that they can be retrieved and used later. I'm thinking a lot like the Mac OS X Keychain (the description here is better than Apple's if you are unfamiliar with the technology), except with distributed access and not platform dependent.

Does anybody know of any existing packages, or have any good suggestions for ways to implement this?

Since there's been so little interest, I might as well go ahead and throw my own brainstorming out there. Keep in mind this is heavily influenced by the tools I'm most comfortable using. Currently my thinking is to use a MySQL database with a very simple table layout:

CREATE TABLE `pwdb` (
  `id` int(11) NOT NULL auto_increment,
  `pwc` tinyblob,
  PRIMARY KEY  (`id`)
) TYPE=MyISAM

We'll need a second table to track login rights, again very simple:

CREATE TABLE `login` (
  `id` int(11) NOT NULL auto_increment,
  `username` varchar(255) NOT NULL default '',
  `password` tinyblob NOT NULL,
  PRIMARY KEY  (`id`)
) TYPE=MyISAM

Obviously lock the database down to access from localhost only. On top of this, write a web-based script (PHP/Perl/Whatever) to access it. I can run all of this on an internal webserver and block public access both from Apache and using the network config/firewall. We can use VPN to get into the network to access the application.

Now as I said originally, there are a lot of gotchas to watch for in this setup and without public scrutiny I'm likely to miss at least a couple of them.

Anyone have any feedback?

[beporter]

Please also keep in mind that the client requesting this "solution" is currently storing their passwords in cleartext in an Excel file hosted on an open network share. In other words, they are in critical need of a huge increase in security. The system doesn't have to be perfect, but it has to be a couple orders of magnitude better than what they have currently.

[beporter]

Well, 10 days and only one response, which unfortunately wasn't even so helpful. I can't believe nobody has any suggestions at all!

Thanks to Killer for his input.

I doubt I'll come back to thescripts.com for any future discussion.

[Killer42]

Well, 10 days and only one response, which unfortunately wasn't even so helpful. I can't believe nobody has any suggestions at all!

Thanks to Killer for his input.

I doubt I'll come back to thescripts.com for any future discussion.

Sorry you didn't get much of a response here in the Access forum.

If you're still around, I'd suggest you try this one in the "Database Developers lounge". Description: Chat about latest database news, trends and technologies. Network and chat with other database developers.

It's a bit odd, really - just about any post here usually develops into a lively discussion, and produces at least some kind of results, or at least ideas.

[Killer42]

Hi folks: I recently switched my website from another provider to ...

Yeah thanks for that, Alex (or Peter, or whoever you are). Perhaps not strictly relevant, though?

Oh, and sorry beporter, I thought your post was in the Access forum - got myself a bit mixed up.

[beporter]

Thanks yet again Killer. I've posted a redirect thread in the Database Lounge. Hopefully that might bring a couple new eyes here and generate some discussion. I won't give up hope yet, and I genuinely appreciate your help.

It's a shame that so many minds have to be so segregated. I mean, it makes sense to have topical boards for certain things, so that people who have very specific questions know the best place to ask them, but what about the meta-questions that span MANY programming topics, like this one? Databases, Web Programming, System Programming, Security, Encryption, Networking, Best Practices... There is no board here that seems appropriate for all of those topics.

In fact, I my very first choice would have been a "Security" board, which I don't seem to see represented at all! Maybe it's just me, but that seems like an oversight of a rather large proportion.

[Killer42]

Thanks yet again Killer. I've posted a redirect thread in the Database Lounge. Hopefully that might bring a couple new eyes here and generate some discussion. I won't give up hope yet, and I genuinely appreciate your help.

It's a shame that so many minds have to be so segregated. I mean, it makes sense to have topical boards for certain things, so that people who have very specific questions know the best place to ask them, but what about the meta-questions that span MANY programming topics, like this one? Databases, Web Programming, System Programming, Security, Encryption, Networking, Best Practices... There is no board here that seems appropriate for all of those topics.

In fact, I my very first choice would have been a "Security" board, which I don't seem to see represented at all! Maybe it's just me, but that seems like an oversight of a rather large proportion.

Yeah, you could be right. Still, I suppose it takes time to fine-tune these things. I know "thescripts " is still undergoing a lot of change and refinement, things moving around and so on. KUB365 runs the place, I believe, so feel free to make suggestions.

I suppose one problem with a very general area is that people tend to look at the areas that interest them the most. For instance, I mostly scan the VB and Access forums. I also occasionally drop into the Programmer's Lounge and Community Lounge, but there's rarely anything there, and even more rarely anything that I find interesting or that I can help with. We have to work within our limits.

Now if we could get paid for providing support like this, I'm sure you'd see a lot more interest. :)

Anyway, I hope you see a more helpful response in the DB lounge. Assuming anyone reads it, that would be my guess as to the best place for it. It might be worth dropping a link into the Access forum, as well (I know, that's where I thought you were originally). But there are a few people there who seem to know a lot about databases.

Good luck!

[MMcCarthy]

I'm going to post a number of redirects for you in the Access, VB, Java, C++/C and Web forums.

Our experts hang out more in the technical forums than the lounges and should generate a lively discussion.

Mary

Thanks yet again Killer. I've posted a redirect thread in the Database Lounge. Hopefully that might bring a couple new eyes here and generate some discussion. I won't give up hope yet, and I genuinely appreciate your help.

It's a shame that so many minds have to be so segregated. I mean, it makes sense to have topical boards for certain things, so that people who have very specific questions know the best place to ask them, but what about the meta-questions that span MANY programming topics, like this one? Databases, Web Programming, System Programming, Security, Encryption, Networking, Best Practices... There is no board here that seems appropriate for all of those topics.

In fact, I my very first choice would have been a "Security" board, which I don't seem to see represented at all! Maybe it's just me, but that seems like an oversight of a rather large proportion.

[Banfa]

Here are some security points

1. Just because you need to retrieve the actual passwords doesn't mean that you shouldn't encrypt them to put them in the database. Some enyryption methods (MD5 for instance) are 1 way and are only used to authenticate a given password, you encrypt the password and see if it matches the encrypted passwords stored in the database. However if you use a 2 way encryption method (i.e. 1 can can encrypt and then decrypt the data) you can store the data encrypted and dycrypt it for viewing editing.

2. If you are going to have a user table that contains logon passwords it will need to be just as secure as the password table.

3. Now it sounds like this may not apply because you are inside a company firewall so there should be no external access but access through the webserver will send the data in the clear (unless you use a secure server). That means anyone sniffing the network (just retrieving all packets) will have access to unencrypted version of any passwords currently being retrieved. The VPN should handle encryption for you from outside the company.

4. You have not made it clear what the percieved security threat that this is trying to combat is. If the data is already inside the company firewall who are you trying to prevent access from? Or is this more about allowing multiple people within the company read/write access to the data concurrently rather than securing it from a percieved threat?

[NeoPa]

A couple of points.
1) I understand why encryption may be a problem, but a simple bitwise NOT might give you a little higher security and allow your interface easy access.
2) Don't know much about web programming myself, but would think that's the best way to get platform independent code working quickly and easily.
3) I think most RDBMS systems should be able to handle your main requirements - backup; availability etc. Access would find it difficult to remain available while being backed up.

I hope you appreciate that, while we try to keep on top of questions here and answer technical problems promptly, as your thread is a little more involved, devoting large amounts of time to it is something we have to watch out for, with a view keeping balanced and covering all requests.

Lastly, let me commend you on the rare clarity with which you expressed your issue. Without that I'm afraid I would have passed on to another question as it is quite complex. I hope I've helped some. If you have further questions in this thread, please don't feel ignored if responses aren't immediate - sometimes people just don't know the answer - and maybe the one person who can help is particularly busy or away on holiday.

BTW I hadn't seen Banfa's response when I formulated this post.
It looks like his security help is better than mine anyway :(.

[alsutton]

Why not use an off the shelf solution?

Apologies for coming to the thread late.

You should probably take a look at the enterprise password safe at http://www.enterprise-password-safe.com/, I think it has all the features you're looking for, and buying in would save you the development, support, and maintenance time of going down the route of an in-house solution.

If it doesn't I work for the company developing it and I know we add customer requests to the development plan so just get in touch.

Al.

[AricC]

Just saw this thread. What kind of platforms do you have to work with, ASP, ASP.Net, ASP 2.0, PHP, Perl etc... There are ton's of Login/Password examples available on the web that I'm sure would do plenty for what you want; I would hesitate on buying anything unless you really don't want to mess with doing a little coding.

[beporter]

Thank you very much for all of your feedback!

I'm afraid this is just one of many projects currently on my plate, and I apologize profusely if it takes me a little while to reply. I am anxious to sit down over the long weekend coming up and respond to all of your input, but right now I must attend to more pressing matters. (Clients are clients.)

Again, thank you all for your input, and I hope that this discussion will eventually turn into something (software, instructions, tips) that will be useful to others!

Please be patient with me, and expect some replies by next week!