[midPoint] REST - POSTing passwords in the clear

[Radovan Semancik]

Hi,

Yes, it is just Tomcat. MidPoint does not have its own web listeners. It 
relies completely on web container. Therefore all the channel security 
settings of web container also apply to midPoint services (both REST and 
SOAP). Some people also deploy Apache HTTP Server or nginx as a reverse 
proxy in front of Tomcat. So that might also be good point to set up 
SSL/TLS. The web service and rest service have fixed URL prefixes, 
therefore the policies can be applied selectively (e.g. do not allow 
non-HTTPS connection to those prefixes).


-- 
Radovan Semancik
Software Architect
evolveum.com



On 02/09/2016 11:12 PM, Roberto Casiano wrote:
>
> 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. /
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160210/13fdd664/attachment.htm>