How can Freeradius detect if the password provided is right when only the salted hash is stored in the database without the salt

Question

I am discovering both Freeradius and the password hashing mechanism. I built a database (in MySQL) to store the passwords of some users. I have a user with the password in clear text, another one hashed in SHA256 without salt and the last one hashed in SHA256 and salted.

I used this script to create the salted hash : https://gist.github.com/bestrocker221/f506eee8ccadc60cab71d5f633b7cc07

When I am testing the connexion to the radius server (with the command radtest and with another computer running ubuntu), all of the accounts can be accessed.

Here is the database content : (Each user have the same password, "passroot")

mysql> select * from radcheck;
| id | username | attribute         | op | value
|  1 |   user1  |Cleartext-Password | := | passroot
|  2 |   user2  |SHA2-Password      | := | ef653cafdcaf5b3733c7c5aa24b781c5c952618642efd2abc04b9c6efccac8258bc84a881850d9ffa8e6c91953c8ca7613f49dea007ae6437ccf26b8f10fadfb
|  4 |   toto   |SSHA2-256-Password | := | /F8Bymi/qgL4rQHP9C+8jDciSLmr/PZEc5JJNoCwRelzZWxkZW1lcg==

The authentication with the account using the salt method is working :

root@Principale:"/share# radtest toto passroot 192.168.150.1 1812 passroot
Sent Access-Request Id 117 from 0.0.0.0:39617 to 192.168.150.1:1812 length 74
User-Name = "toto"
User-Password = "passroot"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
Message-Authenticator = 0x00
Cleartext-Password = "passroot"
Received Access-Accept Id 117 from 192.168.150.1:1812 to 192.168.150.1:39617   length 20

root@Principale:"/share# tail /var/log/freeradius/radius.log
Tue May 4 16:32:07 2021 : Info: Need 7 more connections to reach 10 spares
Tue May 4 16:32:07 2021 : Info: rlm_sql (sql): Opening additional connection (42), 1 of 29 pending _slots used
Tue May 4 16:32:07 2021 : Auth: (164) Login OK: [toto/passroot] (from client test port 1812)
root@Principale:"/share#

I don't understand how freeradius can match the password provided by the user to the salted hash stored in the database when he doesn't know the salt I used.

I'm just going to chime in here: do not use SHA-anything for password storage. There are significantly more appropriate algorithms out there. — Nzall, May 05 '21 at 06:52
Can you give me some name you think about ? I found this list of compatible hash with freeradius for EAP-GTC authentication : Clear-text, NT hash, MD5, Salted MD5, SHA1 & 2, Salted SHA1 & 2, Unix Crypt. — molik, May 05 '21 at 07:06
@molik It appears that FreeRadius does not support anything more secure than SHA-2 unfortunately. Ideally it should support something more modern like bcrypt, Argon2id, scrypt or PBKDF2, which are the current standards for password security. — Nzall, May 05 '21 at 11:11
FreeRADIUS supports PBKDF2 in both master branch and v3.0.x - https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_pap/rlm_pap.c#L843 https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_pap/rlm_pap.c#L1327 — Arran Cudbard-Bell, May 06 '21 at 19:17
@ArranCudbard-Bell adding a new *fast* hash to hash passwords in 2017 is crazy. — CodesInChaos, May 07 '21 at 17:04
Meh... 3 > 2, and with OpenSSL's EVP interface it was only few lines of code. Someone was complaining we didn't support it on the user's mailing list. Much like people here are complaining we don't support bcrypt, Argon2id, scrypt and PBKDF2... Realistically I'm betting a good portion of the passwords for people doing user based authentication for WiFi are still cleartext or MD4 (NT-Password)... Sure you can be more secure with terminal logins, but you're still limited by your user management software as the majority aren't going to roll their own. — Arran Cudbard-Bell, May 07 '21 at 17:28
I'll tell you what, for my sins of adding SHA3 support, I'll implement one of the other more hipsteresque hashing schemes. Only caveats are that it must have a canonical format, and be supported by at least one popular/open source user/subscriber management solution. Place your votes... — Arran Cudbard-Bell, May 07 '21 at 17:34

score 60 · Accepted Answer · answered May 04 '21 at 15:18

60

The hash and salt are both in the value column. After Base64 decoding, the first 32 bytes are the hash, and the rest is the salt (in your case, it's the ASCII string seldemer).

answered May 04 '21 at 15:18

Joseph Sible-Reinstate Monica

7,110
3
21
35

8

`seldemer` (sel de mer) translates as "sea salt" in french btw – Jean-François Fabre May 06 '21 at 14:46
1

Is that salt always used, or only in test? Because a salt is supposed to be different for each user, a fixed salt is almost as bad as no salt. – CodesInChaos May 06 '21 at 16:27
@CodesInChaos Why do you think there's a fixed salt? – Joseph Sible-Reinstate Monica May 06 '21 at 16:30
1

@JosephSible-ReinstateMonica I am not CodesInChaos, but I would assume it is because 'seldemer' doesn't seem all too random. – cjnash May 06 '21 at 17:20
2

@cjnash The OP did manually pick that salt, but it was just for that one user's password. If another user had a salted password, it would have its own salt. They wouldn't have to be the same. – Joseph Sible-Reinstate Monica May 06 '21 at 17:21
2

@JosephSible-ReinstateMonica It's clearly not random, and not part of the code the OP showed. And I wouldn't be surprised if somebody competent enough to choose SHA-256 as password hash, would choose a hardcoded "salt". – CodesInChaos May 06 '21 at 17:48
For my test the salt was not radom :) and hardcoded in the github script. I edited the last 2 lines to change the password and the salt. – molik May 08 '21 at 21:02

How can Freeradius detect if the password provided is right when only the salted hash is stored in the database without the salt

1 Answers1