(apologies if this goes through multiple times, it''s been almost 24 hrs and I haven''t seen my original post) First of all, I love the new cookie-based sessions. Thanks bitsweat. I just have an architectural question / suggestion. The CookieStore takes great care to provide integrity of session data, but we seem to have lost confidentiality in the process. The server-side storage methods had the implicit advantage of keeping the session data secret, but I don''t know if this was intentional or just an unintended consequence. Would anyone see a disadvantage to symmetrically encrypting the cookie data rather than signing it with an HMAC? As far as I can think, this would retain all of the benefits of the current arrangement while obscuring the session data from a potentially untrusted client. (Not that untrusted-client is the normal way of things, but I tend to think fail-secure.) I don''t think we need the full authenticity that an HMAC provides, since we''re not trying to prove session authenticity to anyone other than the server that generated the session. Thanks! --be --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
You''d still need to do the HMAC also, otherwise they could modify the session. Even if they''re modifying in the dark, they could cause funny things to happen (eg imagine storing an id of a model which will be deleted...) - witness what happened to WEP when they forgot this. I agree with you that this should be an option. But I think that even symmetric encryption is much slower than a simple HMAC - so there would be a performance hit. Brad Ediger wrote:> (apologies if this goes through multiple times, it''s been almost 24 > hrs and I haven''t seen my original post) > > First of all, I love the new cookie-based sessions. Thanks bitsweat. > I just have an architectural question / suggestion. > > The CookieStore takes great care to provide integrity of session > data, but we seem to have lost confidentiality in the process. The > server-side storage methods had the implicit advantage of keeping the > session data secret, but I don''t know if this was intentional or just > an unintended consequence. > > Would anyone see a disadvantage to symmetrically encrypting the > cookie data rather than signing it with an HMAC? > > As far as I can think, this would retain all of the benefits of the > current arrangement while obscuring the session data from a > potentially untrusted client. (Not that untrusted-client is the > normal way of things, but I tend to think fail-secure.) I don''t think > we need the full authenticity that an HMAC provides, since we''re not > trying to prove session authenticity to anyone other than the server > that generated the session. > > Thanks! > --be > --Apple-Mail-37-430566699 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > X-Google-AttachSize: 7340 > > <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; > -khtml-line-break: after-white-space; "><DIV>(apologies if this goes > through multiple times, it''s been almost 24 hrs and I haven''t seen my > original post)</DIV><DIV><BR > class=3D"khtml-block-placeholder"></DIV><DIV><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; ">First of all, I > love the new cookie-based sessions. Thanks bitsweat. I just have an > architectural question / suggestion.</SPAN></SPAN></SPAN></DIV><DIV><BR > class=3D"khtml-block-placeholder"></DIV><DIV><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; ">The CookieStore > takes great care to provide integrity of session data, but we seem to > have lost confidentiality in the process. The server-side storage > methods had the implicit advantage of keeping the session data secret, > but I don''t know if this was intentional or just an unintended > consequence.=A0</SPAN></SPAN></SPAN></DIV><DIV><BR > class=3D"khtml-block-placeholder"></DIV><DIV><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; ">Would anyone see a > disadvantage to symmetrically encrypting the cookie data rather than > signing it with an HMAC?=A0</SPAN></SPAN></SPAN></DIV><DIV><BR > class=3D"khtml-block-placeholder"></DIV><DIV><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; "><SPAN > class=3D"Apple-style-span" style=3D"border-collapse: separate; > border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; > font-size: 12px; font-style: normal; font-variant: normal; font-weight: > normal; letter-spacing: normal; line-height: normal; text-align: auto; > -khtml-text-decorations-in-effect: none; text-indent: 0px; > -apple-text-size-adjust: auto; text-transform: none; orphans: 2; > white-space: normal; widows: 2; word-spacing: 0px; ">As far as I can > think, this would retain all of the benefits of the current arrangement > while obscuring the session data from a potentially untrusted client. > (Not that untrusted-client is the normal way of things, but I tend to > think fail-secure.) I don''t think we need the full authenticity that an > HMAC provides, since we''re not trying to prove session authenticity to > anyone other than the server that generated the > session.</SPAN></SPAN></SPAN></DIV><DIV><BR > class=3D"khtml-block-placeholder"></DIV><DIV>Thanks!</DIV><DIV>--be</DIV><> /BODY></HTML>> > --Apple-Mail-37-430566699----~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I thought about the integrity issue, but wouldn''t it be sufficient to just prepend a known string to the data and verify it on thaw? According to this page (http://www.cryptopp.com/benchmarks.html), SHA-1 and AES are about equal in speed (SHA-1 is marginally faster). But I would guess that in this situation even an order of magnitude difference probably wouldn''t matter. (Warning: unsubstantiated claim!) I just noticed that the RDoc does make the nonconfidentiality assumption explicit, so this is probably less of an issue than I had originally thought. On Mar 21, 2007, at 1:30 PM, S. Robert James wrote:> > You''d still need to do the HMAC also, otherwise they could modify the > session. Even if they''re modifying in the dark, they could cause > funny things to happen (eg imagine storing an id of a model which will > be deleted...) - witness what happened to WEP when they forgot this. > > I agree with you that this should be an option. But I think that even > symmetric encryption is much slower than a simple HMAC - so there > would be a performance hit. > > Brad Ediger wrote: >> (apologies if this goes through multiple times, it''s been almost 24 >> hrs and I haven''t seen my original post) >> >> First of all, I love the new cookie-based sessions. Thanks bitsweat. >> I just have an architectural question / suggestion. >> >> The CookieStore takes great care to provide integrity of session >> data, but we seem to have lost confidentiality in the process. The >> server-side storage methods had the implicit advantage of keeping the >> session data secret, but I don''t know if this was intentional or just >> an unintended consequence. >> >> Would anyone see a disadvantage to symmetrically encrypting the >> cookie data rather than signing it with an HMAC? >> >> As far as I can think, this would retain all of the benefits of the >> current arrangement while obscuring the session data from a >> potentially untrusted client. (Not that untrusted-client is the >> normal way of things, but I tend to think fail-secure.) I don''t think >> we need the full authenticity that an HMAC provides, since we''re not >> trying to prove session authenticity to anyone other than the server >> that generated the session. >> >> Thanks! >> --be >> --Apple-Mail-37-430566699 >> Content-Type: text/html; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> X-Google-AttachSize: 7340 >>--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 21, 2:44 pm, Brad Ediger <b...@bradediger.com> wrote:> I thought about the integrity issue, but wouldn''t it be sufficient to > just prepend a known string to the data and verify it on thaw?Not always. This is getting into very difficult crypto. Basically, depending on the cipher, there may be cases where you can change one part of the text without changing the other. WEP tried to do the trick you''re talking about - for performance - and got nailed. There''s no reason to open up a can of worms like this. If you want integrity, you need a good HMAC.> > According to this page (http://www.cryptopp.com/benchmarks.html), > SHA-1 and AES are about equal in speed (SHA-1 is marginally faster). > But I would guess that in this situation even an order of magnitude > difference probably wouldn''t matter. (Warning: unsubstantiated claim!) > > I just noticed that the RDoc does make the nonconfidentiality > assumption explicit, so this is probably less of an issue than I had > originally thought. > > On Mar 21, 2007, at 1:30 PM, S. Robert James wrote: > > > > > You''d still need to do the HMAC also, otherwise they could modify the > > session. Even if they''re modifying in the dark, they could cause > > funny things to happen (eg imagine storing an id of a model which will > > be deleted...) - witness what happened to WEP when they forgot this. > > > I agree with you that this should be an option. But I think that even > > symmetric encryption is much slower than a simple HMAC - so there > > would be a performance hit. > > > Brad Ediger wrote: > >> (apologies if this goes through multiple times, it''s been almost 24 > >> hrs and I haven''t seen my original post) > > >> First of all, I love the new cookie-based sessions. Thanks bitsweat. > >> I just have an architectural question / suggestion. > > >> The CookieStore takes great care to provide integrity of session > >> data, but we seem to have lost confidentiality in the process. The > >> server-side storage methods had the implicit advantage of keeping the > >> session data secret, but I don''t know if this was intentional or just > >> an unintended consequence. > > >> Would anyone see a disadvantage to symmetrically encrypting the > >> cookie data rather than signing it with an HMAC? > > >> As far as I can think, this would retain all of the benefits of the > >> current arrangement while obscuring the session data from a > >> potentially untrusted client. (Not that untrusted-client is the > >> normal way of things, but I tend to think fail-secure.) I don''t think > >> we need the full authenticity that an HMAC provides, since we''re not > >> trying to prove session authenticity to anyone other than the server > >> that generated the session. > > >> Thanks! > >> --be > >> --Apple-Mail-37-430566699 > >> Content-Type: text/html; charset=ISO-8859-1 > >> Content-Transfer-Encoding: quoted-printable > >> X-Google-AttachSize: 7340--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/17/07, Brad Ediger <brad@bradediger.com> wrote:> The CookieStore takes great care to provide integrity of session data, but > we seem to have lost confidentiality in the process. The server-side storage > methods had the implicit advantage of keeping the session data secret, but I > don''t know if this was intentional or just an unintended consequence.My first cut used symmetric encryption. It''s a bit slower than HMAC, but both push thousands of ops/sec on my laptop so it''s not really a concern. The typical session stores a handful of utilitarian info: a user_id, a flash message, and perhaps a return URL. You shouldn''t, and needn''t, use the session for confidential data. I consider exposing these data (however obfuscated) as statement of the reasonable bounds of session usage.> Would anyone see a disadvantage to symmetrically encrypting the cookie data > rather than signing it with an HMAC?There isn''t much technical disadvantage, though it loses HMAC''s in-the-clear philosophical advantage. However, the cookie store is built to be easily subclassed; please do investigate! jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 21, 2007, at 2:08 PM, S. Robert James wrote:> > On Mar 21, 2:44 pm, Brad Ediger <b...@bradediger.com> wrote: >> I thought about the integrity issue, but wouldn''t it be sufficient to >> just prepend a known string to the data and verify it on thaw? > > Not always. This is getting into very difficult crypto. Basically, > depending on the cipher, there may be cases where you can change one > part of the text without changing the other. > > WEP tried to do the trick you''re talking about - for performance - and > got nailed. There''s no reason to open up a can of worms like this. > If you want integrity, you need a good HMAC.I fold. :-) There''s no easy and elegant way to fix this other than to clarify the assumption. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 21, 2007, at 2:15 PM, Jeremy Kemper wrote:> > On 3/17/07, Brad Ediger <brad@bradediger.com> wrote: >> The CookieStore takes great care to provide integrity of session >> data, but >> we seem to have lost confidentiality in the process. The server- >> side storage >> methods had the implicit advantage of keeping the session data >> secret, but I >> don''t know if this was intentional or just an unintended consequence. > > My first cut used symmetric encryption. It''s a bit slower than HMAC, > but both push thousands of ops/sec on my laptop so it''s not really a > concern. > > The typical session stores a handful of utilitarian info: a user_id, a > flash message, and perhaps a return URL. You shouldn''t, and needn''t, > use the session for confidential data. > > I consider exposing these data (however obfuscated) as statement of > the reasonable bounds of session usage.Couldn''t agree more, from a philosophical standpoint. And I''ve never had need to put anything more than the above into a session. I was just looking for an easy way to failsafe the API against someone who decides to use session[:credit_card_number]. Apparently there isn''t an easy way, and such people get what they deserve. :-)>> Would anyone see a disadvantage to symmetrically encrypting the >> cookie data >> rather than signing it with an HMAC? > > There isn''t much technical disadvantage, though it loses HMAC''s > in-the-clear philosophical advantage.Well, I was wrong about the technical disadvantage. See my discussion with S. Robert James in this thread. I''d rather have one big well- known weakness that people can code around than a few lurking ones. I''ll transplant parts of this discussion into my Rails book to make this more explicit, especially since CookieStore is the default now. Great job, by the way. It''s an elegant solution to a nasty little problem. Brad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> > > > > The typical session stores a handful of utilitarian info: a user_id, a > > flash message, and perhaps a return URL. You shouldn''t, and needn''t, > > use the session for confidential data. > > > > I consider exposing these data (however obfuscated) as statement of > > the reasonable bounds of session usage.Storing the user_id in a cookie is exactly the sort of security hole that does concern me. What steps have been taken to ensure that the data cannot be tampered? I also agree that rails should be secure by default. If the data is in text format, then I think session cookies by default is an unwise choice. Steven A Bristol --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Storing the user_id in a cookie is exactly the sort of security hole that > does concern me. What steps have been taken to ensure that the data cannot > be tampered?That''s what the HMAC is for, if you tamper with the data, the hash is no longer correct. http://en.wikipedia.org/wiki/Hmac> I also agree that rails should be secure by default. If the data is in text > format, then I think session cookies by default is an unwise choice.I don''t believe there''s a single person on this list who thinks we should ship security bugs. If there''s a genuine problem with the cookie store, we''ll take the actions needed to clean it up.> Steven A Bristol > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 21, 2007, at 9:28 PM, Steven A Bristol wrote:> > > > > > The typical session stores a handful of utilitarian info: a > user_id, a > > flash message, and perhaps a return URL. You shouldn''t, and needn''t, > > use the session for confidential data. > > > > I consider exposing these data (however obfuscated) as statement of > > the reasonable bounds of session usage. > > Storing the user_id in a cookie is exactly the sort of security > hole that does concern me. What steps have been taken to ensure > that the data cannot be tampered? >The HMAC ensures that. (http://en.wikipedia.org/wiki/HMAC) If the user tampers with the data, the MAC verification fails and the server rejects the session. This discussion is about situations where confidentiality might be required -- where you might want to store something in the session that you don''t want the user to be able to read. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Not really knowing much about the new cookie storage for sessions, is the session effected if I set cookies in javascript on the client machine? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Short answer: don''t do that with cookie based sessions. Always remember what sessions are - an abstraction that gets around the stateless nature of HTTP. It''s merely there so that you know that the HTTP request has come from somebody you''ve dealt with recently. That''s it. It should contain the minimum amount of data necessary to identify where you are in the transaction sequence - assuming the information from the URL supplied is insufficient to do that on its own. Beyond that you are polluting the session layer with application concerns, for which you must expect to be smited by the Gods of Programming :-) NeilW On Mar 22, 2:34 am, Brad Ediger <b...@bradediger.com> wrote:> This discussion is about situations where confidentiality might be > required -- where you might want to store something in the session > that you don''t want the user to be able to read.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Read the rest of the thread. I agree with you completely. :-) On Mar 21, 2007, at 11:09 PM, Neil Wilson wrote:> > Short answer: don''t do that with cookie based sessions. > > Always remember what sessions are - an abstraction that gets around > the stateless nature of HTTP. It''s merely there so that you know that > the HTTP request has come from somebody you''ve dealt with recently. > That''s it. > > It should contain the minimum amount of data necessary to identify > where you are in the transaction sequence - assuming the information > from the URL supplied is insufficient to do that on its own. > > Beyond that you are polluting the session layer with application > concerns, for which you must expect to be smited by the Gods of > Programming :-) > > NeilW > > On Mar 22, 2:34 am, Brad Ediger <b...@bradediger.com> wrote: >> This discussion is about situations where confidentiality might be >> required -- where you might want to store something in the session >> that you don''t want the user to be able to read. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/21/07, Steven A Bristol <stevenbristol@gmail.com> wrote:> > > The typical session stores a handful of utilitarian info: a user_id, a > > > flash message, and perhaps a return URL. You shouldn''t, and needn''t, > > > use the session for confidential data. > > > > > > I consider exposing these data (however obfuscated) as statement of > > > the reasonable bounds of session usage. > > Storing the user_id in a cookie is exactly the sort of security hole that > does concern me. What steps have been taken to ensure that the data cannot > be tampered? >guid field instead of database IDs will mitigate some of your concerns @user = User.find_by_guid(session[:user_id]) court3nay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---