Password Hashed + Salted before authentication with an embedded?script

[Arran Cudbard-Bell]

> On 10 Jan 2015, at 04:40, Robert Graham <robert_graham at uhaul.com> wrote:
> 
> Oh nevermind then, Im running 3.0.6....

Yeah FreeRADIUS 3.0.6 will work with SHA-224 SHA-256 SHA-384 and SHA-512.

It can produce hashes for SHA-256 and SHA-512 (using xlat expansions).

For SHA2 must be built with OpenSSL whereas, we fallback to our own
internal implementations of SHA1 and MD5 if OpenSSL isn't available.

Looking through the code it doesn't support SSHA2, because the SHA-2 digest 
is chosen automatically based on the digest length, and adding a random 
length salt messes that up.

Think the idea was to add a Salt-Length attribute, to avoid adding the
8 additional attributes required for the salt and unsalted version of each
of the SHA2 hashes, but after seeing how many issues relatively simple 
changes like removing Auth-Type from LDAP caused, I think it'd probably be
best to stick with the current scheme and add:

	sha224-password
	ssha224-password
	sha256-password
	ssh256-password
	sha384-password
	ssha384-password
	sha512-password
	ssha512-password

We can still keep sha2-password, and still do the autodetection there, but
we can't support a salted variant.

I'm generally against backporting features to a version which has been 
'feature frozen'. This case is no exception.

If we're going to make policies regarding merging features we should stick
to them. Backporting the SHA2 changes is not risk free, as there's some 
changes to how we initialise libssl to get access to all the EVP hashing 
functions which were not used before SHA2 support was added.

Sounds like this discussion is irrelevant as OP doesn't require SHA2 anyway,
but I would be curious if they require SSHA2 support, and what the FIPS
guidelines say on salting the hashes, and whether that's vital.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2