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" <nat...@freezable.com> wrote: > I'll share my implementation once done. Thanks for the help. > > On Sep 29, 9:08 pm, mdipierro <mdipie...@cs.depaul.edu> 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" <nat...@freezable.com> 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 <mdipie...@cs.depaul.edu> 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 <mdipie...@cs.depaul.edu> 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" <nat...@freezable.com> 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 <mdipie...@cs.depaul.edu> 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" <nat...@freezable.com> 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 web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
