Hello, Paul! On Sunday, May 3 2009 15:21:30 you wrote: > Hi, > > 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? > > No... hashes are one-way, so doing all that does not get you the user's > identity. It's true someone could conduct a brute force attack to try to > recover the password, given this data, but that's a lot different to them > just seeing the plaintext password. > > Challenge-response login is widely used in potocols; it is a sound > approch.
I agree that it's better than the plaintext password, but my point was: how reliable is it? Ignoring brute force attacks (which affect hashing, encryption, or no obfuscation at all), my concern was rainbow tables*. I want to attack you and I know your hashing algorithm, your salt(s) and some sample hashes, because I log your requests/responses... So I can theoretically create a rainbow table for your site. (I say "theoretically" because it depends on the resources I have for this; e.g., a powerful computer). In your particular implementation there's something crucial, which theoretically makes things harder: The timestamp. Assuming the web application checks that the timestamp is less than X minutes, it'd make things much harder because it'd be another variable to take into account; if not and the attacker finds it out, it'd be just a constant -- hence I say "theoretically" here. (Although the attacker could take it as a constant which represents a time in, say, 6 months, if he thinks he'll get a useful rainbow table by then.) But given the approach in question, this verification is up to the back-end developer, not something built-in in your package -- and it can't be because it's just a JS library. On the contrary, using encryption, you could deliver a ready-to-use, hardened-by-default solution, made up of a JS library that encrypts using well-known algorithms (in the back-end, the developer could use existing libraries available for the programming language he uses and no additional verifications would be required)... So that the back-end developer could use the original password for anything he has to or just hash it before storing it in the db. * Well, depending on how you see them, rainbow tables could be a sort of brute force attacks, just that you don't interact with the system under attack. > > Maybe I got it all wrong and this is not the exact way it works (after > > all, I > > I think you understood how it works fine, it's just your cryptanalysis is > wrong. > > > I'd trust a library like this if and only if it does use encryption, not > > ... > > on the fly by an attacker. But still it'd be much, much more secure than > > > hashing. > > What specifically would be more secure about it? An an attacker could certainly create a sort of rainbow table for the passwords _encrypted_ with a given algorithm, but: 1.- It's much, much, much harder. It's nearly impossible for the attacker to be successful if you use a 4096-bit RSA key, for example. 2.- Because you're encrypting (not hashing), you have something up your sleeve: You could encrypt the password _along_ _with_ a random "salt" generated in the client side, which is inserted in a random location. And because you're encrypting, not hashing, in the server you'll be able to get the original password (decrypted and without the JS-generated salt)... And once you have the original password, you can store its hash in the database, as always. This makes things even harder. It's also more convenient. What if you do need the original password in the backend? What if your service is just a proxy for a third party service and thus you do need the original password? For example, if you offer a Web interface to access IRC servers, you'd need the user's password to connect to the IRC server -- Hashing just won't work. > 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. > > Did you read the advanced section? It has some ideas you may be interested > in. Will do, thanks :) Cheers! - Gustavo. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
