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 -~----------~----~----~----~------~----~------~--~---
