Re: [cgiapp] enciphered-cookie-only sessions
On Mon, Mar 10, 2008 at 8:28 AM, Perrin Harkins [EMAIL PROTECTED] wrote: Have you tried browsing the web without cookies recently? It doesn't work at all on a large number of popular sites. For better or worse, cookies are a part of the deal now. But that doesn't mean anything belongs in a cookie. It seems to me if it can't be clear text it shouldn't be in a cookie. At least if it's clear text I have the opportunity to see what's going on and make a choice about whether to accept cookies from a site. I'd go further and say nothing but a session key should go in a cookie. Once it turns into additional elements, opinions differ about what's sensitive or not (userid?, first and last names?, mailing address? date of birth? credit card number?). If it's just a session key there's not a lot to think about. If it contains more than that there's always the risk that the cookie setter's ideas violate my sense of privacy or security. If it's encrypted, who knows what's going on. The fact that it warrants encryption would give me concern. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
* Mark Fuller [EMAIL PROTECTED] [2008-03-10T09:06:30]
On Mon, Mar 10, 2008 at 3:56 AM, Ricardo SIGNES
[EMAIL PROTECTED] wrote:
stores your whole session in the cookie. It's stored as a base64-encoded,
Rijndael-enciphered, JSON-encoded string. This seemed like a swell idea
for me,
I hear a lot about brute-force attacks on encryption. Also, that what
seemed like a terrific amount of brute force 5-10 years ago isn't
today. Is that a concern (if someone steals cookies)?
I think the amount of brute force required would still be pretty darn brutal.
I wouldn't use this for anything like banking or credit cards, but I feel
pretty okay about it for things like a Rubric login.
Probably what I'll do in the (near) future is have an n-day log of secrets,
generated daily. The cookie will then be like
{ generated: mmdd, cookie: ciphertext }
You'll have to crack the secret within n days, which makes it even more
tedious.
Anyway, like I said, and like others say, this isn't for everyone or
everything.
--
rjbs
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] enciphered-cookie-only sessions
* Michael Peters [EMAIL PROTECTED] [2008-03-10T09:15:26] Ricardo SIGNES wrote: It's a Catalyst plugin that stores your whole session in the cookie. It's stored as a base64-encoded, Rijndael-enciphered, JSON-encoded string. Krang does this as well and I've used it on lots of other projects too. But, I think that's a little overkill. I just use a URL encoded JSON cookie. I don't put anything sensitive in there. I usually use this in conjunction with a normal session cookie. So the sensitive stuff goes into the server side session and the non-sensitive stuff in the client side session. Right... the encryption ceases to be overkill when you eliminate the server-side cookie and don't want someone to be able to change his username! The nice thing about putting things into the cookie in an easy to read JSON format is that my client side AJAX/Javascript code can use it too. For instance, Krang has a user preference to determine how long you want the messages that slide-in to remain visible. With this stored in this JSON cookie we can access that from the Javascript, since that's what creates the slide-in messages in the first place. Yeah, that's an interesting point. I should extend my session definition to have private and public data! The reason I use 2 session cookies (one just the key to the server side session and the other a JSON cookie) is mainly because of (c). Cookie size is limited and I can't guarantee that some people's sessions won't get really big. Yeah. Again, in this specific application, I know all the data that might go into the session, and they are all small. -- rjbs # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
* Mark Fuller [EMAIL PROTECTED] [2008-03-10T09:27:47] On Mon, Mar 10, 2008 at 6:15 AM, Michael Peters [EMAIL PROTECTED] wrote: I just use a URL encoded JSON cookie. I don't put anything sensitive in there. Is there a risk that this contributes to the bad reputation of cookies? One person puts stuff in a cookie and obfuscates it (presumably for a reason). Another encrypts it (presumably for a reason). There's no transparency for the user who isn't even asked if they accept this. Who obfuscated? URI-encoding is just useful to make it 7-bit safe. (I think!) It's barely obfuscatory, too, if you know the few common things that will appear. I don't know that cookies have a bad reputation at all! They're just accessible to the user to view and edit, and they have a small maximum size. Having a cookie containing authenicated_user_name=rjbs in the clear would be stupid. Trying to store a complete serialized set of preferences for a complex application would also be stupid. To me, it sounds like the kind of thing that makes people disable cookies entirely (or, trust them too much and, before too long someone's definition of what's not sensitive and satisfactory obfuscation is incorrect). It seems like just storing a sessionID avoids all that. Is making the programming less complex worth falling into that category of cookie suspicion? What's the kind of thing? Huh? I have no idea what you're driving at. -- rjbs # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
RE: [cgiapp] Re: ValidateRM and dynamic content
Sorry for the late response. I was up against a deadline and had to switch tactics, but wanted to post a follow up for at least archive purposes. The project ultimately produced surveys each with content that could be classified into different form types (checkbox, radio, text, etc) and some more complex forms (ex. Some checkbox and radio sections require accompanying text (check 0ther or Please describe...)). In any event all questions belong to one variation of a form element. I created one template that contained all of the standard form info (headers/footers, etc) and a loop that examines each question on that template (question info is stored in a database) and displays the proper form element. Everything worked great until validation. The problem seems to lie in the fact that the name of the form element was dynamically named. Example: input type=text name=TMPL_VAR foo maxlength This works great for the original display of the template, but if errors are detected there doesn't seem to be a way (that I can think of at least) to template the error message. My error messages have the prefix 'err' so to template error message I am left with: TMPL_IF err_TMPL_VAR foo err_TMPL_VAR foo /TMPL_IF The TMPL_IF line is not legal H::T syntax, so I tried the line without TMPL_IF statements. No matter what I did the error message would not display. I ended up creating one template for each survey section each with the questions for each section explicitly defined (mostly static) in order to get the project out the door. I'd like to revisit the idea of one dynamic template for this application because it would make annual maintenance simple and adding new surveys trivial. After I asked the list I did try creating a bit of HTML::Template code separate from the dynamic template and then tried to include it back in. The closest I came to making it work is error sections were created and physically included in the template so that the TMPL_IF error code posted above would be part of the page source of the HTML page. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Stosberg Sent: Saturday, March 08, 2008 4:32 PM To: cgiapp@lists.erlbaum.net Subject: [cgiapp] Re: ValidateRM and dynamic content I am using HTML::Template and CGI::Application::Plugin::ValidateRM. Page content is generated dynamically which works fine until a validation error occurs. Unfortunately err_TMPL_VAR field_name is not valid H::T. Could you provide a more complete example? I have been using ValidateRM and H::T with complex websites for years and haven't gotten stuck here. I suspect there's another way to accomplish your goal while still using sing these tools. Mark -- http://mark.stosberg.com/ # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Test Failures with CGI::Application::Plugin::TT
Hi Cees, feature). I don't have a windows box to play with so there is not much I can do to fix this. I would appreciate if someone could take a few minutes to do some debugging. A patch would be greatly appreciated, and/or SVN access to my CAP::TT repo can be organized for anyone willing to put in a bit of time to fix this problem. I am willing to do whatever debugging seems helpful. Besides what Ron already tried, do you have any idea where I could look? I won't be able to get at it before the weekend but I will definitely do what I can to fix this. CAP, TT and CAP::TT with them are the heart of most of my applications so I am very interested to get the current version without a force install. -Michael # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
On Mon, Mar 10, 2008 at 11:43 AM, Mark Fuller [EMAIL PROTECTED] wrote: But that doesn't mean anything belongs in a cookie. It seems to me if it can't be clear text it shouldn't be in a cookie. At least if it's clear text I have the opportunity to see what's going on and make a choice about whether to accept cookies from a site. Again, have you tried turning on the ask me option for cookies lately? You'll find that many pages give you a dozen or so cookies from various ad banners and the like. Hardly anyone looks at cookies, and those who do will probably be happier if they don't look like readable text. I'd go further and say nothing but a session key should go in a cookie. Once it turns into additional elements, opinions differ about what's sensitive or not (userid?, first and last names?, mailing address? date of birth? credit card number?). Information that isn't sensitive can be made tamper-proof with an HMAC. Information that is sensitive can be encrypted with a strong cipher like Blowfish. It's not that hard. The real issue with cookie-storage is avoiding sending too much data back and forth. In a typical application, sessions contain a handful of database IDs and uncommitted form data, so the size is reasonable. - Perrin # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
On Mon, Mar 10, 2008 at 11:46 AM, Mark Fuller [EMAIL PROTECTED] wrote: BTW: I didn't understand the part in the Catalyst documentation saying the benefit of sending the session in the cookie is that you don't have to access the disk. I assume that's supposed to be a performance benefit. But, after two encodings and an encryption, and two decodings and a decryption? I don't see how that could be much of a performance boost. It's worth benchmarking, but it seems likely to me that even strong encryption is faster than fetching data from a database. Removing one or more database hits from every page access could be significant. Most web servers have tons of idle CPU because they're constantly waiting for I/O operations. The real win in my mind is scalability -- you no longer have to worry about how to share the data across your cluster. No matter how many servers you add, your cost for session storage never goes up. - Perrin # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
* Mark Fuller [EMAIL PROTECTED] [2008-03-11T10:52:29]
On Mon, Mar 10, 2008 at 9:54 AM, Ricardo SIGNES
I wouldn't use this for anything like banking or credit cards, but I feel
pretty okay about it for things like a Rubric login.
The problem (from my perspective) is that if it's encrypted *I* have
no idea what you're trying to store on *my* computer. Nor what
encryption method you've chosen (if any at all, it could be base 64
encoding to obfuscate the data), your diligence in choosing a
passphrase.
If you don't trust my ability to make security decisions, you shouldn't use
services I provide. Period. If I only stored a session key, and then looked
up sessions in Amazon S3, where I stored your credit card number in the clear,
with a password of rjbs you would never know.
One must make security decisions based on the reputation of the service
provider, because the implementation details will generally not be exposed.
Probably what I'll do in the (near) future is have an n-day log of secrets,
generated daily. The cookie will then be like
{ generated: mmdd, cookie: ciphertext }
You'll have to crack the secret within n days, which makes it even more
tedious.
I was thinking more along the lines of a cracked cookie being harmful
to me, not you. :)
If cookie vulnerability means someone can alter someone else's data, it's bad
for the service provider AND the service consumer. Am I missing something?
I guess someone could store child porn in encrypted cookies on users'
computers, but...
What's the specific problem you're objecting to, here?
This just doesn't seem like a good use of a cookie to me. It could be
a good use. But, as the person upon whose computer it is being placed
(which might be a public computer, et al), I can't tell if it's a good
use because it's encrypted. A lack of transparency into what's being
placed on (hopefully) my computer doesn't seem like a good thing. It
may make the operator's processing more efficient and scalable. But,
I'm old enough to remember people making that argument for storing
private information as hidden form fields 15 years ago.
...but fifteen years ago, the data was still visible in the clear, so it was
obviously stupid for any use case where the connection was not secure end to
end. I don't see a serious security vulnerability here, at least for services
that will not be attracting huge amounts of CPU-years of attack per day.
Is your objection just that you don't want me storing anything in your
browser's cookie jar that isn't plaintext or a serial number?
--
rjbs
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] enciphered-cookie-only sessions
Ricardo SIGNES wrote: Is your objection just that you don't want me storing anything in your browser's cookie jar that isn't plaintext or a serial number? Also, I'd like to make that point that a good unique session id (like one generated form mod_unique_id) will be indistinguishable from some encrypted data or some data structure. They need to be Base64 encoded (or similar) to be used in HTTP headers anyway, so it's all plain text. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] enciphered-cookie-only sessions
On Tue, Mar 11, 2008 at 8:19 AM, Ricardo SIGNES [EMAIL PROTECTED] wrote: Is your objection just that you don't want me storing anything in your browser's cookie jar that isn't plaintext ... Yes. I thought I'd said that more than once. A unfortunate perception exists among many that cookies are bad. IMO encrypting session data and placing it in a cookie contributes to that perception. It doesn't mean every usage is bad. But, it can be. The problem being that it's not transparent for the recipient to make that determination. I agree with you that worse things could be happening on the backend (storing credit card numbers in clear text on a loosely secured network-accessible device). Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
