1

I'm working on a CMDB like application, where I have to store our security credentials (servers usernames & passwords, ...).

I'm looking for the best way to store them securely with those constraints :

  • Most users will NOT have access to all credentials (depending on user role)
  • We don't want all passwords being encrypted with the same key (already tried : when a user leave the company, it's a pain to change the key...)
  • Indeed, we don't want any private key to be hard written in app source, or even stored anywhere (in our previous version, private key was stored between our ears...)
  • We need to realize passwords strength audits (ie. parse decrypted passwords from a script)
  • There must not be any case where we can not access our credentials anymore (lost key, ...) => we don't want unauthorized persons to look at them but we don't want to loose them either => solution for this constraint could be regular export into a physical locker...

I'm not asking about application (https, ...) or database (no public access, ...) security concerns themselves but only about the storage side (could even NOT be in a database...? encrypted files or something...) : Is it possible to prevent someone, even having access to app code or database content (worst case scenario), to be able to read decrypted credentials ?

I'm aware that I'm asking for some magic solution, but I want to know it if it exists ;o)

Gauthier Delacroix
  • 689
  • 4
  • 20
  • 1
    credential management systems are worthless if you have glaring security flaws in your system as a whole. – rook Jul 24 '12 at 17:45
  • 1
    Simple: Users log on with *their own* password and gain access depending on an ACL. – tc. Jul 24 '12 at 18:30
  • @tc. Of course they will (with LDAP auth) but as I said, I don't ask for application side security but storage side. – Gauthier Delacroix Jul 24 '12 at 19:35
  • @Rook I totally aggree, but trust in higher levels isn't a security best practice... – Gauthier Delacroix Jul 24 '12 at 19:36
  • Each service should simply use your authentication/authorization server to decide if a user has access. If you mean storing passwords for *external* services (e.g. the company twitter account), then the system seems complicated enough that people will just paste them into a text file. – tc. Jul 25 '12 at 12:13

1 Answers1

2

The general case of what you're asking to do is not possible. All types of modern cryptography are mechanical advantage. That is, they use a small secret to guard a larger secret. If you can't keep the small secret safe, there is no safety. If you want the ability to give passwords on a password by password basis to someone, you are effectively giving them the secret -- the passwords -- that they would need to gain access to the items in question.

This very problem is why federated identity systems (Kerberos/Active Directory/etc.) systems exist -- to allow a central machine to authenticate users without exposing secrets to said users. But using a federated identity system requires cooperation between the system-to-be-logged-in-to and the identity service.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • Very good reasoning from you and in the linked article. Of course, security can never be total, but it has to be the best possible in every layer (I won't store credentials into a spreadsheet because security can't be total!). It comforts me to the idea that a good solution could be keeping the 'unwritten' unique key principle, but only shared with few people, needing to set the key on every app restart (and solving how to share key between threads...). The key is only present in threads memory. To look at the key, you have to change the code, involving app restart, involving loosing the key. – Gauthier Delacroix Jul 25 '12 at 07:51
  • @GauthierDelacroix To look at the key, you just have attach with a debugger/dump memory. If that is too difficult, you can just replace the binary with one that leaks the key and pretend the app crashed. – tc. Jul 25 '12 at 12:08
  • @tc. Yes, memory can be dumped but I won't try to go that far. Uncrypted credentials will stand in memory too. You can't totally protect something you need to display... Even so, I think there's a gap between extracting the key from a file and from the memory... – Gauthier Delacroix Jul 25 '12 at 12:23