What sort of clowns stored the credit card number in a cookie? Seriously? What a breathtakingly stupid show of total incompetence.
Was considering switching my personal account to Santander, have been looking to move away from Natwest for a while now. Natwest are a dismal failure of a bank to the extent I'm always happy to go out my way and dissuade people from associating with them in any way. I'll be writing Santander off my list for sure now. How on earth can you trust them after seeing this?
For a business who HAS to take security seriously, for a business with a LOT of resources, for a business who hold YOUR cash this is utterly pathetic and inexcusable on their part.
Leaving them might be a good idea for your personal security, unfortunately the UK is a little short of good banks. Would love to see someone shake up banking like Stripe has shaken up online payments.
Maybe I'm an ignoramus, but what's wrong with storing your credit card number in a cookie, as long as it's encrypted? This is how session management is typically done, right? Your session information is stored encrypted in a cookie so that on subsequent page requests, the server still knows who you are, but the session information is encrypted and decrypted on the server, so that the client can't forge the session information.
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.
The level of 'good enough' security for banking is higher than general web browsing. Even though a user input for their CC number would be encrypted in transmission, that encrypted value is not stored for a long period of time. A cookie, even if encrypted, would allow for a greater ease of access, in general, so now it may be possible for a malicious user who is targeting the site to possibly gain many encrypted values - which depending on the encryption algorithm could allow for finding a flaw.
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.
> Maybe I'm an ignoramus, but what's wrong with storing your credit card number in a cookie, as long as it's encrypted? This is how session management is typically done, right? Your session information is stored encrypted in a cookie so that on subsequent page requests, the server still knows who you are, but the session information is encrypted and decrypted on the server, so that the client can't forge the session information.
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:
It's plenty secure in the sense that you can't forge a session. It's not secure in the sense that the data is inaccessible if you know how to base64 decode a cookie.
If you're using cookie sessions, you should know better than to store sensitive information in the session.
But it is not even encrypted. And AFAIK most (sane) sites do not store you account information encrypted in the cookie, they store a session id. This session id is then used to find the relevant session information which is stored on the server.
Well for starters, it's common practice (e.g. in Rails' cookie store, but many others too) to leave the cookie contents as plaintext and just append a HMAC so that you know they haven't been tampered with.
> it's common practice (e.g. in Rails' cookie store, but many others too) to leave the cookie contents as plaintext and just append a HMAC so that you know they haven't been tampered with.
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.
It is based on the observation that most apps only store the user ID and other non-sensitive data in the session. Storing the session in the cookie then brings many benefits. It does not require any server side session store maintenance, it is very fast and scalable because no database lookup is required. The fact that this store should not be used for storing sensitive information is well-documented in the Rails security guide. For storing sensitive information, one can use many of the alternative session stores available, such as the ActiveRecord session store which saves session data into the database.
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 dont know either why is this the default in rails.
In PHP you only have a session id in a cookie. When I first saw how it works in rails (ruby?) it blew my mind.
I don't want to think about how many rails user don't know this and send sensitive data to the client.
The advantage -- and it's often a big one -- is that you don't have to have a corresponding server component to translate session id to session state. The state is all in the client.
Edit: wouldn't have written this if I'd seen FooBarWidget's more detailed remarks first.
The session information is cryptographically signed, so you don't have to trust it! These stateless server frameworks are just using the client as a state cache.
The information is usually already publicly available : for examples the facebook graph api uses the same setup for some of their basic api methods (such as letting a site log you in through facebook) - base64 encoded json user data and an hmac signed with a private key + timestamp. Since the data is already publicly available (it's your facebook user id and other publicly available data), there's no need to use a more costly encryption algorithm. The hmac is there to confirm to the server who manages whichever associated online service that also created a facebook app you just gave access your profile to that this is good data, since they've got the secret on their end that the staff registered with on facebook. HMAC is fast.
No, it doesn't. No one should be using Blowfish for anything (except its key scheduler for bcrypt) and Blowfish is known to be slow as hell. A SHA-2 HMAC is basically identical in speed to AES-CTR. Sure, you want an HMAC on that, too, but whatever -- get a modern processor or an AES coprocessor. I guarantee this is not your performance bottleneck.
>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.
Even if the cookies would be properly encrypted, it still violates PCI DSS mandatory requirements - you aren't supposed to store or send a full credit card number unless necessary for an actual transaction.
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.
IANA security expert but I think session info is somewhat protected by the short TTL. The amount of time required to get at the session data should (hopefully) exceed its window of validity.
I've found Santander to be absolutely ghastly as soon as any exceptions to their core process occur. Anecdotal, but in my opinion you're probably better off avoiding them anyway.
Barclays online offerings are pretty good as well, depends on how much you can ignore their slightly shady ethics when it comes to investment banking. They also weathered the last financial meltdown a bit better than the rest, so there's that.
UK is definitely missing a trustworthy, ethically sound bank though.
Got there seconds ahead of me. Co-op (and Smile, their internet alter-ego) seem to be the ethically best choice. And their customer service is the best of anyone, ever.
I've heard negative things about their online banking and customer service, but those were a while ago so I'm not sure what the state of play is now. Could be worth a try, I do like their ethics.
Their online banking is fairly primitive, but it does the job. One thing which I find particularly funny is that if you want to have a standing order which continues indefinitely, you have to put a value of 999 in the "number of payments" field. I would have thought having a tickbox which says "Continue payments indefinitely" would be better from a user perspective.
Their (Smile) online banking is "not bad for a financial institution", and if that sounds like damning with faint praise ...
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
I've also found the customer service to be pretty good for the standard stuff but there is a blurry line between smile and The Co-operative Bank that confuses them.
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.
The one almost inexcusable omission from their online banking is any way to download your statements. You have to scrape the data from the pages themselves, and infuriatingly, they display the page of most recent items in a slightly different format to older pages, making it a pain to merge data scraped from different pages.
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".
I must admit I haven't personally used them so I can't comment on either of those things, but from a purely ethical point of view you are not going to get much better from a leading bank.
> 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.
They're owned by their members (hence the name), and operate pretty much exclusively as an old-school retail bank without any of the other banking activity that tends to at least wander into ethical grey areas.
I used to think that Mutuals would have their members interests first and foremeost. Certainly they never tire of telling people that. But my actual experience is that it's not true. Mutuals, commonly, are like any business where the owner (the membership) isn't paying attention and the result is a business that puts the interests of the staff first.
Service to members of a mutual society can be every bit as bad as any public listed company and is often worse because of the lack of a profit incentive means no one gives a damn
That's a bit of a strawman I think — surely by the logic you're using, the existence of a profit motive would mean that the company was interested only in serving its shareholders and would ignore its consumers? There are plenty of examples of this, but it doesn't mean it's true generally of profit-making companies.
On the subject of "slightly" shady, let's not forget Barclay's enabling (via a questionable naming rights deal) of neighborhood-killing, taxpayer-fleecing eminent domain abuse, either:
What's the problem with the MTA receiving $200,000 in free money? Nobody even knew what Pacific St. was anyway -- it's a minor one-way street that doesn't even go through at Flatbush. (The station should have been called Atlantic/Flatbush or Atlantic/4th but the MTA doesn't really name stations that way.)
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.
I think part of the incompetence has to do with what talented engineers want to work on. Most of us here on HN would never dream of writing mundane business logic software for a bank. Why would we, when we could be working on much more interesting problems, while earning a lot more money, working in a much more stimulating environment? This leaves mediocre programmers who can't get jobs at {Google, Facebook, Microsoft, Amazon, Startup X}. Talent goes where the money is, and the money is not in writing a bank web service.
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).
Because regulators don't do their job.
Private customers shouldn't be responsible for auditing their bank - instead, regulators should enforce fines for banking privacy and security breaches that are an order of magnitude greater than the cost of implementing the systems securely.
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?
In theory, I'd rather have it in a cookie than unprotected in a database. In practice, anyone doing something that stupid will have XSS exploits rendering that information available to anyone running an exploit.
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 don't know if you saw Bank of Dave [1] but it showed how difficult it is to start a new bank in the UK, even if you are going to be run responsibly and in a small way.
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.
Do you have any grounds for this disbelief or do you just a go around changing the subject to make unsubstantiated assertions? FD's customer service (the subject of the parent comment) is beyond excellent, they set the standard to which all others should aspire. The comment about hiding the addressbar is simply tinfoil hat-ism.
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.
I switched to FD over a decade ago after many cock-ups by NatWest (my previous bank for ~6 years), been happy since. A few minor problems, but they have always been fixed quickly to my satisfaction.
If they bank does not have a two token security system, its is not secure. A single password should never, ever, anywhere, be enough to legally prove identity or validate a bank transfer.
Natwest are a dismal failure of a bank to the extent I'm always happy to go out my way and dissuade people from associating with them in any way.
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 would agree with you. I have been with them for 20 years and I have never had one problem with them. They even let me off with some overdue charges (which were my fault) when I asked them nicely.
A little bit off-topic, but in what way(s) is Natwest a "dismal failure of a bank"? I had a Natwest account a few years ago when I was in the UK, and I was happy with it at least in relation to the other bank I had an account with.
I graduated 5 years ago with a maxed 2K overdraft. Last year I went to the bank to reduce the limit and the nice lady informed me I hadn't been paying interest the whole time on it, she promised to not to tell.
Doesn't seem too awful to store obfuscated credit card details in a short-lived cookie with httponly and secure set. (Say, in a checkout flow where you have to hold the credit card details somewhere for a couple minutes).
If you encrypt it, either you use a different key for each user's data, which means you're storing per-user session data on the server so you may as well store the cc number there, or you're not storing per-user keys on the server which (and I'm not a crypto expert here) probably opens you up to known plaintext attacks if an attacker gains access to many users cookies.
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).
could be brute forced pretty readily, with a knowledgeable guess at the first 6 digits and an understanding of the checksum algorithm, you're only left with one billion possible numbers. (In fact, I wonder if rainbow tables already exist for this for various values of any_encryption_function()?
If you encrypt it, either you use a different key for each user's data, which means you're storing per-user session data on the server so you may as well store the cc number there
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?
At the very least, the data (encrypted or no, but it should probably be encrypted) on the server related to a session lives outside the webroot, whereas in a cookie, even if it is encrypted, it's still essentially public. If there's no reason to have that data, explicitly, exposed in the client then why put it there?
Maybe a naive question/response on my part but why not rather encrypt it and hold it in a session? Or if you have to put something in a cookie, just a reference that points to some data on the server like an id, which has no real meaning to the end user?
I may be missing something, but what does it mean to "hold something in a session" if not to either
(1) store it in a cookie (encrypted or not) or
(2) store it server-side with a token stored in a cookie pointing to it?
I meant storing it on the server - just preferring not to have any actual cc data on the cookie, even obfuscated or encrypted. It may be a distinction without a difference, though, I honestly have never dealt with anything more complex than your basic 'hash username and password and check the hash when they login' scheme.
Was considering switching my personal account to Santander, have been looking to move away from Natwest for a while now. Natwest are a dismal failure of a bank to the extent I'm always happy to go out my way and dissuade people from associating with them in any way. I'll be writing Santander off my list for sure now. How on earth can you trust them after seeing this?
For a business who HAS to take security seriously, for a business with a LOT of resources, for a business who hold YOUR cash this is utterly pathetic and inexcusable on their part.
Leaving them might be a good idea for your personal security, unfortunately the UK is a little short of good banks. Would love to see someone shake up banking like Stripe has shaken up online payments.