Password storage

[roswell1329]

I work in a large enterprise environment, and I supervise a team of Unix admins that need to access several websites to verify different things about different servers. Access to these various websites are all password-protected, and I'm the only one who is notified when those passwords change -- at the request of the business. I'd love to set up a website that stores these passwords in a database that users of the website can view, but I know in the back of my head that storing passwords online is undeniably insecure. Surely this can't be a new problem, though. How do other people get around this problem?

My solution was to build a server from scratch with only 1 logon...mine. On that server run a PHP/MySQL combination with the passwords stored in the database using a symmetric encryption algorithm. Then when a user logs in, store the key in the users cache for the session, then remove it when they leave or have it timeout. Obviously, I'd have both my private key and my encrypted text on the same system (insecure!), but I don't know how else to do it. Any ideas?

[valhallen]

use 2 way encryption to store the password hashes. Encrypt password - store in DB (create user login system so only those admins who are logged in can access the encrypted keys)

they can then choose the encrypted hash they want for whatever site. And use the static private key to decrypt it. So the even if the password changes you just replace the old hash with your new one and provided you keep the key the same all the time (maybe issue new keys at regular ties to all admins for additional security tho) then the admins can decrypt it at their end.

[XTC46]

I'm the only one who is notified when those passwords change -- at the request of the business.

so, once you have them, you publish them? how does that make sense?

how many admins are we talking about? how many servers? are they standard passwords (the same on for all servers) how often are they changed? I STRONGLY suggest you do not store passwords in an online database. Notify them in person, if possible. How are you notified of the change? just replicate that to them.

[catch]

It is better to just do a good thing than searching for a good way to do a bad thing.

An access system that manages and grants short terms access tokens to the various sites based on the user supplied passphrase, source address, and any other useful measures to limit access effectively (grant X access to Y only during hours A to B with passphrase P and source address of S... etc)

This would be much simpler to develop and a complete compromise of the access management system would not explicitly grant the attacker any new access.

cheers,

catch

[zencoder]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I used to work there with roswell, so I know some of these details.

Admins = anywhere from 5 to 20 people or so.

Servers = could be a hundred or more...it depends on what specific
portion he is handling...a lot of protected web pages with system
specific details, some of them might be remote consoles to servers,
etc.

Passwords = not usually standard, there might be some repetition, but
not a whole lot...the idea is to avoid this practice. They probably
don't change very often if at all.

The problem is, this team suports thousands of servers globally. A
lot of them are legacy platforms that have been inherited by this
team, and none of them meet any single standard.

The passwords they need are for everything from local backup root
accounts to remote consoles to network console drops to login
credentials for vendor support pages to application logins to.... on
and on and on, ad naseum. It is way too much information to pass on
verbally; that much info would have to be disseminated by
email...which breaks security practices, and brings us back to
roswells question.

roswell, you are the guy that bitches at me for not considering
public key encryption. Can't you protect the data via public key,
encrypted to everyones keypair? Don't tell me you haven't required
they generate key pairs for use at work...! I'll have to come write
you a process for that, if you haven't!

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQu67CWAm/qcOht6xEQL6IQCg17LJwWu0RoC/qrvqmsQeeLM+4P4AoNsi
UwZkY+IgtydPONAEQc82GQXx
=jgUB
-----END PGP SIGNATURE-----

[roswell1329]

Originally posted here by zencoder
roswell, you are the guy that bitches at me for not considering
public key encryption. Can't you protect the data via public key,
encrypted to everyones keypair? Don't tell me you haven't required
they generate key pairs for use at work...! I'll have to come write
you a process for that, if you haven't!
[/B]

Heheheheh. I would have LOVED to implement encryption keypairs, but it's still a no-go with the business. They complain about convenience. Don't all users, though?

I think most of the above answers are perfect. I'll just create a system that creates a private/public keypair upon registration, and I'll store the private key somehow on the users computer. Then, when I need to change passwords, I'll just encrypt it with every public key in the users table. That way, the only thing stored online is the hash. Great idea everyone! Thanks!

My only problem now is how to store the private key! If I store it as a cookie, it could get wiped out. Guess I'll keep working on that one.

Thanks again, everyone.