On Fri, Nov 26, 2004 at 02:01:00PM +0800, Chan Min Wai wrote:
> Alan DeKok wrote:
> > "Chan Min Wai (System Administrator)" <[EMAIL PROTECTED]> wrote:
> >>>CLEAR text passwords are required for EAP-MD5. Crypt passwords will
> >>>NEVER work.
> >>Anyway to make it work? somehow?
> > No. It's impossible.
> I know this have been bugging you From Or since freeradius support LDAP
> And I do saw a lot of people are looking for such sultion.
> May I know in more technical term why it is not possible?
> I know there is no way to get the plain text password back from {crypt}
> but I just wonder what is the password send from the EAPOL (Wire MD5).
> Is there anyway to make such that this password is hashed in the same
> way and product a same password as {cyprt} in the LDAP and we go to
> compare that?
If that worked, it would be effectively the same as using plain text
passwords _everywhere_ since someone could just capture the cypted
password in the login request, and use _that_ to login.
Basically, the user and the server must share a secret. Either that
secret is sent from the client to the server (PAP), or some extra piece
of information is send, modified by a process identical on both ends
that uses the secret as input, and the resulting output is sent to the
server for comparing. (Everything but PAP)
*note: the below is as I understand CHAP. I'm sure there are other
tricky things EAP does, but I think my point is still clear*
If that third piece of information is constant, someone could simply
intercept the output of the process and send it everytime they were
asked, making it as good as having the password.
Since this extra piece of information must change, either the server
must store the input to the process (the plain-text password) or the
output of the process for each possible input. (That is, if the function
is f(password,extra) it must store either password or f(password,extra)
for every value of extra.
If extra ranged from one to ten, for example, you'd have ten items to
store in your database, and an attacker would have to watch ten logins
to have the right answer for each possible extra. _Or_ they can watch
one login, and be successful on one try in ten.
If your extra ranged from one to 100, you would need to store 100
versions of the output, and an attacker could get in one time in 100.
That's the easy part.
However, usually 'extra' includes something time-dependant. Time only
moves forward (barring daylights savings ending ^_^) so "extra" now has
a possible value limited only by your imagination. If extra was the
seconds since 2001-01-01 00:00 UTC, and you used, say, a 32-bit value,
(so your authentication system would work only until early February
2137) then you would need to store 4 294 967 296 passwords in your
database for each user, less the number of seconds that have already
passed since 2001-01-01 00:00 UTC. In this case, the attacker wouldn't
be able to use any old hashes captured from the wire, as the clock
would never repeat over that period.
If you wanted to skimp, you could only store enough passwords to last
until the user's account expired (say, one month's worth, 2 629 800 or
so) as long as every time they renew, you create another 2 629 800
password entries to last the next month. And remember, you need their
plain-text password to regenerate the password list.
And _then_, an attacker who sent their request in the same second as
the user would still be able to use the reply to break in, unless you
add more to the 'extra' value... Say, a number from one to 1000. Then
you store a thousand passwords for every second second, or roughly
two thousand million passwords per user-month.
Frankly, that won't be _useful_ until we have quantum computing or
similar, at which point the attacker can probably break your passwords
anyway by sending four thousand million simultaneous authentication
requests.
So in short, yes, it's possible. But I don't plan to implement any
such system, and no one else has shown much interest.
Patches welcome, as always. ^_^
--
Paul "TBBle" Hampson, on an alternate email client.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
