How about an expiring (30 days from last use) unique session key stored in a cookie and in the database (the cookie must be sent in both directions over an HTTPS connection to prevent sniffing and hijacking the session) ... if both match and it's not expired, you're in. If it's not HTTPS, it's assumed to be an attack or at least something fishy, and that key gets deleted as a precaution, and the user has to type in the password. Of course when proxying it's hard to tell if you're https, no?
On 10/30/06, Kevin Horn <[EMAIL PROTECTED]> wrote: > > > On 10/28/06, Nadav Samet <[EMAIL PROTECTED]> wrote: > > > > Can anyone advice if this is a security risk to accept both encrypted > password and the plain-text one? > > I would advise against it... > > If the provider accepts an encrypted password, it's pretty much the same as > sending a plain-text password. Why bother encrypting the password, if it > gets sent over the wire and stored in the database in a form that someone > can just grab and use? > > This is why "Remember Me" links are evil...of course that doesn't stop > clietns from requesting them. > > <sigh> > > You might try storing some other information in the cookie, like maybe > encrypting the encrypted password, or something...but tehre's really not a > good way to do this securely AFAIK. If you have "Remember Me" > functionality, security pretty much goes out the window. > > Kevin H. > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
