Encrypting/Hashing clear text passwords in Java Bean

Wessel, Keith kwessel at illinois.edu
Mon Jan 25 19:56:09 UTC 2021

You might consider putting the password in a properties file that's not stored in Git. It could contain any passwords that you don't want in Git. You could add it to the list of property files to add at the top of idp.properties. Then, you could reference the properties in places like this bean in global.xml.


From: users <users-bounces at shibboleth.net> On Behalf Of Ullfig, Roberto Alfredo
Sent: Monday, January 25, 2021 1:51 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Encrypting/Hashing clear text passwords in Java Bean

It does serve a purpose. A configuration file like global.xml is stored in git. Moving the credentials to a password vault would be a better solution but I don't see how I can access a password vault from this bean code. We have code written in perl that accesses credentials from a password vault so that the scripts stored in git don't have clear-text credentials.

Roberto Ullfig - rullfig at uic.edu<mailto:rullfig at uic.edu>
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
From: users <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>> on behalf of Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>>
Sent: Monday, January 25, 2021 11:34 AM
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Re: Encrypting/Hashing clear text passwords in Java Bean

On 1/25/21, 12:20 PM, "users on behalf of Kim, Allan via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net<mailto:users-bounces at shibboleth.net%20on%20behalf%20of%20users at shibboleth.net>> wrote:

>    How would we go about replacing the clear text version with a hashed or encrypted string? Thanks!

Hashing it can't work, that's not reversible. Encrypting it is pointless because the decryption password would be in the same place.

The best improvement you can make is to abandon unattended restart as a feature and putting it on an encrypted volume that's unmounted at startup and during backups and only unlocked to start the service. Of course you could put the decryption password there too but that serves no purpose when you can just put the property itself there.

Or of course using a secrets manager or vault, but that just moves the problem to the credential used to access the vault, so I don't see them as moving the ball either.

-- Scott

For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Crullfig%40uic.edu%7Cd5079493e0d443cbbc8908d8c157a5b1%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637471929481633026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=NFb1vtrVrs0hf0TcLqiO25vNvvXX3epTULZN8J0qnp8%3D&reserved=0<https://urldefense.com/v3/__https:/nam04.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwiki.shibboleth.net*2Fconfluence*2Fx*2FcoFAAg&data=04*7C01*7Crullfig*40uic.edu*7Cd5079493e0d443cbbc8908d8c157a5b1*7Ce202cd477a564baa99e3e3b71a7c77dd*7C0*7C0*7C637471929481633026*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=NFb1vtrVrs0hf0TcLqiO25vNvvXX3epTULZN8J0qnp8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!DZ3fjg!vmqg6sf34sgiMb2ippK22UmebgeYwQVmhAJNVaG_KVTalBiWdC2C9i0LjtjUagrCLw$>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210125/1044e3df/attachment.htm>

More information about the users mailing list