[RADIATOR] Using unix crypto ?

Patrik Forsberg patrik.forsberg at globalconnect.se
Wed Apr 14 07:01:36 UTC 2021

I see.. thanks for your response then I at least know why 😊

Best Regards,

-----Original Message-----
From: radiator <radiator-bounces at lists.open.com.au> On Behalf Of Heikki Vatiainen
Sent: den 13 april 2021 19:25
To: radiator at lists.open.com.au
Subject: Re: [RADIATOR] Using unix crypto ?

On 13.4.2021 16.56, Patrik Forsberg wrote:

> I’m trying to use something like $2y$ crypto from a sql query but .. 
> either I’ve failed in generation of the hash (using php password_hash) 
> or something is missing to allow Radiator to verify against this hash ..
> so I’m wondering if there are any package that is needed ?

Hashes $2a$, $2x$ and $2y$ are passed to Perl's crypt() function which in turn uses libc's crypt(), at least for some hashes. For this reason Radiator's ability to use $2y$ currently depends on the OS it runs on.

Looking at our tests, for example CentOS/RedHat 8 and Ubuntu 20.04 are supposed to have bcrypt but, for example, Debian 10 (buster) is not supposed to work. In other words, 'bad password' is always expected on buster.

> I’ve tried Crypt::Blowfish and Crypt::UnixCrypt but they made no 
> difference whatsoever.. also tried installing the mcrypt package ..
> still no difference.. ☹

Might be that Authen::Passphrase::BlowfishCrypt would be better. It seems that other than $2a$ is not supported on all bcrypt based modules. 
But in any case, because Radiator currently only uses crypt(), it would need code changes in addition to finding a module that would work.

> I’m running this under a Debian Linux 10 (buster).
> I’ve tried to put radiator into trace mode(trace 9) but it doesn’t 
> show anything wrong either (other then “bad password”).. and the 
> passwordlog shows the correct password being received and the hash is 
> what is expected from the sql.. so it is apparent that it is Radiator 
> that decides that the password is wrong for some reason..

To summarise: at this point $2y$ support depends on the OS Radiator runs on. OS independent support would need code changes so it's not immediately possible with, for example, having suitable modules installed.


Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
radiator mailing list
radiator at lists.open.com.au

More information about the radiator mailing list