This topic has been locked.
2 replies Latest Post - 2012-11-08T02:39:37Z by SystemAdmin
Pinned topic Storing UIDs and PWDs on XI50
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
There are many instances where services on datapower have to make REST calls using preconfigured UIDs and pwds for authentication on target systems. Once can supply them on basicAuth headers, but it is either plain text or base-64 encoded. We are looking for a encrypted location to store such UIDs and PWDs. Is there anyway to store and reference them from the encrypted portion of storage on datapower(somthing like crypto shared secret etc).
Updated on 2012-11-08T02:39:37Z at 2012-11-08T02:39:37Z by SystemAdmin
momasa 100000RA6A19 PostsACCEPTED ANSWER
Re: Storing UIDs and PWDs on XI502012-11-06T14:11:19Z in response to SystemAdminHello, in my opinion this is a general question and I ask myself whether there is solution at all.
Where would you store your key for decrypting your passwords? Datapower must have access to the key, so any attacker on the device has it too (sooner or later).
I think you should restrict the access to the device very well. Some admins will know the secrets, all others should have no access.
Never the less, if there is a best practice, I'm interested in too.
SystemAdmin 110000D4XK6772 PostsACCEPTED ANSWER
Re: Storing UIDs and PWDs on XI502012-11-08T02:39:37Z in response to SystemAdminAs Uli noted, any technique a service can do to retrieve the password (i.e. read a key and decrypt it) can be done by someone with access to the appliance. At the very least, they can write their own service on the box (remember, you gave them access) to retrieve and decrypt the password just like you did. But the lazy eavesdropper won't bother with that. They'll just slap a probe on your original service and read your BasicAuth passwords from the headers that your service populated.
The only way to avoid storing passwords on DP is to retrieve the passwords from another server that stores them securely. You would verify your identity to this password-server using your private certificate (and hopefully not another password, otherwise it defeats the whole purpose!). This is usually overkill; both in terms of complexity and performance.
Of course, the password server has the same problem. We've just pushed it off on someone else. Logically, this problem has no solution.