Psychotomy

So … One of the tasks I’ve been looking at is a password server at the office. The major driving goal is that, after 5 years or so of succesfully NOT changing the password every 90-days, someone at the top of the Oracle group got a bug up their ass (actually, I think it’s a new head guy) and they’re declaring that they WILL change them now.

They’ve also said that they can’t be bothered to figure out who uses what accounts or to tell them that the passwords are changing. So one solution being tossed around is some dual account strategy where everything has two complete access points on offset cycles and some kind of SSL authenticated session managing so that we don’t have to worry about the passwords anymore because they won’t be used we’ll have the SSL certs. Without passwords? NOOO! There’ll still be passwords, we just won’t be using them, so it won’t matter if they change. But the certs, will they have passwords? NO!!! that’s the whole point! that way it’s secure! because now the connection is encrypted!

But … uh … if I can just swipe the cert, now, instead of the password … what has this gained us? other than that now we can eliminate that pesky security precaution of changing the password, because presumably we’re not talking about cycling the certs every whenever … “Well, if it’s compromised, we can just change the SSL cert and it won’t matter!” … uh, we can do that now. It’s called changing the PASSWORD. And it’s about 90x simpler than creating a cert. Oh, and self-signed non-authenticated certs area PITA, and I wouldn’t garauntee Oracle would even accept them for connections, lets be honest. OH! AND the guy proposing it has no idea if it’s even feasible! functional! possible!

My idea was to set up a database that has all the user/server/password combos that are used and the apps that use them. then a web service. and then App A connects to SERVICE, says “I am A, tell me what I need to know” and gets back all the relevant password/connection information. The passwords can be stored encrypted (I’m looking at mysql’s builtin AES, since I need to get it back out). The service can be HTTPS, so it’s not listenable. Then the service gets the password out, and passes it to the app that asked. If I look up client certs (same problems as their plan, but I’m not trying to use them to avoid the password, see?) and set it up, now I can use the cert to authenticate the app (I can also use the request IP for furtherance probably). We can set up however many accounts for any system. We can set up multiple different types of accounts. One app can have 3 databases to talk to on 3 different types of database and 2 or 3 account logins apiece

And the biggest danger? Well, the app can get it’s data. See, technically, if the SSL Cert is swiped and used in a forged request, well, then that forged request would get the credentials for use that app had. But you know what? If they’re swiping the cert, they could just swipe the password file, Because if the system can use it, the system can access it. And if the system can access it, then a sufficiently wide hole will allow the attacker to access it. And if they’re in for a penny, they’re in for a pound.

So, thus, the question. How do you secure it? Because, really, you need to secure the password(s) in such a way that the app can’t access them. That way it can’t divulge them. But, obviously, it then also can’t USE them. Catch-22!

Of course, the other thing to do would be to set up a series of READ ONLY accounts for the query systems (ie — apps), and then SEPARATE accounts that have privs (for the administrative features, etc). But THAT would require giving someone who knew what they were doing control. and that can’t be allowed to happen. We won’t discuss why, because that’d be wrong ;)

Posted in: work by attriel /