Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request - Add SHA3 and Bcrypt support #2045

Closed
lepianoman opened this issue Aug 24, 2017 · 24 comments

Comments

Projects
None yet
3 participants
@lepianoman
Copy link
Contributor

commented Aug 24, 2017

Issue type

  • 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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

It looks like the SHA3 implementation in OpenSSL was finished 8 days ago (openssl/openssl#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.

@arr2036 arr2036 closed this Aug 24, 2017

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

Thanks for the thoughts!

@arr2036

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

@arr2036

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

Right, no salt though.

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

E.g. SSHA512 isn't listed

@arr2036

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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 added a commit that referenced this issue Aug 24, 2017

arr2036 added a commit that referenced this issue Aug 24, 2017

@arr2036

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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.

@arr2036 arr2036 changed the title Better password encryption? Feature request - Add SHA3 and Bcrypt support Aug 24, 2017

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

@lepianoman

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 24, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.