Take my cookie! Choke on it! CHOKE ON MY COOKIE!!

Remember the good old days, when if you configured your web browser to remember cookies for a site forever, you wouldn't have to log in again all the fucking time? Gosh, those were the days. Before sites kept a useless shit-ton of server-side session state that they felt the need to constantly expire on you. Or before they decided to log you out every N days for "security" reasons.

Also remember when if you told your web browser to remember your user name and password for web sites, that worked? When people actually used HTTP authentication instead of crazy-assed bullshit involving JavaScript and Flash and turning off autocomplete, because they know better than you? Yeah. Those were the days.

Dear Interweb: fucking knock that shit off.

Tags: , ,

59 Responses:

  1. Right but noone ever made basic auth programmable, right? Well, except for embedding a password in the URL, and that always gives me a kind of nervous tick. I'd love to use basic auth more, but I think it needs a little coding love first on the browser side and I think many other webmasters might agree.

    • duskwuff says:

      • There's no way to force a logout
      • Basic sends your password in plain text (well, base64, but that's practically plain text), and the fancier schemes still aren't well-supported
      • There's no way to customize the login UI
      • Some mobile browsers don't support HTTP authentication at all, because nobody uses it
      • jwz says:

        See, these would all be examples of things that are not interesting, and are orthogonal to my point. Which is that shit used to work better. Excuses for why you think it's reasonable for it to work worse don't make it work better.

        • duskwuff says:

          I'm not so sure, though, whether it's a matter of "that shit used to work better" or of "people used to care less". The lack of any way to log out has always been a known problem, for instance, as has the insecurity. It just so happened that, back when this stuff was all new, public terminals and insecure wireless weren't design considerations.

          • jayp39 says:

            You log out with HTTP auth by closing the browser. You log out of everything that uses cookies all at the same time automatically by deleting your cookies.

            • duskwuff says:

              If closing the browser makes your HTTP authentication go away, then it's strictly inferior to a session cookie - you've got to log back in every time you restart your browser, and there isn't even any way to autofill the password.

              • jayp39 says:

                You tell your browser to remember the password, and it does. You can also tell your browser to forget the password. In other words, control is firmly rooted in the client side, which means the server can't decide that it's time to forget that you're logged in and that you asked it to remember you.

              • nester says:

                I think you failed to understand the point.. He's not saying "fuck cookies" so much as "Hey fucktards, don't make my cookies expire"

            • asjo says:

              You log out with HTTP auth by closing the browser.

              So because I want to log out of one website, I have to close all my other browser-windows and tabs.


              (Other than that, I agree fully).

              • mcsmurf says:

                I think some browsers allow you to logout without closing the browser. For example SeaMonkey should be able to do that (Tools->Password Manager->Log Out).

          • hatter says:

            It would take about 2 seconds to add an http auth logout function to the web browser. I continue to boggle at its absence. I fact, it's so simple it's the sounds like a handy little project to learn firefox's codebase for, then hope it propagates to Opera/IE/Safari, and then the million other browserish products out there.

            The hackier option is to have the website lie. You present your auth details again, and the server shakes its head, tells you they don't work this time. Generally, the browser then throws away the login values it cached.

            the hatter

            • jmtd says:

              The hack for most browsers is to visit a URL that logs you in with a different username. something like logoutuser:fakepass@site.com/...

              • hatter says:

                Didn't realise that one. Would also have been easy for site designers to link to that - before browsers started warning by default about URLs with credentials in.

                • kowh says:

                  The problem with this is that it doesn't work consistently across browsers. Even different versions of the same browser. And on some of the browsers none of the hacks seem to work.

      • I agree with all this except customising the login window. Any customisation should really just be to confirm the site... show a logo embedded in the site certificate for example. For me, the whole point of this vs. cookies is that there is some client-side security. The most important part is to add appropriate salting and hashing so that the password is not sent in plaintext on the wire.

        Yes, there needs to me a way to force the client to forget the password.

        • duskwuff says:

          Eh, I dunno. There's some bits of customization that might make sense, in terms of added options (authentication domain, bind to IP address, expiration period, etc). You could probably hack at least some of this in by allowing suffixes on the username or something similar. That'd be pretty ugly, though, not to mention nonintuitive.

      • 00. You can force a logout: send back a 401 Unauthorized response.

        01. If you care about snooping, aren't you using SSL? Not that this makes the naive approach to authorization *good*, but it makes it better than the vast majority of form-based schemes,

        10. Why do you want to fuck with my user experience? My browser happens to have a rather *nice* login dialogue and I don't trust any of you to create a nicer one.

        11. Some mobile browsers need to get with the 90s, at the very least, before trying to get past 2000.

        • duskwuff says:

          00: See thread above. It turns out that doesn't work reliably - and shouldn't be expected to, as the behavior of the browser isn't particularly well specified.

          01: SSL sucks. Massively expensive on the server side, (still!) requires a dedicated IP, costs money for a certificate that browsers won't complain about, etc.

          10: See other thread above. Sometimes there's more relevant data than a username and a password.

          11: Granted - but given one solution that works in all browsers and another one which doesn't, I think I know which one I'm using.

      • taiganaut says:

        I think HTTP digest authentication may solve yr second point. IIRC it doesn't just send a hash of the password, but rather does a little challenge response dance. I could be wrong though.

  2. jayp39 says:

    Agreed. There's no excuse for that crap. I'm working on a flash app right now (or rather, the backend for it) and we're configuring it to work better with remembering your password and auto-logging you in. If we can do it with a flash app, there's no excuse for less complicated pages.

  3. As with any other human-made feature it had both negative and postitive effects. For example your cookies can be used by federal agents against you:)

  4. fo0bar says:

    I went to chase.com to pay my credit card bill this evening. The cycle for the last year or so has been this:

    1. Go to chase.com, notice that the username is not pre-filled.
    2. Enter my username and password, check "remember my username", never actually expecting that to work the next month. Log in.
    3. Get "Hey, we don't recognize your computer!" (Note: my computer has not been given plastic surgery in the last month.) "We'll have to SMS a code to your cell phone so you can prove yourself to us!
    4. It does so, I enter the 6-digit code, it lets me in.
    5. I pay my credit card bill.
    6. Repeat next month.

    This month, the username wasn't pre-filled, but here's the surprise: it didn't "not recognize" my computer! Isn't technology amazing!

    • taiganaut says:

      It's probably installing an ActiveX control to query yr 'Windows Genuine Advantage' hardware hash. heh.

    • imsaguy says:

      I get this too. cardmemberservices.com, which is an identical site except its hooked up to all of their branded cards, has the same checkbox and doublecheck. It actually remembers the username as well as the doublecheck, so I'd venture to guess that part of their code is broken on chase.com.

    • nester says:

      yeah, part of the reason I canceled my Chase card was because of this. Hate Hate Hate.

      That and I had been with them since 2004, had a 750+ credit score, and they refused to give me any better than 21% interest.

  5. kavavita says:

    one of my *favorite* fabric stores online times out a session after 30 minutes. This means that, wherever you are on their site, if you've been idle for 30 minutes, you get an error saying "sorry! your session has ended! please go to our home page and start shopping again!"

    This even happens when, say, I was shopping Monday night, left a browser open, and start working Tuesday morning, and click on a link from a blog/coworker/client saying "check out this product...". Their STUPID FUCKING SITE loses the context entirely, and sends me to a "your session has timed out, please go to our home page and start over" error page, with zero reference to what I was actually trying to get to. This is great, of course, because I usually have four rows of tabs going, and I have to go re-create what I was looking for in the first place, hoping that the original product reference is still in some chat/email log somewhere so that I can figure out what it was in the first place.

    Since a major portion of what I have to do is source materials, their shopping site PISSES ME OFF to no end. I've lost hours of time doing research, only to have them delete my entire cart full of carefully chosen materials, because I was idle for thirty minutes. My new solution is to just continually print my shopping cart to PDF so I can at least re-create it later.

    they aren't the worst, but they are a nationwide major retailer. No site where you have to have a user account in order to purchase goods should forget what you were trying to buy. ever.

    • inoshiro says:

      Have you tried telling them what is wrong, why, and how is has negatively effected your shopping experience?

      Waving $$s at companies tends to get them to fix the problem.

  6. superlib says:

    Another unneccesary kludge of technology is that 'site popup' thing on LJ. Some pople may use it and love it. Personally I don't want a mini-website to pop up any time I mouse over a link. But since the setting is stored in a cookie, any time I use a computer I haven't used before I'm subjected to it again. Or when cookies are auto-purged on my work computer.

    Opt-out settings should NOT be stored in cookies.

  7. taffer says:

    ARGH yes.

    The CMS we use here (cobbled together through McGyver techniques) logs you out every hour. Doesn't remember anything for you.

    Entirely pointless because it's only accessible from without our network, so you're already authenticated somewhere.

  8. mark242 says:

    You want to know what happened?

    Let me tell you what happened...

    Microsoft made saving form data the default behavior, and people happened to stay logged into their bank accounts, eBay accounts, etc, while using shared computers. A few lawsuits later, and you've got image-based challenge-response systems, "this computer isn't recognized" ip-validation systems, cookies holding only session ids, and other various security obfuscations.

    The real solution to the various security problems is not that stupid Firefox 3 behavior of coloring the url bar green, or making extra-big lock icons that scream "we're secure!" on your sites. The real solution is to use SSL all the time. Browser manufacturers have no excuse to work on the time it takes to create and break down an SSL request/response, and to store all cookie data with the server's public key, so each cookie is encrypted differently. Once you can assume that every request you're processing is SSL, and that any cookie data you send will be secure, you can send a lot more data down to be stored at the client.

    • One problem with that last sentence -- unless you're writing a web app strictly for a tightly controlled internal network, you can never assume that cookie data on the client is secure because it almost never is (if your user base is the general Internet public, that is).

    • taiganaut says:

      I dunno, my company is pretty much PCI compliant these days and I was testing the cart on our retail site last night and there were products in there that I'd put in 3 weeks ago.

      There are ways to be sanely 'secure' and not annoying.

    • sherm says:

      How does transport-level encryption at all help the "idiot typed his credt card number into a public computer and it's all Microsoft's fault!" problem?

  9. jferg says:

    Remember the good old days when 99% of the people on the internet weren't completely non-technical, and had at least a minimalistic grasp of a.) how the internet worked, and b.) how to keep their personal data somewhat private on their own? Yeah. Me too. Unfortunately, that's not the case now, and the majority of the stupid authentication schemes end up being implemented to keep the lusers safe from themselves. Unfortunately, they just end up inconveniencing the other 2% of the internet that doesn't think that myspace is the greatest thing since the hamsterdance.
    (And yes, I work for security at a bank, and we've been forced to implement most of this crap by the Office of the Comptroller of the Currency. But, given some of the stupid shit that I've found just by perusing our referrer logs, (http://luser.tripod.com/myaccounts.html, containing the user's entire username/password and account number list, anyone?) I think for the most part it's justified.)
    The session-timeout bullshit, though - there's just no excuse for that shit.

  10. Maybe another take on this whole thing: http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client-certificates/ though if you are multiple systems, then you need to lug a keychain around.

  11. evan says:

    Un(der?)documented LJ tip: if you put an ! after your username when you login, you don't have to check off the "remember me" setting. This means Firefox remembers "evan!" as my username so even when my cookies are reset the form autofill remembers enough that I don't have to check the checkbox when I log in again.

  12. cabrius says:

    MS's Xbox site is extra-retarded in that if you were previously logged in and the session expired, the next time you visit it will immediately take you to an "oh please relog in again now" page. Even if you were just going to the front page, or following a link from another site, or anything else that doesn't even need you to be logged in.

    If I remember correctly, it doesn't even give you a "no, go away, continue without logging in" option at that point.

  13. boggyb says:

    Hear hear.

    I spent a chunk of time yesterday attempting to find useful stuff (a headset driver that works with the Windows XP Bluetooth stack). After many pages of google results and several trips to the wayback machine I discovered that there's far too much noise, aggregration sites, advertising sites, dead links, domain squatters and people posting "how do i make this cool thing work without having to read the manual" to have any hope of finding actually useful information.

    • loosechanj says:

      useful stuff (a headset driver that works with the Windows XP Bluetooth stack)

      This must be some weird new usage of the term useful that I wasn't previously aware of.

      • boggyb says:

        I dunno, I consider a Bluetooth stack that automagically opens and closes connections to be pretty useful. Getting headset support for that stack would make it even more useful.

        (the dongle did come with the Widcomm stack, which while it does understand headsets it is full of many ways to trip you up, does evil things with driver signing or lack thereof, and doesn't automagically open and close connections)

  14. elusis says:

    Oh, so it's not just me/Firefox/my Mac then.

    I suppose that's some kind of small comfort.

  15. deviantq says:

    Recently I've found a pretty good solution for this, which is the iMacros plugin for Firefox. It's basically just very simple macro recording and playback that does all the smart things you would hope. So I can record myself performing complicated multi-step login procedures, and then save the macro into a bookmark, which is basically the easiest thing ever. It's a good fix.

    • strspn says:

      Neat. I was thinking Yes/No/Always/Never with adjustable defaults.

      Macros are cool, but, web forms can change, so what does it do when the the macro player hits an error -- and how can it possibly know that? E.g., when when tabs to the password field start ending up in the message field?

      • deviantq says:

        As I said, it's pretty smart; it doesn't use keyboard or mouse input, but instead navigates to certain elements on the page using, e.g., their HTML ID or the link text. So if the form/page changes, it has a very good chance of just failing.

        And if it fails, then the sidebar (in which you normally watch the macros execute) will show the execution path so far and highlight the step that failed; you can then edit the macro or whatever.

  16. lionsphil says:

    Jesus, the fact that hardly anyone uses HTTP auth these days, yet also break the idea that a URI encapsulates all page state (the fact that hyperdocuments now have state is a whole barrel of hate of its own), TROLLS ME ROTTEN.

    "Oh, hai, we redirected via this shitty form that just boings back to the URI you came from, and now all the form data and AJAX wankery state you were doing has been lost. Kthxbye!"