Hello, Paul, and thanks for letting us know about it. On Sunday, May 3 2009 05:51:07 Paul Johnston wrote: > So, this is a call to the authors of all web authentication libraries. > Add JavaScript MD5 as an authentication mechanism. And then let me > know, so I can link to you from my site. If you need any help > implementing it, drop me a line, I'll do what I can.
I love the idea of encrypting passwords in client-side, but I have some concerns about this particular implementation after taking a quick look into its docs: 1.- This library doesn't encrypt passwords; it replaces the password with its MD5 hash (and MD5 is a weak hashing algorithm). 2.- The hashing salt is sent to the client. 3.- The hashing algorithm is available in client side. This is, if I'm an attacker, all I need to know to steal a user's identity is to get the server challenge (for the login/registration form) and the client response for such a challenge (the submitted data, including the password). Am I right? Of course, this can be hardened in the server-side to make it more reliable. For example, by assigning a random token to each challenge which will identify the salt and timestamp, instead of sending such values over to the client. But still it wouldn't be very strong, from my point of view. Maybe I got it all wrong and this is not the exact way it works (after all, I just read its docs quickly), but my point is that I can't trust a password _hashed_ in the client side because there will always be a change to cheat on me. And leaving additional verifications up to the back-end developers just makes things less reliable. I'd trust a library like this if and only if it does use encryption, not hashing; specifically, a symmetric-key encryption algorithm, where the JS in the client side _encrypts_ the password using a shared secret/key and then the back-end _decrypts_ the received password using its private key... Finally, upon successful decryption, such a decrypted password will be _hashed_ and stored in the database/file/etc. But there will still exist a risk with an infrastructure like this: That because the shared key/secret is transmitted unencrypted, it could be modified on the fly by an attacker. But still it'd be much, much more secure than hashing. After all, it's not possible to get something as reliable as SSL. I know this may sound discouraging, but it's a suggestion to improve the solution you aim to provide, because I'd love to see a solution to this issue. ;-) > I think supporting this mode would be a big selling point for any > authentication library. And if support becomes widespread, the > internet becomes a little bit safer for everyone. I agree. Indeed it'd be better than transmitting passwords in the clear. If somebody wants to implement the back-end piece for this library, it should be really easy to write such a plugin for repoze.who -- pretty easy, I think. Cheers! -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
