On 14/07/17 10:43, Federico Capoano wrote: > > > On Thu, Jul 13, 2017 at 11:00 PM Leonardo Maccari > <[email protected] <mailto:[email protected]>> wrote: > > >> >> Yes you have understood correctly, we are talking about the >> password hashing algorithms supported by Freeradius. >> >> >> basically, if you want to use any of these authentication >> protocols, you have to use these hashes because the password >> comes already hashed from the supplicant. If you want to use >> another hash you have to configure FR to pass along the >> password in clear, and then do your own hashing. You can do >> this using the PAP protocol, which sends the password in >> clear (!!) and then you can hash it at the destination. To >> make this reasonably secure you have to embed it into a TTLS >> tunnel. This may be even supported by other applications so >> you can re-use the db for other uses. >> >> >> We don't want to use one of those hashing algorithms for the >> reasons stated in the first email. The password can then be sent >> to freeradius in cleartext using a TTLS tunnel. In some cases, >> the NAS (network access server) sits on the same host of >> freeradius or in a trusted LAN (eg: the LAN of a virtualized >> physical server) and a TTLS tunnel is not needed. > > maybe I was not clear enough, need a picture to explain: > > SU --- AU -------------- Radius ---- DB > > this is the typical authentiation set-up, with a supplicant, an > authenticator, a radius and a user db. I think in your case SU and > AU are co-located in the web server. > > With protocols like MSCHAPv2 this happens: > > > SU --- AU -------------- Radius ---- DB > hash(pwd)------------------------------> > > so basically Radius knows nothing about hashes, and you have to > cope with crappy hashes (which, BTW, is what everybody uses, > because you still pass through a TLS tunnel, so it is not that > horrible, and collisions are still hard enough not to be practical). > > With PAP this happens: > > SU --- AU -------------- Radius ---- DB > pwd---------------------------------->hash(pwd) > > So the pwd passes in the clear up to the DB. There you can hash it > with whatever you want, including a salted SHA256. But, since > everything passes in clear, you have to be extremely sure that you > have no leaks anywhere (and that authentication is bi-directional > in some way, but this may not be your case). I am pretty sure > there is a working ldap configuration for this, even if i never > tried it myself. > > > Yes this is the solutions we are talking about, using PAP (encrypted > with TTLS or not depending on where the communication between radius > clients and radius). > > Each method has trade offs. The method we have discussed is easy > enough to implement, secure, flexible, has low mantainance costs. > > As said, storing passwords in SHA1 or MD5 is not viable unless we only > store passwords in that form only for users of a freeradius > instance/federation, but we would need to store these passwords in a > different location than the main user passwords (eg: administrators, > operators, future contributors when we will introduce the possibility > of contributing to the network by adding nodes into the system), this > means we should keep the SHA1/MD5 encrypted passwords for freeradius > users either in separate fields or a different DB entirely: this > solution would be cumbersome, bug prone and costly to mantain.
Ok I understand you don't want to have MD5/SHA1, but with the PAP solution, you don't have to. Unless you are telling me that the documentation or rlm_pap is wrong: https://freeradius.org/radiusd/man/rlm_pap.txt which is entirely plausible. Even if I am thinking that i miss some pieces because i don't understand why you want to replicate the user DB, once you have a RADIUS server. > before i answer, maybe i miss the big picture. generally you want > to interface to RADIUS because you have some external DB of > passwords that are already in use, and you want to plug your > application into it. But maybe you are interested in the other way > around, you want to embed an user DB and a FreeRadius server into > the host where openwisp is running, so you can offer to > third-party applications all-in-one with OpenWISP and a RADIUS > interface? > > > Sorry, I'm not following you. let's try again: what is the architecture you have in mind? given the following scheme: SU --- AU -------------- Radius ---- DB what are the components you control and what are the external components you only plan to connect to? l. > > Federico > -- > You received this message because you are subscribed to the Google > Groups "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- Leonardo Maccari, Assistant Professor @DISI, University of Trento Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7 -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
