On 6 Feb 2014, at 19:46, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
Support for SHA-224 SHA-256-SHA-384 and SHA-512 hashes has been added to rlm_pap. The correct digest algo is determined by the length of the value of SHA2-Password.
28 bytes - SHA-224 32 bytes - SHA-256 48 bytes - SHA-384 64 bytes - SHA-512
Wow, good news indeed!
So, all those different lengths are so to speak "multiplexed" into one single "SHA2-Password" attribute? Also, what is the encoding? base64?
Binary, hex, or base64, it uses the same normifying logic as the other hashes. So I guess there's the extremely unlikely possibility a SHA512 digest which consisted entirely of hexits could be decoded as a SHA256 password, but that's why there's an option to turn normification off and do the conversion manually with the base64 xlat. Also, the odds of every single char of the output digest being between 48-57 65-70 97-102, hmm (26/256)^64 = 2.697345e-64 i.e. very unlikely.
A kinda logical next step would be to allow salted SHA2-x. The multiplexing wouldn't work there though due to unpredictable salt length...
I'd actually rather add a generic Salt attribute, and get rid of all the salted variants of functions. I think it can be done in a way that's backwards compatible. It just doesn't make sense having two versions of the code doing pretty much the same thing. In that case we could just reuse the 'multiplexed' attribute, but strip off salt based on the header. Where the password is stored in a database without a header, a header could be added as a hint using unlang, or people can do the decode and splitting manually, or store the salt in another column. Else were going to have to add four more attributes just to represent the salted versions. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2