If this technique is good enough to make sure that you still are who you said you were when you logged in, why is this not good enough for storing other sensitive information? And if it's not good enough for session management, then you're in deep trouble anyway, since someone else can now log in as you and funnel all your money into their Swiss bank account.

Edit: As it turns out, it seems that most cookie-based session data is only stored cryptographically signed, rather than encrypted. The reason for this seems to be that HMAC signing is up to 4X faster than encrypting with Blowfish.

For session management - that's not the only way to handle user information. Often the web server will store a unique hash value and temporarily store the users information on the server with the associated hash. Note: if you're not using sticky sessions on server connects or a distributed server side session object that users info will be lost on reconnect if they hit a different web head.

And no, it is not entirely good enough for session management, which is why when you're on amazon.com or other online sites and you go to your account you are prompted to reenter your password. It is another level of security, but nothing is perfect.

Amazon/ebay/etc would usually do this because they have unencrypted parts of their site you can be directed towards, or unencrypted services, which would expose the cookies in transmission for session information [although I'm pretty sure they've got secure cookies for some parts of their acct mgmt]. Online payment processing force https for cookies and for session management and sets server & client side session timeouts, expire the cookie to prevent any possible future session hijacking, as well as many other procedures to secure their online services. There's a lot to PCI compliance.

edit: as phil said, HMAC is good policy if you store information on users on the client side, but I wouldn't put anything more than user tracking or analytics info in there.

No, that's not how session tracking works. The server uses a cookie to assign you a temporary ID, and then creates a corresponding storage area "server side" which can contain data like credit card numbers.

> Rails 2 introduced a new default session storage, CookieStore. CookieStore saves the session hash directly in a cookie on the client-side. The server retrieves the session hash from the cookie and eliminates the need for a session id. That will greatly increase the speed of the application, but it is a controversial storage option and you have to think about the security implications of it:

If you're using cookie sessions, you should know better than to store sensitive information in the session.

This approach seems strange to me. Why is this approach taken? Why not encrypt everything?

I only really know anything about writing server-side web code from using Play Framework, which provides a "session" object for storing information in the browser using the cookies mechanism. Everything in the session object is kept encrypted on the client in a cookie.

The most common use for the session information is to store a user ID and/or a session ID, but I believe it not uncommon to use this to store additional small bits of information if this will take some load off of your database and/or cache, and to help the server be more RESTful/stateless.

Edit: It turns out that I was not quite correct about Play. Like Rails, it seems to only sign the session cookie, rather than encrypting it. From looking at some benchmarks for the performance of HMAC vs Blowfish, it seems that signing with HMAC can be up to 4X faster than encrypting with Blowfish.

We at Phusion have created an encrypted session store in the past (http://blog.phusion.nl/2010/04/13/announcing-encryptedcookie...). However we've found it to be of limited use (and indeed, it doesn't look like many people use it). If your data is sensitive then you're better off storing it on the server. If your data is not sensitive then encrypting it doesn't help you.

I don't want to think about how many rails user don't know this and send sensitive data to the client.

Edit: wouldn't have written this if I'd seen FooBarWidget's more detailed remarks first.

Ah, yes I see. I just found a benchmark that shows HMAC to be up to four times faster than Blowfish. Well, that explains things.

Ah, another reason to hold REST in contempt...

They could do without a (full) CC number there. Ergo, it's a violation.

It's simple defense in depth, and does reduce the risks - say, if the encryption you thought was secure really isn't, etc.

UK is definitely missing a trustworthy, ethically sound bank though.

http://www.co-operativebank.co.uk/servlet/Satellite/11932063...

As another commenter wrote, their online banking is "primitive", but it's usable.

Particular nits are: - pressing the browser 'back' button triggers an immediate logout - they don't use email for anything except to tell you they've sent you a "secure message" that you have to log in and read - no data export (though there are greasemonkey scripts)

Their customer service I've found to be fine unless you want anything usual, complicated, or to be done in a timely fashion. Much like any large company, really

For example, I can pay in a cheque or withdraw funds over the counter in a Coop Bank branch, but if I want to set up a foreign bank transfer I have to use the an online secure message. When I asked why I was told over and over "smile is an online bank". Which I suppose is true, up to a point.

In lesser annoyances, they make you do a stupid amount of typing to log in, about the only bit of which is actually secure is two randomly selected digits from your 4-digit PIN. All other info is insecure: account number, sort code, first school attended, yada yada yada. All in all they make you enter something like 30 characters spread across 3-5 input boxes and two pages, all for about 6 bits of actual entropy. Unless, of course, you're the sort of person who when asked to tell your bank what your first school was, replies "8EOHzxdO6QnJ".

> Another mutually-owned business, and a clear best buy in the report is the Co-operative Bank. Since 1993 – and in response to the kind of concerns shown above – it has been developing detailed public position statements on who it will and who it will not lend to. These now cover seven human rights areas, five environmental areas, four international development areas and five animal welfare issues. More details are available at www.co-operative.coop/corporate/ethicsinaction/ethicalpolicies. It also uses your money to campaign on key issues of the moment such as unconventional fossil fuels or the decline of bees. Although other banks have come up with similar policy statements, none come close to the Co-operative’s for clarity and ambition. One of the most frequently asked questions at Ethical Consumer is how the Co-operative can be a best buy when its score is much lower than other providers. Our answer is that its relatively low score is the result of it being part of the Co-operative Group which – as a supermarket – is involved in animal farming and other activities which its banking competitors are not. Best Buys are there for us to apply a sense check to our mechanistic, but largely useful, rankings. In other areas, we weight key categories for the sector when choosing the best buys – such as workers' rights and supply chain management for clothing. In banking, having a clear ethical lending policy is a prime concern, which is why the Co-operative tops the pile.

http://atlanticyardsreport.blogspot.com/2012/06/t-shirt-im-s...

Barclays Center is built above a rail yard, which wasn't really doing much for the neighborhood either. All the hate for Barclays Center is completely misguided and the complaints are just the NIMBY types looking for something to whine about.

So I don't understand how anyone could possibly call redeveloping a rail yard into a stadium "shady". Maybe you don't want the foot traffic in your neighborhood, but it's hard to blame Barclays for that.

This is the real issue. Banks can certainly afford to hire qualified engineers; Santander apparently chooses not to.

because their customers chose not to care (at least, until shit hits the fan). A bank (or any conservative organization) will only really react, as it is too slow to become proactive (otherwise, it'd be by definition, no longer conservative! ala, google, facebook etc).

The banking rules should be so that even an immoral Scrooge would see proper security as the cheaper, cost-efficient way compared to screwing their customers with shoddy systems.

If a bank teller violates financial privacy by leaking his customer's transaction lists, it carries criminal penalties in many countries. Why should a manager who intentionally violates banking privacy of thousands of customers face less prosecution?

While security and encryption are definitely not easy (and far less so when you're talking about adhering to PCI-DSS Level 1, which somehow actual banks never seem to do), there are plenty of well-tested libraries that make it significantly easier. Having said that, I'd prefer to see the data stored in plaintext - obviously bad - rather than using easily-broken encryption (short keys, re-used keys, bad key storage, poor algorithm, etc) which looks OK at the surface but provides a serious false sense of security.

What really blows my mind is that Visa and Mastercard never seem to require PCI certification for their issuing banks. Being deep in the industry I realize how many middlemen and layers of misdirection there are with this kind of thing (usually to get around these security requirements), but Visa's diligence process is actually quite thorough - at least in the US. I've been interviewed by PCI auditors, and my experience was that they were actually asking the right questions, and required demonstrations to prove your claims. But for all I know, that varies widely from auditor to auditor.

I find it difficult to imagine someone new entering this market place, other than "people" like Virgin and Tesco with deep pockets to back them.

[1a] http://www.guardian.co.uk/tv-and-radio/tvandradioblog/2012/j...

[1b] http://www.ft.com/cms/s/0/2ba372d4-d80b-11e1-80a8-00144feabd...

[1c] http://www.burnleysavingsandloans.co.uk/about-us/

They force a 640px popup window that deliberately hides addressbar, so you can't easily check if it's HTTPS.

My browser warns me that their site still has SSL renegotiation vulnerability unpatched.

You are the first and only person to mention the SSL issue so far as I can see, given the quality of your other comments I am inclined to disregard this as you not understanding what you were being told or because you are using a defective browser.

EDIT: I've just logged in, my popup window (Firefox, OS X) does have an address bar. My instinct was correct, you have no clue.

Safari obeys their wishes fully.

Run this in JS console before clicking "Internet Banking"

    window.open = function(){console.log(arguments)}

    ["/1/2/pib-service", "pib", "toolbar=0,location=0,directories=0,status=1,menubar=0,scrollbars=1,resizable=1,width=780,height=510,top=0,left=0"] 

Just as a countering data point, I've been with NatWest for 14 years both for personal and business banking (plus a business credit card) and have had nothing but an excellent experience with them (the only negative I can think of is their online banking goes down for maintenance at 2-3am sometimes for an hour or two).

- I have no idea if it's PCI compliant (I would hazzard a no here)

- Obfuscation is such weak security it should be considered as pretty much worthless

- It's vulnerable to cookie jacking over non HTTPS

- It's vulnerable to theft if you have access to a computer where someone has logged on

There are other ways of doing it, putting it in a short live cookie is one of the worst ways

Say obfuscation = encrypted.

> It's vulnerable to cookie jacking over non HTTPS

That's why you use the secure and httponly flag for the cookie.

> It's vulnerable to theft if you have access to a computer where someone has logged on

Pretty much everything is vulnerable to theft if you have access to a computer where someone else has logged on.

Are there any actual crypto experts reading who'd comment on the dangers of encrypting multiple credit card numbers with the same key? Keep in mind for a single bank the first 4 digits of a credit card will all be one of two choices (their Visa or Mastercard prefix) and for a single branch I think the first 6 digits will be the same for every customers Visa card, which only leaves 9 digits (and the checksum).

Surely a naive approach like:

  $encrypted_cookie_text = any_encryption_function($sixteen-digit-cc-number,$global_key);

I don't see how that follows. Storing credit card details on the server is generally a bad thing to do and takes a lot of work to get it to be PCI compliant.

What would be wrong with a different key/salt per user stored on the server, with the credit card number stored in a short-lived, secure, httponly cookie?

Also you didn't address the most important point, PCI compliance.

The method Santander employs is unquestionably a bad way to do things.