On Feb 7, 2017, at 9:37 AM, David Teston <dteston@georgialibraries.org> wrote:
My company runs an application that hashes/encrypts user passwords in a central postgres DB. I have a bash script that can be run remotely to check a username and password against it: ./script.sh <user> <plaintext_pass>
Why not just use FreeRADIUS to query the DB? FreeRADIUS has a postgres plugging, and the queries are customizable.
The end goal is to store the username and encrypted password on the local FR postgres DB, but always/only check the password against the central DB.
I have no idea what that means. You're doing to store the password in a local DB, but then never use it... and instead use a second DB? That's inefficient, to be polite.
This will account for any password/permissions changes that occur on the application DB.
Why not use database replication? Replicate the main DB to a local one for FreeRADIUS, and then have FreeRADIUS query the local one.
My fear is that I will not be able to use EAP or CHAP (and their various sub-types) because of client-side password hashing. It seems that PAP will be the only usable solution because it would still provide the server with a plaintext password to be passed into the script. But I run into security issues with PAP.
Security is a trade-off. You can't be perfectly secure all of the time. a) use secure EAP methods where the password doesn't go in cleartext, BUT put cleartext passwords into the DB b) use less secure EAP methods where the passwords go in cleartext, AND put hashed passwords in the DB. Pick one.
Does anyone know of a proper method that would allow me to check all user credentials against the external DB while still remaining secure throughout the entire process?
http://deployingradius.com/documents/protocols/compatibility.html There is no magic here. There is no solution which lets you do everything you want. My $0.02 is to use EAP-TTLS + PAP in the inner tunnel. If you trust TLS (and you should) then using PAP is fine. If you don't trust TLS, well, don't go to Facebook, Google, Amazon, or pretty much any modern site on the net. Alan DeKok.