Thanks for the feedback. I guess it is a mitigated risk considering that you would need to already have access to the database. I would think that, at that point, the game was over anyway. Also, I have decided that javascript is a minimum requirement. Is there a better place you can think of to store the token?
At any rate, it's better than sending plain passwords like reddit.com ;) On Oct 4, 2:03 pm, Thadeus Burgess <[email protected]> wrote: > Well, as oliver pointed out earlier, if I had access to your password field > in the database, then all I would need to do > > Is that that hash, go to the login page, take the token from the form, hash > manually, and then manually submit the POST > > Then I would be logged in as that person. The only thing is, I would still > need access to your database. So as long as thats secure, I think this is > the safest way against external snoofing! :) > > Also, what about a fallback, for if they don't have javascript enabled? You > should still allow them to perform an unsecure login. > > -Thadeus > > On Sun, Oct 4, 2009 at 12:21 PM, mr.freeze <[email protected]> wrote: > > > Success! I ended up going a slightly different route using only the > > jQuery sha256 plugin (considered GnuPG but I didn't want passwords to > > be decryptable by even me): > > > 1) When a person registers, an sha256 hash is made of the username > > +password on the client and sent to the server. > > 2) When the login page is requested, a token is generated and stored > > in the session > > 3) To authenticate, the jQuery sha256 plugin combines the username and > > password, hashes them then hashes again using the token as the hmac > > key. > > 4) Once login is attempted, the token is destroyed and a new one is > > created. > > 5) On the server, a custom auth login method takes the password from > > the database and hashes it using the token. > > 6) It is compared to the hash from the client to determine success. > > > Login, register, retrieve_password, and change_password all use this > > and it seems to work well. I am building a re-usable class for my > > Client Tools module if anyone is interested. The one drawback is that > > users will need to reset their password. > > > Even if the username+password hash is captured during registration or > > password change, you still wouldn't be able to login without the > > token. Please let me know if you see any holes in this process. > > > Thanks, > > Nathan > > > On Sep 29, 9:51 pm, "mr.freeze" <[email protected]> wrote: > > > I'll share my implementation once done. Thanks for the help. > > > > On Sep 29, 9:08 pm, mdipierro <[email protected]> wrote: > > > > > You are right and I like this. You are assuming the server does not > > > > store the password already hashed. I was not assuming that. > > > > > On Sep 29, 8:10 pm, "mr.freeze" <[email protected]> wrote: > > > > > > Perhaps I misunderstand. Here is my plan: When the login page is > > > > > requested, the server will generate a random token, store it > > somewhere > > > > > (session most likely) and send it to the client. The user then > > enters > > > > > their password which is hashed using the jQuery plugin. The hashed > > > > > password is concatenated with the token then hashed again. The > > result > > > > > is transmitted to the server. To authenticate, the server pulls the > > > > > password hash from the database, the hashed token from wherever it > > was > > > > > stored (probably the session), concatenates them and generates a hash > > > > > which is compared to the hash from the client. Neither the password > > > > > nor the password hash are ever transmitted. > > > > > > Does that seem secure? The only weak spots are registration and > > > > > password changes I think. > > > > > > On Sep 29, 7:43 pm, mdipierro <[email protected]> wrote: > > > > > > > Basic concepts in digital identity are message integrity, non- > > > > > > repudiation, and confidentiality. > > > > > > > The point using SSH/HTTPS is that it performs a key exchange using > > > > > > public key encryption and that critical to confidentiality (the > > > > > > password and information cannot be stolen in transit). Public key > > > > > > allows the two parties to agree on one encryption key without ever > > > > > > transferring that key. After this initial exchange all > > communications > > > > > > are encrypted, including the transmission of the password. > > > > > > > Hashing (MD5, SHA, HMAC, etc) is a critical ingredient of integrity > > > > > > (together with encryption, it allow you to detect, if data has been > > > > > > tampered with). Hashing does nothing to protect your password in > > > > > > transit. You may as well send it in the clear. > > > > > > > That jQuery plugin does not help at all the problem of transmitting > > > > > > the password. > > > > > > > There are places where you get a free ssl certificate. > > > > > > > Massimo > > > > > > > > I'm going to try this:http://plugins.jquery.com/project/sha256 > > > > > > > > On Sep 29, 6:18 pm, mdipierro <[email protected]> wrote: > > > > > > > > > If not running over http session.secure() will prevent sessions > > from > > > > > > > > working and login will not work. > > > > > > > > > hashing with a salt can easily be attacked. > > > > > > > > > Massimo > > > > > > > > > On Sep 29, 6:11 pm, "mr.freeze" <[email protected]> wrote: > > > > > > > > > > Reddit seems to send a clear text password but Digg and a few > > others > > > > > > > > > seem to be hashing on the client using a token salt before > > sending. > > > > > > > > > I'm too cheap to pay for a unique IP and SSL so I will try > > that > > > > > > > > > first. > > > > > > > > > > Question: Does session.secure do anything useful when *not* > > running > > > > > > > > > over https? > > > > > > > > > > On Sep 29, 4:50 pm, mdipierro <[email protected]> > > wrote: > > > > > > > > > > > I did not notice and that is bad. > > > > > > > > > > > If your app uses authentication you should have > > > > > > > > > > > session.secure() > > > > > > > > > > > and use HTTPS. The latter line will not accept sessions > > cookies > > > > > > > > > > without HTTPS. > > > > > > > > > > > Massimo > > > > > > > > > > > On Sep 29, 4:28 pm, "mr.freeze" <[email protected]> > > wrote: > > > > > > > > > > > > What are sites like reddit.com doing to secure their > > logins? > > > > > > > > > > > Anything? The login request goes over http according to > > firebug. I'm > > > > > > > > > > > just wondering if my wiki site needs https for login or > > http is > > > > > > > > > > > acceptable or if there is another trick I can use. > > > > > > > > > > > > Thanks! > > > > > > > > > > > Nathan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" 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/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
