On 29/01/2007, at 10:07 PM, Alan DeKok wrote:
James Lever wrote:
I'm stuck trying to work out how to avoid sending the password
unhashed
to the server
Why?
Two reasons - first I am trying to limit risk of client
misconfiguration - if a client has misconfigured their supplicant, to
avoid passwords inadvertently going through in the clear and secondly
to limit the risk of account compromise through abuse of privileges
on the radius server. Yes, I realise that this is a small risk, but
I'm just trying to see how far I can go in terms of securing the user
credentials.
See my web page for compatibility issues: http://
deployingradius.com/documents/protocols/compatibility.html
Thanks for the pointer. This helps clarify the requirements of the
different authentication mechanisms.
Your desires are contradictory. If the password is hashed in EAP-
TTLS, then the server needs the cleartext password in order to
authenticate the user.
I don't understand why giving the server access to the cleartext
passwords is such a terrible thing to do.
What are the risks of client misconfiguration such that it will
actually get to the point of attempting to transmit the password in
the clear?
cheers,
James
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
