On Tue, Apr 02, 2002 at 04:43:43PM -0600, McNutt, Justin M. wrote: > Okay, so the way that Microsoft's RADIUS server gets away with this is due to the >fact that in a Microsoft domain, user names and passwords are not stored using strong >(one-way) encryption. You can decrypt the password file. >
No. Microsoft stores a cleartext equivalent of the password. > So when an EAP request comes in to an MS RADIUS server, MS decrypts your password, >then encrypts it again using EAP-MD5, which it can then check against the string that >came from the NAS. > > Right? No, it hashes the cleartext equivalant the same way the client does. It then compares the two hashes. > And the "real" alternative is to use EAP-TLS, correct? dunno /fc > -----Original Message----- > hello > > > > I don't understand where this restriction comes from. Once the FreeRADIUS server >gets the > > password from the NAS, what prevents it from checking that password against >/etc/shadow, > > PAM, another RADIUS server, or whatever? > > in fact, it's not a restriction of freeradius. it's a necessary > restriction of the CHAP (and EAP-MD5, which is basically the same). > > the problem is that the client doesn't send a password which the server > can check against whatever in whichever way. the client sends an > authentication string (i'm not going to be very precise, it's the > principal which we are talking about) produced by the user basically out > of user's identity, the challenge sent before by the server, etc. and of > course the password itself. what's good about this authentication string > is that you can't guess whatever information has been taken to create it > by just looking at the result (it's usually a cryptographic hash built > using MD5, so a one-way function with rare collisions). the second good > thing about it: it's very improbable, that you will be successful in > producing the same result just using some crap instead of values used by > the user. > > so, the only way to verify such an authentication string on the server > side is to re-compute it the same way the client did. the only > (theoretical) way to do so is to have the same input values and to > process them in the same order and in the same concatenation through the > same algorithm (MD5). then you compare the results. if they don't match > - the user loses. if they do, the server sends the accept message. > > so, the server needs the unencrypted password. > > > hope this helps. > > artur > > > -- > Artur Hecker Groupe Accès et Mobilité > [EMAIL PROTECTED] Département Informatique et Réseaux > +33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13 > http://www.infres.enst.fr ENST Paris > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
