Re: Auth feature

<mbretter@jawa.at> wrote : > Hi, > > Alan Knowles schrieb: >> The algorithm sound good -except I would assume the md5 would be of >> username:{encrypted password}:challenge >> >> as most normal password storage mechanisms store passwords encrypted by >> default. - so you would not be able to get the cleartext password.. >> > I think both should possible, md5(id + challenge + md5(pass)) wich isn't > RFC conform and md5(ip + challenge + pass). I guess you meant id, not ip. > I strongly recommend implementing also RFC 1994 conform CHAP, because > otherwise the RADIUS Auth Container doesen't work. IIRC, if someone gets the md5 encrypted password + the challenge and turns off javascript, he can login the same as if he had the non encrypted password. So, sniffing packets would be enough to get the login credentials.. It might even be easier than without md5 because the password will always be 32 chars long. Additionally, some users might not have enabled javascript which will lead to confusion when trying to compare the credentials against the auth container. Having only encrypted passwords in the container is nice but as md5 cannot be decrypted, if a user forgets its password, you will have to send him a new one (probably by unsecure mail). I have used this solution for some time and I don't think it's worth it. The only secure solution is SSL. And maybe enforce users to choose secure passwords. I would see an interest though for an intermediate solution with encrypted password that could be decrypted (not md5). Just my 2 cents, Bertrand Mansion Mamasam