Upgraded FR to the 3.0.x release and the password shows that it is ssha512 but where in the code does the salt get pulled from? and where do I configure it? Sent from my Android device
On 22 Jan 2015, at 19:43, Robert Graham <robert_graham@uhaul.com> wrote:
Upgraded FR to the 3.0.x release and the password shows that it is ssha512 but where in the code does the salt get pulled from? and where do I configure it?
There is no separate salt attribute. update control { SSHA2-512-Password := "0x%{sql:query to get hash in hex concatenated with salt in hex}" } pap For salted hashes it's always <hash><salt>. The hash part is determined by the expected length of the hash. So for SHA512 the first 64 bytes of the hash/salt concatenation are assumed to be the hash, and the rest is assumed to be the salt. The code takes the salt part, creates the concatenation of <password><salt> and passes that to SHA512, the result of that is then compared to <hash>. If you can't figure out how to get the hash in hex form, the server will accept base64 as an alternative, but you should then do: update control { Password-With-Header := "{ssha512}%{sql:query to get hash concatenated with salt in base64}" } pap The PAP module will then use heuristics to determine the correct encoding (hex or base64 or none), and normalise the <hash><salt> to binary data. Note: You can't just concatenate two base64 strings. If they're stored that way in the db they would have to be separately decoded and the result concatenated. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
We were able to get the output of the salt in hex form, but getting it to concatenate is a whole other problem. When I do research on the web and tried all possible examples of the query, still would not give me the information that I need. If I have a column that has the hashed password and a column that has a salt that is in hexfomat... how would the update control { SSHA2-512-Password =: "0x%{sql:SELECT what is the proper context to concatenate the hashed pw in hex and the salt in hex Robert Graham FreeRadius users mailing list <freeradius-users@lists.freeradius.org> writes:
On 22 Jan 2015, at 19:43, Robert Graham <robert_graham@uhaul.com> wrote:
Upgraded FR to the 3.0.x release and the password shows that it is ssha512 but where in the code does the salt get pulled from? and where do I configure it?
There is no separate salt attribute.
update control { SSHA2-512-Password := "0x%{sql:query to get hash in hex concatenated with salt in hex}" } pap
For salted hashes it's always <hash><salt>. The hash part is determined by the expected length of the hash. So for SHA512 the first 64 bytes of the hash/salt concatenation are assumed to be the hash, and the rest is assumed to be the salt.
The code takes the salt part, creates the concatenation of <password><salt> and passes that to SHA512, the result of that is then compared to <hash>.
If you can't figure out how to get the hash in hex form, the server will accept base64 as an alternative, but you should then do:
update control { Password-With-Header := "{ssha512}%{sql:query to get hash concatenated with salt in base64}" } pap
The PAP module will then use heuristics to determine the correct encoding (hex or base64 or none), and normalise the <hash><salt> to binary data.
Note: You can't just concatenate two base64 strings. If they're stored that way in the db they would have to be separately decoded and the result concatenated.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 28 Jan 2015, at 08:06, Robert Graham <robert_graham@uhaul.com> wrote:
We were able to get the output of the salt in hex form, but getting it to concatenate is a whole other problem. When I do research on the web and tried all possible examples of the query, still would not give me the information that I need.
If I have a column that has the hashed password and a column that has a salt that is in hexfomat... how would the
update control { SSHA2-512-Password =: "0x%{sql:SELECT what is the proper context to concatenate the hashed pw in hex and the salt in hex
If it's easier you can do it in two queries, but it's less efficient. i.e. 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}" } -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Thanks for all your help Arran,this should do it now. Ill let you know what the results are when I run some tests. Have you or anyone on your team ran these tests with the sample data we provided? Sent from my Android device
On Jan 28, 2015, at 9:38 AM, Robert Graham <robert_graham@uhaul.com> wrote:
Thanks for all your help Arran,this should do it now. Ill let you know what the results are when I run some tests. Have you or anyone on your team ran these tests with the sample data we provided?
Yes. They’re part of the automatic test suite, which is run on every commit. See src/tests/keywords/pap-ssha2 Alan DeKok.
On 28 Jan 2015, at 22:38, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 28, 2015, at 9:38 AM, Robert Graham <robert_graham@uhaul.com> wrote:
Thanks for all your help Arran,this should do it now. Ill let you know what the results are when I run some tests. Have you or anyone on your team ran these tests with the sample data we provided?
Yes. They’re part of the automatic test suite, which is run on every commit.
See src/tests/keywords/pap-ssha2
No. They're not. I wrote a different set of tests using the sha512 xlat which I'd tested previously against other sources and knew was correct. It turns out the hashes OP provided are wrong. Or at least compared to openssl's SSHA512 function they're different. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 28 Jan 2015, at 21:38, Robert Graham <robert_graham@uhaul.com> wrote:
Thanks for all your help Arran,this should do it now. Ill let you know what the results are when I run some tests. Have you or anyone on your team ran these tests with the sample data we provided?
I just did, and I can't reproduce your hashed values. The strings you gave will be the same in UTF8 or latin1. To confirm it wasn't the code in FreeRADIUS, I ran the test strings though openssl sha512. The resulting hashes were the same as FreeRADIUS. Your test strings: Hellohello 18888702 arr2036@power:~$ echo -n "Hellohello18888702" | openssl sha512 (stdin)= 6298c5de72a33bf3653462a338fa4ae26c4570b06a196b15c9cecda4f6daca53e4061ec19d0038815b9e8e0b66fed2f382736331d6a74c44691ed7557b1267c1 arr2036@power:~$ echo -n "18888702Hellohello1" | openssl sha512 (stdin)= 764b34078e93c7ff1a4c1e221b854b1e307e540ecde3614d0653b0b8dc050b838d409458f9523712eef204bf8e152d2786e798514f8d7fbee967c2e3202793ee Neither match the expected output: 20d6ab7a8b3e40f62d8dc1022d0b0fde4388fea53c3ecd63395ba382b2596ffcd15711eebcc3ccc5620a1b1bcfb4b89914609985994b1e3cb30c568d5fcd0311 and FreeRADIUS agrees with OpenSSL on the correct values. I also noticed you said your code did: Hash( salt + password ); For every other salted hash in FreeRADIUS the salt is appended, not prepended. Same with Dovecot's SSHA2 hashing schemes (see bottom section on salting): http://wiki.dovecot.org/Authentication/PasswordSchemes ----- public static byte[] Hash(string salt, string password) { byte[] passwordBytes = Encoding.Unicode.GetBytes(password); byte[] saltedPasswordBytes; if (string.IsNullOrEmpty(salt)) { saltedPasswordBytes = new byte[passwordBytes.Length]; } else { byte[] saltBytes = Encoding.Unicode.GetBytes(salt); saltedPasswordBytes = new byte[passwordBytes.Length + saltBytes.Length]; Array.Copy(saltBytes, 0, saltedPasswordBytes, passwordBytes.Length, saltBytes.Length); } Array.Copy(passwordBytes, saltedPasswordBytes, passwordBytes.Length); using (var hashProvider = new SHA512Managed()) { return hashProvider.ComputeHash(saltedPasswordBytes); } } The good news is that you were wrong (assuming that code is C#). If you look it copies the salted bytes into the saltedPasswordByes at destination index passwordBytes.length i.e. at an offset of passwordBytes. It then fills in from the start of the array (index 0) up to the length of passwordBytes. Prototype for the first copy call is: public static void Copy( Array sourceArray, int sourceIndex, Array destinationArray, int destinationIndex, int length ) and the second: public static void Copy( Array sourceArray, Array destinationArray, int length ) So you should end up with Hash( password + salt ); You have the correct hash value for your test strings above. It's up to you guys to figure out why they don't match. Not much more we can do from here. Though first off, i'd check the lengths are what you'd expect, make sure no trailing junk (like newlines) has accidentally been appended to the strings. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Robert Graham