I agree we shoud have this as an option.All we need is to add an option to session.connect(...) Users can decide.
On 1 Ago, 03:07, Thadeus Burgess <[email protected]> wrote: > IP addresses can be faked... well anything sent to the server can be > spoofed. It is much easier to hijack a session token and steal the > users login than it is to crack a signed cookie. > > I agree we need both methods in web2py, with the ability to specify > which method we want. > > -- > Thadeus > > > > On Sat, Jul 31, 2010 at 7:57 PM, Scott <[email protected]> wrote: > > True, the PCI-DSS mandates things like that, such as tokenizing credit > > cards and only passing the tokens, using a centralized secure database > > to store the data, etc. WRT the site cookie, you'd have access to > > what that user has been authorized to see, sure. There are other > > standard-practice methods like associating the IP address to the > > session (again, built into web2py)... I just happen to be paranoid > > about these types of things and would rather give out as little > > information as humanly possible to the client. That is to say, only > > the session token. Call it the Principle of Least Information =) WRT > > this not being an issue on today's hardware, sure I agree. I have a > > tendency to look for what not only works today but works for the > > future to prevent having to redesign the system a few years down the > > road. I'd rather do the hard work now to pay dividends down the > > road. > > > So how about a compromise - let's switch to using secure, HTTPOnly, > > signed and encrypted cookies which store the session token and give > > the programmer the option to store some data in the cookie if > > required. Just put a caveat that the least amount should be stored > > (and in any case, less than the 4k limit). > > > On Jul 31, 8:38 pm, Thadeus Burgess <[email protected]> wrote: > >> @Scott, I think your argument is based on assuming a bad programming > >> design. If you have any type of data that needs to be secure to that > >> detail, I hope to god your not storing them in the session in the > >> first place! I mean, if I somehow copy your sites cookie from a user, > >> I now have access to the entire site anyways. > > >> You should only be storing data in a session that won't compromise > >> your data in the first place. Userid doesn't mean anything even if the > >> cookie was cracked (though on todays hardware would take 900 trillion > >> years to crack a good hmac key). If your storing an encrypted tree of > >> credit cards in the session, don't you think it would be appropriate > >> to redesign your application and store that in the database instead? > > >> Not to mention, google, facebook, twitter, microsoft, quicken, chase, > >> capitalone, visa, etc. etc.. all use signed cookies... They are the > >> "most correct" way to do it on todays hardware, and todays software, > >> and todays browsers. Perhaps when we have flying cars it won't be the > >> best way anymore, but until then =) > > >> -- > >> Thadeus > > >> On Sat, Jul 31, 2010 at 7:28 PM, Jonathan Lundell <[email protected]> > >> wrote: > >> > On Jul 31, 2010, at 5:09 PM, Scott wrote: > > >> >> In essence your argument is that it would take too much time and you > >> >> could change the hmac key monthly to prevent an attack. I understand > >> >> and respect that signed cookies are one way to solve the problem, but > >> >> I do not believe they are the "most correct" way. > > >> >> My analogy would be the difference between a handheld portable safe > >> >> (signed cookie) and a bank (server-side session). If your money is > >> >> stored in the bank, it's a lot harder to steal it because a thief > >> >> would need to break into the bank whereas a thief has all the time in > >> >> the world with a portable safe (which are also a lot easier to > >> >> break). With computer processing speed and algorithms (particularly > >> >> distributed computing) I am not sure that signed cookies will remain > >> >> as "safe" as they are today. With regard to changing the hmac key, > >> >> you are right they should be periodically changed although this would > >> >> need to be carefully planned as it essentially invalidates sessions > >> >> when it changes. I believe it would also would invalidate stored > >> >> encrypted data unless you use a one-time method to decrypt then re- > >> >> encrypt the data using the new hmac key. > > >> >> In summary, I believe server-side sessions to be more secure than > >> >> client-side cookies, period. > > >> > As a practical matter, I don't think it's much of an issue. A SHA-1 > >> > based HMAC, or SHA-2 if you're feeling especially paranoid, is not going > >> > to be cracked within the lifetime of a session. Notice that unlike > >> > encryption of sensitive data, cracking the session HMAC has no value > >> > once the session has expired. So the ability to attack it for months > >> > offline isn't of much use. > > >> > The expiration problem could be handled by having two keys active at any > >> > given time, with their valid-time overlapped, so you have an 'old' key > >> > and a 'new' key. If someone comes in with an old key, replace the HMAC > >> > with a new version.
