[midPoint] REST - POSTing passwords in the clear

[Roberto Casiano]

Hi Radovan,

Thanks for the explanation.

How do you configure REST service to use HTTPS? Is it just in tomcat?

Regards,
Rob

From: midPoint [mailto:midpoint-bounces at lists.evolveum.com] On Behalf Of Radovan Semancik
Sent: Wednesday, 10 February 2016 3:51 AM
To: midpoint at lists.evolveum.com
Subject: Re: [midPoint] REST - POSTing passwords in the clear

Hi,

This is a bit complicated. Theoretically you should be able to send encrypted password, but to do that you will need a key. The key is symmetric and it is stored in midPoint keystore. If you take that key, encrypt the data, provide proper key identifier midPoint should accept that. We haven't tested that, but it theoretically should work.

... but ...

distributing the symmetric key from the midPoint keystore to the clients may not be a good idea from a security perspective. The password key in midPoint was designed to protect cleartext passwords in the database, e.g. if the attacker manages to make a database dump or if he can get database backups. The passwords stored there will be useless, because the key is stored outside of the database (and as it is regular Java keystore it can be stored even in HSM). By distributing this key over the network the attack surface significantly increases. It is all about the security trade-offs. However, there is one trick that you might be able to use: midPoint supports several keys used at the same time. One is (primary) encryption key that is used to store new password values. But midPoint will be able to decrypt data encrypted by any key that is in the keystore and that was properly identified in the ProtectedString data structure. Therefore you can create a new key and pair-wise distribute it between client and midPoint. MidPoint should be able to accept data encrypted like this. The ProtectedString data structure is based on (slightly simplified) XML Encryption standard, so you will find all the necessary documentation there. We have never tested this use case and therefore there may be some bugs. But any such bugs will be easy to fix.

Anyway ... my personal recommendation would be to choose entirely different solution: send the password in <clearValue> elements but protect the channel using HTTPS. This is clearly the simplest solution. It is not ideal, but it is used all over the cyberspace. Therefore if you go this way your solution is unlikely to have lower security than the rest of your system.



--

Radovan Semancik

Software Architect

evolveum.com


On 02/09/2016 08:01 AM, Roberto Casiano wrote:
Hi,

Using REST, we’re creating and modifying users, including setting passwords. However, the passwords are in cleartext. I noticed though that in the repository, the user passwords are encrypted.


1.      Is it possible to send encrypted passwords (during both user creation and modification)?

2.      Where can the REST client (which is our app) get the key that midPoint uses for the password?

Thanks,
Rob


This email, and any attachment, is confidential and also privileged. If you have received it in error, please notify me immediately and delete it from your system along with any attachments. You should not copy or use it for any purpose, nor disclose its contents to any other person.



_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

http://lists.evolveum.com/mailman/listinfo/midpoint







This email, and any attachment, is confidential and also privileged. If you have received it in error, please notify me immediately and delete it from your system along with any attachments. You should not copy or use it for any purpose, nor disclose its contents to any other person.


This email, and any attachment, is confidential and also privileged. If you have received it in error, please notify me immediately and delete it from your system along with any attachments. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160209/c9a7e406/attachment.htm>