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