Rails' CookieStore isn't broken
coffeepowered.net
Rails' CookieStore isn't broken
1–10 of 33 posts
Re: Rails' CookieStore isn't broken
#2The problem is not CookieStore itself but the fact that you need to know the caveats if you expect to use it properly. That alone makes it a bad default setting for a framework that favors convention over configuration.
Re: Rails' CookieStore isn't broken
#3I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using something like Firesheep or as simple as forgetting to logout of a public terminal. You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.
Re: Rails' CookieStore isn't broken
#4The CookieStore isn't broken but you do need to add code to fix the issue?
I have no experience with Rails but I really hadn't expected that sessions would be client-side only.
Re: Rails' CookieStore isn't broken
#5I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS.
Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO
Re: Rails' CookieStore isn't broken
#6I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS. Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO
What do you mean? Rails support running over HTTPS. Or are you suggesting that Rails never run over HTTP only?
Re: Rails' CookieStore isn't broken
#7I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS. Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO
What do you mean? Rails support running over HTTPS. Or are you suggesting that Rails never run over HTTP only?
I'm suggesting that site operators need to use HTTPS. It doesn't matter if you use Rails, PHP, Node.js, whatever. USE HTTPS. NEVER USE HTTP.
It's as simple as that. Never assume that anything transmitted over HTTP is safe, because that assumption will come back to bite you.
Re: Rails' CookieStore isn't broken
#8I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS. Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO
What do you mean? Rails support running over HTTPS. Or are you suggesting that Rails never run over HTTP only?
[deleted]
Re: Rails' CookieStore isn't broken
#9I hope that this will at least light a fire under the asses of Rails devs everywhere, and get them to adopt HTTPS. Nothing is safe against Firesheep without HTTPS. All of these issues would be solved with HTTPS. Also, doesn't cryptographically signing (or fully encrypting, in Rails 4) the cookie just add more time to processing than using a database? I always assumed cryptography is slower than IO
What do you mean? Rails support running over HTTPS. Or are you suggesting that Rails never run over HTTP only?
I think he means getting devs who deploy Rails apps to start using HTTPS for their app, rather than there being a deficiency in the framework.
Re: Rails' CookieStore isn't broken
#10I don't think requiring that your user(s) be compromised before this becoming an issue is a valid defence. Especially when cookies are easily stolen using something like Firesheep or as simple as forgetting to logout of a public terminal. You should ultimately be putting in systems that, if in the event of a compromise, you can mitigate the cost to the user.
I recognize this fight. Person A has a system, person B finds a problem in it. Now, is it a "real" problem?
Emotions run high, on both sides, and I've been on both sides of it at various points in my life. I recognize the patterns of the bad arguments made by both sides (by A: "of course you don't do that," "this requires something else bad to happen," "that's a problem with bad coders", "you are an idiot"; and by B: "every potential issue is worth full attention," "you should always stop your developers from breaking things," "you can't fix things with obscurity!!!1," "you'll be sorry", "you are an idiot.").