Feature request - Add SHA3 and Bcrypt support

[lepianoman]

Issue type

• [x] Feature request.

It'd be great if freeradius included better ways to hash the user password. Unless I'm mistaken, I'm not seeing a way to use bcrypt or ssha512 or even ssha256. Considering rainbow attacks, even on SHA512, my (limited) understanding is that the current hashing options are pretty limited. SHA3 isn't listed, for instance.

I'm not too worried about what's going on within TTLS--even sending unencrypted passwords wouldn't be too bad in my view--but I think we all assume that all servers may be hacked.

[lepianoman]

By the way, what's the most secure way to store hashed passwords in the current scheme according to you--a salted SHA1? Or is an unsalted SHA512 better?

[arr2036]

It looks like the SHA3 implementation in OpenSSL was finished 8 days ago (https://github.com/openssl/openssl/issues/439), and isn't yet available in a public release. SHA2 is not even close to being broken. We'll add support for SHA3 and SSHA3 when there's a public release of OpenSSL which supports it.

Rainbow attacks only work if you don't use a salt or your salt is too small. I highly doubt anyone would succeed in cracking a SSHA512 hash. If you really care, salt your passwords.

SHA256, SHA512, SSHA256 and SSHA512 are all supported in 3.0.15 (they were added a few versions back). The LDAP password headers and attribute names are here: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/modules/rlm_pap/rlm_pap.c#L89

v4.0.x adds support for PBKDF2 which is essentially the same as bcrypt.

I'm not too worried about what's going on within TTLS--even sending unencrypted passwords wouldn't be too bad in my view--but I think we all assume that all servers may be hacked.

Ok, so you're not worried because it'd only compromise individual user accounts? Or you don't care because attacks would require the hacker to actually be in broadcast range of the supplicant?

Because I'd be worried... Internally we use EAP-TLS. Removing passwords entirely is definitely on the roadmap for us (not from FreeRADIUS server, but the organisations which support the project).

If you want to cargo cult security advice - get rid of passwords and use X509 certs instead. Supplicant behaviour is laughably poor on macOS/iOS and Windows. If you use EAP-TTLS, EAP-PEAP etc... anyone sufficiently motivated will be able to harvest your user's passwords.

[lepianoman]

Sorry, I was apparently reading outdated webpages about the kinds of encryption freeradius supports.

Thanks for the thoughts!

[arr2036]

Are the pages on freeradius.org or wiki.freeradius.org? If so, let me know and I'll get them updated.

[lepianoman]

To be fair, I ran man rlm_pap in freeradius -v 3.0.15, and certain rlm_pap pages don't have it, e.g. http://freeradius.org/radiusd/man/rlm_pap.html

[arr2036]

On 24 Aug 2017, at 13:36, lepianoman notifications@github.com wrote:

To be fair, I ran man rlm_pap in freeradius -v 3.0.15, and certain rlm_pap pages don't have it, e.g. http://freeradius.org/radiusd/man/rlm_pap.html

Um?

[lepianoman]

I'm also not sure I get how EAP-TLS could be implemented across a large userbase but that's another story.

[lepianoman]

^^Not sure where I got the idea that pap didn't support SSHA512--but it's not listed in that man page.

[lepianoman]

ps thanks for your patience with my n00bness--I'll try to do something helpful by the time I get this all going :)

[arr2036]

Yes it is, see the line {ssh512} SHA2-Password SHA2 hashed passwords.

[lepianoman]

Right, no salt though.

[lepianoman]

E.g. SSHA512 isn't listed

[arr2036]

Looks like there's a missing 'a' in the headers list, i'll go fix that.

As for provisioning EAP-TLS. The Hot Spot 2.0 standards specify all the infrastructure for this. The later versions of the standard allow for dynamic reprovisioning of certificates too.

One of the commercial projects I worked on a couple of years ago was to deploy EAP-TLS for 1M+ subscribers. These weren't University students, or some sort of captive user, this was for your average everyday cell phone subscriber.

[arr2036]

Sha3 support is now in v4.0.x as a xlat expansion, a pbkdf2 hashing scheme, a plain password hashing scheme, and a salted password hashing scheme.

If you really want bcrypt, feel free to submit patches. You could probably copy most of the PBKDF2 hashing stuff.

[lepianoman]

Thanks for that--that's exciting :) And I'm glad my bug reports are leading to some good and are not just based in my errors.

If I have some time before school starts I will absolutely try a pull a bcrypt request.

Ok but one other thing: another reason I thought freeradius didn't support SSHA512 is because the documentation for radcrypt (e.g. http://freeradius.org/radiusd/man/radcrypt.html or man radcrypt) makes it sound like radcrypt is also super outdated cryptographicaly speaking. Is your development goal to have radcrypt be bcrypt, SHA3, even SSHA512 compatible, etc.?

If not, may I humbly suggest including in the radcrypt documentation some suggestions on how best to arrive at a salted hashed SSHA512 password? e.g. openssl commands? I'm currently using doveadm.

[lepianoman]

And/Or even what you just told me about EAP-TLS being ideal, along with what you told me about pushing TLS certificates onto 1000 BYODs. (Current google searches don't make it sound easy.)

If you don't plan to keep radcrypt up-to-date, you may want to mark that in the documentation as well.

[lepianoman]

Also, speaking of documentation, when I browse to:

http://wiki.freeradius.org/project/List-of-modules

And click on rlm_pap to view the latest documentation, I get a page (http://wiki.freeradius.org/__omnigollum__/auth/failure?message=csrf_detected&strategy=github) that says:

Authentication failed

Provider did not validate your credentials (csrf_detected) - please retry or choose another login service

Try again

Hope these are helpful and you can let me know if I'm being a bother. (fortunately, I get the same error for most of the wiki, so you may not get too many more bug reports from me unless you fix that one ;) because it seems that even the man pages within freeradius 3.0.15 may be outdated (e.g. comparing man rlm_pap to http://networkradius.com/doc/3.0.10/raddb/mods-available/pap.html--the latter has SSHA512, the former does not, and cannot access wiki.freeradius)

[lepianoman]

A more serious bug report: Another reason I thought freeradius didn't support SSHA512 is because I can't get it to work.

For instance, I have user yo with password joe

doveadm pw -s SHA512.hex gives me 226c72af6fd3dc3ba3c50d56b43dc79cc93482c57a1359089cd6cbf5a3e5095d0bb435609df2290bf126295dab0d8e1fb45409a348bb223eab5f29622f012b95 In users: yo SHA2-Password := "226c72af6fd3dc3ba3c50d56b43dc79cc93482c57a1359089cd6cbf5a3e5095d0bb435609df2290bf126295dab0d8e1fb45409a348bb223eab5f29622f012b95" This command works: radtest -x yo joe localhost 0 testing123

But this fails:

doveadm pw -s SSHA512.hex 
112c0b49666b365bc204c48466f14319a071b945ca46b08a62cd65e379ca9b11df2b12af3e3c48c0f8b01846ea019b04e3fc7dd71e010db808a8f20d312e272a8a840771

If I try SSHA2-Password, I get /etc/freeradius/mods-config/files/authorize[16]: Parse error (check) for entry yo: Unknown name "SSHA2-Password"

[mcnewton]

There's a better list now on the new freeradius.org web site, so I've updated the wiki to point there, thanks.

It's not an error. That link on the wiki is to a page that does not exist, so it asks you to log in before you can create it.

There's a lot of documentation on the web site, wiki and server source (man pages etc), which is a lot of work to keep up to date. Patches and pull requests (most are on github) for any of them are welcome!

[lepianoman]

And by the way, the pap documentation says it accepts base64 hashes, but this is not my experience: doveadm pw -s SHA512.base64 {SHA512.BASE64}Imxyr2/T3DujxQ1WtD3HnMk0gsV6E1kInNbL9aPlCV0LtDVgnfIpC/EmKV2rDY4ftFQJo0i7Ij6rXyliLwErlQ== vim users yo1 SHA2-Password := "Imxyr2/T3DujxQ1WtD3HnMk0gsV6E1kInNbL9aPlCV0LtDVgnfIpC/EmKV2rDY4ftFQJo0i7Ij6rXyliLwErlQ==" Freeradius -X says: pap: ERROR: "known good" digest length (68) does not match output length of any SHA-2 digests

[lepianoman]

Thank you--I will be delighted to help update the man pages!

[lepianoman]

Also in users:

`yo1 SSHA-512-Password := "112c0b49666b365bc204c48466f14319a071b945ca46b08a62cd65e379ca9b11df2b12af3e3c48c0f8b01846ea019b04e3fc7dd71e010db808a8f20d312e272a8a840771" freeradius -X /etc/freeradius/mods-config/files/authorize[17]: Parse error (check) for entry yo1: Unknown name "SSHA-512-Password" Failed reading /etc/freeradius/mods-config/files/authorize /etc/freeradius/mods-enabled/files[9]: Instantiation failed for module "files"

`

[lepianoman]

Should I file a separate bug report? I kind of meant to complain in this OP that I couldn't get SSHA-512 to work. Will gladly update docs when I'm sure I understand what's supported and what's not. Thanks!

[mcnewton]

That should be SSHA2-512-Password, not SSHA-512-Password or SSHA2-Password. The rlm_pap module handles base64 coded passwords automatically. There's no need to tell it to do so.

The mailing list is a better place for discussion around this now.