Options to obfuscate the LDAP/JDBC Realm passwords in SHIRO.INI

[Andreas Reichel <an...@manticore-projects.com>]

Greetings!

We are using SHIRO to authenticate and authorise users vs JDBC and AD
and it works just great in general. Thank your for providing this
software.
Unfortunately we are facing some concerns of clients, that Passwords
for the JDBC or AD realms are written out in the SHIRO.INI file. I do
not share those concerns, but I need to respond to it.

So please allow me to ask: are there any standard options to
obfuscate those passwords?
(If not I would have to implement a simple ROT13 in the source code
myself 😞).

Thank you already for hints and cheers!
Andreas

Re: Options to obfuscate the LDAP/JDBC Realm passwords in SHIRO.INI

[Andreas Reichel <an...@manticore-projects.com>]

On Mon, 2024-09-02 at 11:44 -0500, lenny@flowlogix.com wrote:
> It’s not a good practice to store passwords in plain text, period.
> Shiro.ini in particular gets checked into code repositories, and it’s
> not a good place for passwords to be.
> 
> Current “good practice” is something called “zero trust” and just
> because the system is behind ssh, it doesn’t mean
> that a threat actor cannot hack into it some other way, and get the
> password.
> Plain-text passwords just open up more security threats that you can
> possibly think of.

Thank you for your advise, Lenny. I do appreciate and in general you
are certainly right.
However, for my example we do not talk about real users and passwords
but only about the technical accounts talking to the AD or JDBC realm
when authenticating or authorising a real user against it.

Those technical users have zero rights or capabilities but can only
query the realm for "is password valid for user" or "does user have
role".
So I don't see any possibility to harm in this specific scenario, even
when publish those passwords in the internet. Its just audit drones
searching for a justification of their mere existence.

For us, shiro.ini or any client/user specific setting/configuration is
always FAR AWAY from the source in its own linux os user config
directory.
But that's a story for another day and I am going of topic here.

The provided documentation solves my problem and I thank you both.

All the best
Andreas

Re: Options to obfuscate the LDAP/JDBC Realm passwords in SHIRO.INI

[le...@flowlogix.com]

Hi, Andreas,

I second everything Benjamin says.

It’s not a good practice to store passwords in plain text, period.
Shiro.ini in particular gets checked into code repositories, and it’s not a good place for passwords to be.

Current “good practice” is something called “zero trust” and just because the system is behind ssh, it doesn’t mean
that a threat actor cannot hack into it some other way, and get the password.
Plain-text passwords just open up more security threats that you can possibly think of.

> On Sep 2, 2024, at 11:38 AM, Andreas Reichel <an...@manticore-projects.com> wrote:
> 
> On Mon, 2024-09-02 at 18:31 +0200, Benjamin Marwell wrote:
>> Hello Andreas!
>> 
>> Since current Linux and Unix distributions have environment variables
>> secured from other users nowadays, one way would be to inject them at
>> runtime via ${ENV_VARIABLE_NAME}.
>> 
>> A few examples are in our documentation:
>> https://shiro.apache.org/configuration.html <https://shiro.apache.org/configuration.html>
>> 
>> Let us know if that works for you.
> 
> You Sir are my hero!
> This works perfectly fine for the audit drones because it gets the ball back into the client's court:
> 
> 1) if they don't want to hard code passwords of those technical user accounts, then provide the System properties when starting the Web Application (which will be so much fun)
> 2) otherwise accept that the password has to be somewhere and secure your server properly against unauthorised access
> 
> Btw, those servers holding this shiro.ini files have SSH password only access with accounts like "admin/admin" 😄
> What a time to be alive.
> 
> Thank you so much for prompt round turn and cheers!
> Andreas

Re: Options to obfuscate the LDAP/JDBC Realm passwords in SHIRO.INI

[Andreas Reichel <an...@manticore-projects.com>]

On Mon, 2024-09-02 at 18:31 +0200, Benjamin Marwell wrote:
> Hello Andreas!
> 
> Since current Linux and Unix distributions have environment variables
> secured from other users nowadays, one way would be to inject them at
> runtime via ${ENV_VARIABLE_NAME}.
> 
> A few examples are in our documentation:
> https://shiro.apache.org/configuration.html
> 
> Let us know if that works for you.

You Sir are my hero!
This works perfectly fine for the audit drones because it gets the ball
back into the client's court:

1) if they don't want to hard code passwords of those technical user
accounts, then provide the System properties when starting the Web
Application (which will be so much fun)
2) otherwise accept that the password has to be somewhere and secure
your server properly against unauthorised access

Btw, those servers holding this shiro.ini files have SSH password only
access with accounts like "admin/admin" 😄
What a time to be alive.

Thank you so much for prompt round turn and cheers!
Andreas

Re: Options to obfuscate the LDAP/JDBC Realm passwords in SHIRO.INI

[Benjamin Marwell <bm...@apache.org>]

Hello Andreas!

Since current Linux and Unix distributions have environment variables
secured from other users nowadays, one way would be to inject them at
runtime via ${ENV_VARIABLE_NAME}.

A few examples are in our documentation:
https://shiro.apache.org/configuration.html

Let us know if that works for you.

- Ben

Am Mo., 2. Sept. 2024 um 17:05 Uhr schrieb Andreas Reichel
<an...@manticore-projects.com>:
>
> Greetings!
>
> We are using SHIRO to authenticate and authorise users vs JDBC and AD and it works just great in general. Thank your for providing this software.
> Unfortunately we are facing some concerns of clients, that Passwords for the JDBC or AD realms are written out in the SHIRO.INI file. I do not share those concerns, but I need to respond to it.
>
> So please allow me to ask: are there any standard options to obfuscate those passwords?
> (If not I would have to implement a simple ROT13 in the source code myself 😞).
>
> Thank you already for hints and cheers!
> Andreas
>