Hi all, I'm trying to configure freeradius with mysql authentication. Specifically I'm trying to use a somehow longer hash. I came upon the thread http://lists.freeradius.org/pipermail/freeradius-users/2015-January/075505.h... Which explains using update control to query hash and salt from the database. It goes something like this: update control { Tmp-String-0 := "%{sql:SELECT hash FROM <table> WHERE <clause>}" Tmp-String-1 := "%{sql:SELECT salt FROM <table> WHERE <clause>}" } update control { SSHA2-512-Password := "0x%{control:Tmp-String-0}%{control:Tmp-String-1}" } This is probably a beginners question, but I don't know what to put in the where clause as I don't know which parameters are available at the time of calling this, ideally the statement will look like this: Assume table: users(id, username, hash, salt) update control { Tmp-String-0 := "%{sql:SELECT hash FROM users WHERE <USERNAME_CONNECTING = username>}" Tmp-String-1 := "%{sql:SELECT salt FROM users WHERE <USERNAME_CONNECTING = username>}" } Any idea how to achieve that? Sepcifically how to get the username the user is currently submitting
update control { Tmp-String-0 := "%{sql:SELECT hash FROM users WHERE <USERNAME_CONNECTING = username>}" Tmp-String-1 := "%{sql:SELECT salt FROM users WHERE <USERNAME_CONNECTING = username>}"
}
WHERE username='%{User-Name}' man unlang Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi Arran and thanks for the quick reply Unfortunately I can't seem to get it running, getting a "[pap] Passwords don't match" error Here's the simplest example I could come up with: username: freddi password: wilma salt: berlin Then hashed the password+salt: echo -n "wilmaberlin" | openssl sha1 (stdin)= ae5fb20004bd032779db7ecb7eda7973fa25d281 In the users table, the hash is set to that sha1, while salt=berlin Then here's the configuration from sites-enabled/default: update control { Tmp-String-0 := "%{sql:SELECT hash FROM accounts WHERE username = '%{User-Name}'}" Tmp-String-1 := "%{sql:SELECT salt FROM accounts WHERE username = '%{User-Name}'}" } update control { SSHA-Password := "%{control:Tmp-String-0}%{control:Tmp-String-1}" } I removed the 0x before the password value, so that it gets normalized Any idea what I'm doing wrong? Regards and thanks On Sun, Aug 9, 2015 at 8:22 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
update control { Tmp-String-0 := "%{sql:SELECT hash FROM users WHERE <USERNAME_CONNECTING = username>}" Tmp-String-1 := "%{sql:SELECT salt FROM users WHERE <USERNAME_CONNECTING = username>}"
}
WHERE username='%{User-Name}'
man unlang
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Aug 10, 2015, at 3:38 PM, Moataz Elmasry <zaza1851983ml@googlemail.com> wrote:
Hi Arran and thanks for the quick reply
Unfortunately I can't seem to get it running, getting a "[pap] Passwords don't match" error
Here's the simplest example I could come up with:
username: freddi password: wilma salt: berlin
Then hashed the password+salt: echo -n "wilmaberlin" | openssl sha1 (stdin)= ae5fb20004bd032779db7ecb7eda7973fa25d281
In the users table, the hash is set to that sha1, while salt=berlin
Then here's the configuration from sites-enabled/default:
update control { Tmp-String-0 := "%{sql:SELECT hash FROM accounts WHERE username = '%{User-Name}'}" Tmp-String-1 := "%{sql:SELECT salt FROM accounts WHERE username = '%{User-Name}'}" }
update control { SSHA-Password := "%{control:Tmp-String-0}%{control:Tmp-String-1}" }
I removed the 0x before the password value, so that it gets normalized
Is the salt hex encoded also when it comes out of the db? -Arran
No I didn't hex encode it. I'm using a stock freeradius 2.1.12 coming with Ubuntu 14.04 The table has been created as follows: This is the table schema CREATE TABLE `accounts_dummy` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(45) NOT NULL, `hash` varchar(255) NOT NULL, `salt` varchar(45) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `id_UNIQUE` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1; And insert the user as follows echo "INSERT INTO `accounts_dummy` (`id`, `username`, `hash`, `salt`) VALUES ('1', 'freddi', '$( echo -n "wilmaberlin" | openssl sha1)', 'berlin');" > insert_user.sql After insertion I made sure that the sha1 in the db is: ae5fb20004bd032779db7ecb7eda7973fa25d281 On Mon, Aug 10, 2015 at 9:44 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Aug 10, 2015, at 3:38 PM, Moataz Elmasry < zaza1851983ml@googlemail.com> wrote:
Hi Arran and thanks for the quick reply
Unfortunately I can't seem to get it running, getting a "[pap] Passwords don't match" error
Here's the simplest example I could come up with:
username: freddi password: wilma salt: berlin
Then hashed the password+salt: echo -n "wilmaberlin" | openssl sha1 (stdin)= ae5fb20004bd032779db7ecb7eda7973fa25d281
In the users table, the hash is set to that sha1, while salt=berlin
Then here's the configuration from sites-enabled/default:
update control { Tmp-String-0 := "%{sql:SELECT hash FROM accounts WHERE username = '%{User-Name}'}" Tmp-String-1 := "%{sql:SELECT salt FROM accounts WHERE username = '%{User-Name}'}" }
update control { SSHA-Password := "%{control:Tmp-String-0}%{control:Tmp-String-1}" }
I removed the 0x before the password value, so that it gets normalized
Is the salt hex encoded also when it comes out of the db?
-Arran
On 10 Aug 2015, at 17:23, Moataz Elmasry <zaza1851983ml@googlemail.com> wrote:
No I didn't hex encode it.
I'm using a stock freeradius 2.1.12 coming with Ubuntu 14.04
The table has been created as follows:
This is the table schema
CREATE TABLE `accounts_dummy` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(45) NOT NULL, `hash` varchar(255) NOT NULL, `salt` varchar(45) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `id_UNIQUE` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
And insert the user as follows echo "INSERT INTO `accounts_dummy` (`id`, `username`, `hash`, `salt`) VALUES ('1', 'freddi', '$( echo -n "wilmaberlin" | openssl sha1)', 'berlin');" > insert_user.sql
After insertion I made sure that the sha1 in the db is: ae5fb20004bd032779db7ecb7eda7973fa25d281
So you'd want: update control { SSHA-Password := "%{control:Tmp-String-0}%{hex:control:Tmp-String-1}" } That way you've concatenated the digest, which is hex, with the salt, which is now also hex. When rlm_pap normalises the string, the buffer will contain the binary hash, and the cleartext salt, concatenated together. Here's what the code does: static rlm_rcode_t CC_HINT(nonnull) pap_auth_ssha(rlm_pap_t *inst, REQUEST *request, VALUE_PAIR *vp) { fr_SHA1_CTX sha1_context; uint8_t digest[128]; RDEBUG("Comparing with \"known-good\" SSHA-Password"); /* Attempt to convert base64 and hex, back to binary */ if (inst->normify) { normify(request, vp, 20); } if (vp->vp_length <= 20) { REDEBUG("\"known-good\" SSHA-Password has incorrect length"); return RLM_MODULE_INVALID; } /* Run the password we received from the user through sha1 */ fr_sha1_init(&sha1_context); fr_sha1_update(&sha1_context, request->password->vp_octets, request->password->vp_length); /* Run any bytes after the sha1 hash through sha1 */ fr_sha1_update(&sha1_context, &vp->vp_octets[20], vp->vp_length - 20); fr_sha1_final(digest, &sha1_context); /* Compare the resulting digests */ if (rad_digest_cmp(digest, vp->vp_octets, 20) != 0) { REDEBUG("SSHA digest does not match \"known good\" digest"); return RLM_MODULE_REJECT; } return RLM_MODULE_OK; } Repeated calls to fr_sha1_update are the same as if you'd fed the concatenated string into sha1. If your salt is not hex armoured, the normalisation code is going to see the string contains non hex chars, and assume its in its binary/cleartext form already. If this still doesn't work, please post the output (radiusd -X) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
It worked!!!! Many thanks. The problem was, as you correctly pointed that the salt was coming out of the db not hex encoded. Here is the final settings of sites-enabled/default: update control { Tmp-String-0 := "%{sql:SELECT hash FROM accounts_dummy WHERE username = '%{User-Name}'}" Tmp-String-1 := "%{sql:SELECT salt FROM accounts_dummy WHERE username = '%{User-Name}'}" } update control { SSHA-Password := "0x%{control:Tmp-String-0}%{control:Tmp-String-1}" } Here's a nodejs function that will return the hash and the salt hex to be used in two separate columns: var hashSimple = function (value, salt) { var shasum = crypto.createHash('md5') shasum.update(value) shasum.update(salt) console.log("Hash encoded in hex=" + shasum.digest('hex')) console.log("Salt encoded in hex=" + new Buffer(salt).toString("hex")) } or if someone wants to store both into the 'radcheck' table as one field as usual instead of using this twisted way like me, then here's how to var hashSimple = function (value, salt) { var shasum = crypto.createHash('md5') shasum.update(value) shasum.update(salt) console.log("Full hash encoded in hex=" + new Buffer.concat([ shasum.digest() , new Buffer(salt) ]).toString('hex')) } So it was kinda a user misunderstanding, the tutorial on: https://www.packtpub.com/books/content/freeradius-authentication-storing-pas... is quite good actually, but I misunderstood what really the Perl script does Thanks and regards On Tue, Aug 11, 2015 at 1:29 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 10 Aug 2015, at 17:23, Moataz Elmasry <zaza1851983ml@googlemail.com> wrote:
No I didn't hex encode it.
I'm using a stock freeradius 2.1.12 coming with Ubuntu 14.04
The table has been created as follows:
This is the table schema
CREATE TABLE `accounts_dummy` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(45) NOT NULL, `hash` varchar(255) NOT NULL, `salt` varchar(45) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `id_UNIQUE` (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
And insert the user as follows echo "INSERT INTO `accounts_dummy` (`id`, `username`, `hash`, `salt`) VALUES ('1', 'freddi', '$( echo -n "wilmaberlin" | openssl sha1)', 'berlin');" > insert_user.sql
After insertion I made sure that the sha1 in the db is: ae5fb20004bd032779db7ecb7eda7973fa25d281
So you'd want:
update control { SSHA-Password := "%{control:Tmp-String-0}%{hex:control:Tmp-String-1}" }
That way you've concatenated the digest, which is hex, with the salt, which is now also hex.
When rlm_pap normalises the string, the buffer will contain the binary hash, and the cleartext salt, concatenated together.
Here's what the code does:
static rlm_rcode_t CC_HINT(nonnull) pap_auth_ssha(rlm_pap_t *inst, REQUEST *request, VALUE_PAIR *vp) { fr_SHA1_CTX sha1_context; uint8_t digest[128];
RDEBUG("Comparing with \"known-good\" SSHA-Password");
/* Attempt to convert base64 and hex, back to binary */ if (inst->normify) { normify(request, vp, 20); } if (vp->vp_length <= 20) { REDEBUG("\"known-good\" SSHA-Password has incorrect length"); return RLM_MODULE_INVALID; }
/* Run the password we received from the user through sha1 */ fr_sha1_init(&sha1_context); fr_sha1_update(&sha1_context, request->password->vp_octets, request->password->vp_length);
/* Run any bytes after the sha1 hash through sha1 */ fr_sha1_update(&sha1_context, &vp->vp_octets[20], vp->vp_length - 20); fr_sha1_final(digest, &sha1_context);
/* Compare the resulting digests */ if (rad_digest_cmp(digest, vp->vp_octets, 20) != 0) { REDEBUG("SSHA digest does not match \"known good\" digest"); return RLM_MODULE_REJECT; }
return RLM_MODULE_OK; }
Repeated calls to fr_sha1_update are the same as if you'd fed the concatenated string into sha1.
If your salt is not hex armoured, the normalisation code is going to see the string contains non hex chars, and assume its in its binary/cleartext form already.
If this still doesn't work, please post the output (radiusd -X)
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Moataz Elmasry