Re: Hash/Salt password with mysql

20 Aug 2015

      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