2

The problem: some environments need to use plain text credentials or long-lived tokens in order to unlock a specific functionality. Examples include

  • third party legacy services which need a login/password for authentication (they do not support oAuth, OpenID, short-term tokens or similar solutions and cannot be adapted)
  • unlocking of an encrypted vault which require the input of a password at application start

There is a way to programmatically trigger these services but this requires to present plaintext credentials.

What is the current consensual position on solutions for the storage of such credentials?

One solution is to encrypt them, with more or less elaborate ways to disconnect the encryption key from the code. I do not want the teams in charge of this part of the project to invent their own solution as it is likely to be weak. I would appreciate any pointers if there is something tangible on that subject (I did not fond anything, OWASP does not even try to hint that this is acceptable, which is understandable but not very useful).

I also saw that HSMs are suggested but I fail to understand how they facilitate the recovery of the key/credentials (I understand their value as secure data stores).

  • The threat model is very different for disk encryption than it is for creds on third party services. Perhaps you should remove the disk encryption bit, and give some more examples of other use cases. I guess credit card numbers, used for "save this credit card for later use" would be another example. – paj28 May 23 '16 at 13:29
  • "disk encryption" was indeed not a good description of what I meant: encrypted vaults (accessed from an application). I will update the question. Credit cards would be another example. – WoJ May 23 '16 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.