Lessons in website security anti-patterns by Tesco | Hacker News Reader

Lessons in website security anti-patterns by Tesco

troyhunt.com

352 pointstroyhunt118 comments

Hey Troy, Thought you might be somewhat interested in this one. Remeber the cool guys over at http://www.realestate.com.au/ Just to refresh your memory..

https://twitter.com/#!/realestate_au/status/2207319148043059...

Anyway, "we are aware of this issue and are working on it".

Click http://www.realestate.com.au/ then "Register".

Then stand in utter amazement at their solution.

-------------------------------------------

Why do we need your email address?

     *We send your password via email.*
     *Your email address is your log on.*
     *If you forget your password, we'll send you a new one.*

-------------------------------------------

This is hilarious. I can only assume that they took offence to you choosing a "strong version" password, so they decided, how can we fix this? I know, lets just pick the password for them.

So, their fix that they told you about, was to ensure that you can't pick a password at all, and they will still email you their "super strong version password"...

> Thank you for registering. Your password has been sent to username[at]gmail.com. It should arrive shortly.

12 seconds later.

Your password is: DTCNE

(In case people aren't aware, realestate.com.au is owned by HomeAway)

In slight defense of that horrible password practice:

You can't really do much with a realestate.com.au account unless you are an Agent (which is a separate account). There's no payment processing, or any way to add content to the site. The accounts there are basically just a way to save common realestate searches as far as I can tell.

Yeah, no.

All private user information is equally private. To arbitrarily suggest that certain data is less important is a dangerous road to walk down. We should be holding everyone to the same standards when it comes to security.

This is especially true with the high amount of password reuse that goes on.

I'm not sure I agree. I'd say my name is private, I'd say my date of birth is more private, I'd say my medical conditions are more private still. There are clearly degrees of privacy.

Does it really make sense to hold my bank to the same standard as a real estate website? Sure they should all reach some minimum requirement (salted and hashed passwords), but I expect my bank to have far higher standards (e.g. two factor auth) than a a random site.

The problem with storing passwords insecurely is that people reuse them. You can try to tell them otherwise as much as you like, they will do it, so even if one service holds non-sensitive data, stealing the password will grant access to other, completely unrelated services.

Yeah that was overly simplistic.

I guess the issue is that the layman cannot really tell how secure a solution is, and so are unlikely to be able to make well reasoned decisions about the information they release. As such there really needs to be a far greater level of responsibility placed on people who hold the keys so to speak. Once again this is especially true since people re-use (and use overly simple) passwords at a scary rate. By not protecting their information on a crappy real estate website you are potentially leaving open their bank to abuse.

I feel instances like these just show dangerous levels of incompetence and a blatant disregard for user's information. Good solutions generally require less work anyway so there's no excuse.

This is clearly not true, or HIPPA would apply to my street address, and sites that want my phone number would have to be PCI compliant.

PCI compliance is an industry standard, not a regulatory standard, so it's not a valid comparison. Also, PCI compliance isn't for privacy reasons, it's for loss mitigation.

Amusingly enough, the banks who impose PCI compliance on merchants aren't themselves required to be PCI compliant, and some of them will happily e-mail you extremely sensitive customer data (no matter how many times you ask them not to), even though doing so yourself would violate PCI compliance.

All realestate.com.au are trying to do is give the user a persistent session registered to their email address. Think of it as kind of like a cookie which you can easily transfer between browsers to get a slightly more personalised experience.

> This is especially true with the high amount of password reuse that goes on.

I do agree that it is a bit off (read: probably illegal) that they allow users to change the password and then store the user's password in plaintext. The system would be considerably better if users could only use a system-generated password.

Actually, you do a lot with them; I could take a significant portion of them and log on to the account holders' Twitter / Facebook / GMail. Reuse is rampant and anyone who holds credentials has a duty of care to protect them.

Do you know who else does this? The US Department of Labor when you register/reset/change your password with the PERM system.

I don't mind the emailing of a new password for password reset requests. It seems just as secure as the password change link that most sites use. It does have the potential to be more annoying to the user if other people are submitting fake password reset requests though, which is why I'd still go with the password change link.

Well, let's look at the good side of it. At least it limits the risks of password reuse.

You don't know that for sure. For all we know, they email "DTCNE" to everybody.

As far as I know, realestate.com.au is not owned by Homeaway.com - its listed on the ASX under REA Group http://en.wikipedia.org/wiki/REA_Group

Agreed, HomeAway does NOT own realestate.com.au (so says my friends at homeaway when I forwarded them this comment).

They POST forms unencrypted. And either they don't have an HTTPS version of the site, or it's broken.

Several pages that do this:

(Search for "We send your password via email")

https://www.google.com/webhp?sourceid=chrome-instant&ie=...

I've given someone I know at REA a heads-up; hopefully he'll have the clout to fix it.

In other news it's not just REA. I checked and my ISP (TPG) does the same :-(

This is a hilarious, albeit depressing, view of the state of cyber security as seen by the general public. People, even those who are generally considered computer literate, don't have any understanding of web security. Due to this, Tesco won't hit any negative publicity outside of a tight knit circle of programmers. In fact, saying that everything is "stored securely" according to "industry standards" would reassure most people.

There have been many calls in past exploit threads for a name and shame policy, but that won't do anything. Name and shame only works when people keep up with the list, and people won't. They're too busy with their lives to focus on a list, especially given the number of insecure websites around the world.

We need everyone to have a list of easy to remember rules about web security from a consumer perspective. This list of rules needs to reach everyone. Putting them in the browsers may lead to the exposure needed, but I don't see that happening.

This primitive level of education needs to start breaking through as it's only going to get worse as computing and security advance further. We haven't even finished explaining to people that plain text passwords almost always indicate impending disaster, yet we already need a way to explain MD5 is never enough and SHA256 isn't enough without a salt...

If only Google Chrome would start warning users on signup that their password would be stored in plain text.

Google Chrome and the Google search engine warn you if a website contains malware or is suspected of phishing. Poor security is just as dangerous as these, the only thing missing is the malicious intent.

Unfortunately, Google would likely open themselves to lawsuits if they warned users away from or penalised websites due to poor security.

It's a sad reflection of the state of things that we worry Google would be subject to lawsuits for trying to guide users away from almost-certain disaster, yet no one is naive enough to believe that a lawsuit could result from storing my password for an online shopping site in plaintext.

> that we worry Google would be subject to lawsuits for trying to guide users

um no, it's Google that would worry. Myself, I don't care if they got a lawsuit. I'd applaud G for trying (and who knows the publicity that such a lawsuit would (hopefully) generate might do some additional good).

I can imagine Google not pursuing such a strategy without a really good reason, though.

Poor security is just as dangerous as these, the only thing missing is the malicious intent.

Really? This password storage isn't great, but using tesco.com is hardly the same as visiting a malware or phishing site.

Unless/until Tesco have their databases hacked or stolen there is no risk at all.

Poor security references far more than just poor password storage, but even poor password security by itself becomes a serious issue incredibly quickly. Most people re-use passwords and most passwords are reset by email, meaning a leaked password and email address combo can quickly lead to massive damage.

Not all security exploits require a database to be hacked either. Even if a database is hacked, half the time we're finding out about this from third party sources well after the fact instead of the companies released press releases themselves.

These things happening silently is horrific[1]. Malware or phishing sites are relatively easy to spot and defend against -- but what about a compromised but legitimate website? If I find a security hole and pick a small but high quality selection of targets, how long will it take authorities (if ever) to piece together that they all were members of CornerStore Online?

[1]: We still have no idea when Twitter lost their 6.5 million password hashes -- they probably don't either... http://news.ycombinator.com/item?id=4074510

We still have no idea when Twitter lost their 6.5 million password hashes

Twitter or LinkedIn?

Oops - I meant LinkedIn! I have no clue how that slipped into Twitter.

Unfortunately I can no longer edit, hopefully the link itself is self explanatory.

Unless/until Tesco have their databases hacked or stolen there is no risk at all.

This is not the case. The most glaring reason why was pointed out in the posted article. It very clearly showed that Tesco failed to communicate logged-in state information (stored in a cookie) between the client and server over an encrypted line. This means your account is vulnerable to attack without the entire db being leaked.

Yes, a phishing site needs to trick me, and a malware site needs to get through my browser sandbox, and any anti-virus software I might have installed. I site with poor security (and a large user base) can be assumed to give my information to the first script kiddie that asks for it.

Don't be ridiculous.

A conditional statement saying there is no risk is utter nonsense. The reason for this is very simple - there is always a risk the conditional has already been fulfilled.

More than depressing I consider this to be a reality check. Procedures must be put in place for people who can't be expected to deal with this kind of thing properly.

> There have been many calls in past exploit threads for a name and shame policy

There is an attempt at naming and shaming here: http://plaintextoffenders.com/

I'm bothered that that blog doesn't distinguish between sites that (A) email generated passwords for new accounts and sites that (B) email plaintext passwords for existing accounts.

After looking at that site I find it hard to tell if they are receiving the password they entered in the email or a randomly generated password on account creation. If the password is a generated, typically "temporary" password, there is no real indication of it being stored in plain text then.

Maybe the solution is for a 'white hat' hacker to hack them, send them an email (oh btw here's the usernames and passwords of thousands of your customers). That might light a fire under their ass.

Edit: And publicly blog about it to shame them into action.

While nice, it would be trivial to send you to prison for doing that: https://en.wikipedia.org/wiki/Computer_Misuse_Act_1990#The_C...

I put it down to training more than anything. I bet Tesco haven't offered any of their development staff a structured (possibly external) training course on web security.

While training your staff won't solve all your security problems, I still think it'll help mitigate a lot of them.

What's really weird to me is how some people can foster an actual anti-security mindset, where they explicitly try to argue against proper security practices. I don't know where it comes from, but i've seen it often.

You report that the way a particular type of SSL cert is implemented leaves a MITM attack, and they come back with a dissertation on why MITM is not a concern of ours. (Oh? Then why the fuck are we encrypting the connection?!)

You tell them that they have unpatched, years-old, remote root vulnerabilities in their servers, and they give you the long list of reasons why we not only don't need to patch it, patching it would be bad.

You tell them how storing a password unhashed will lead to a PR catastrophe when an attacker gets your PW DB. They tell that implementing scrypt isn't feasible, bcrypt is weaker than scrypt, SHA1 hashes are easily crackable, and that if somebody has our PW DB we have bigger problems, so we shouldn't even worry about the passwords. And since we shouldn't worry, we might as well e-mail them.

My guess is they think it will be extra work and they're trying to avoid it. The alternative that I hope isn't true is that their egos are so big they don't want to believe they did something insecurely, so they craft a story to tell themselves and others that actually what they did was smart. Either way, the users lose out in the end, and there's nothing we can do about it.

I've seen exactly this attitude multiple times with clients from a wide range of industries. So much so that I'd say that this is attitude towards security is the norm rather than the exception.

Oh yes. Exactly this. It's infuriating!

I watched this exchange occur over Twitter on the weekend; the worst part of it was not that Tesco stores the password in a reversible manner, but that their representative actively defended their mechanism.

Otherwise, all of their other "crimes" (cookies are sent unencrypted, etc) are bad but not really unexpected from a large chain like this. I'm never really surprised when large organisations get these things so wrong, given the way many either contract this work out and/or [mis]handle it in-house.

If it was the weekend, it seems unlikely to me that the person running the Twitter account would have got in touch with someone with a technical understanding of how the site works. More likely they just consulted their list of talking points and picked the ones that looked most relevant to the situation.

On the other hand, the sensible thing to do would be to say something like “Can you provide your contact details in a DM: we’ll get one of our tech guys to contact you on Monday”

Yes, definitely. Having customer service respond to security complaints on Twitter really isn't very smart.

This is the dilemma with customer service in big companies. They get too many queries so they just hire someone who knows nothing but how to make up official sounding responses to finish their day at work and go home.

I discovered this a couple of years ago and emailed and got an unsatisfactory response:

http://pastebin.com/C745weQ2

Hopefully this new attention will have them change the policy.

So they actually say the passwords are not encrypted in that email, which is quite different to what they say on twitter. I wonder if they're using a reversible encryption now, or (perhaps more likely) they just don't know what they use.

They have a maximum length requirement. That's a red flag which suggests they are just storing it plaintext.

> In fact the only real possibility that leaves any credibility whatsoever is that the stored password is being decrypted then compared to the password provided at logon using a non-case sensitive comparer.

You can do case-insensitive passwords with hashing/salting. It's just a matter of lower-casing the password before hashing it. (Edit: I'm not saying this is a good idea, of course!!)

I remember reading once that Facebook actually hashes multiple versions of your password (eg with the first letter upper-cased to handle the case where a phone auto-corrects it, and also with all character cases toggled to handle the case when you left caps lock on). I wonder if there's any statistics about how often this kind of thing actually helps?

Of course, it seems pretty clear in this particular case that Troy is right and they're just storing your password in a case-insensitive database column.

If you want hash based passwords to be case insensitive (or have case insensitive characters) You should convert the case before you hash on login. Saving every hash makes it easier for an attacker to find a collision.

Does it really? What matters is NUM_POSSIBLE_KEYS / NUM_SAVED_HASHES, saving hashes for multiple casings of the password can't possibly increase the number of hashes by more than lowercasing the password would decrease the keyspace by.

You're right, I was thinking that the attacker didn't know the publicly available information that passwords were case insensitive. However, I would still be concerned that it unnecessarily increases the chances to exploit some weakness in the hash algorithm.

>Facebook actually hashes multiple versions of your password (eg ... when you left caps lock on).

Detecting if capslock is on with javascript (in a round about way) would seem to be a much better solution for this case.

The plain text password thing might have been an edict come down from marketing.

For example, they might find that people who forget their password become less likely to use the site because when they get their new (hard to remember) password emailed to them they can't figure out how to change the password back to what it used to be. This means they end up resetting their password every week to do their shopping.

But... a proper password reset mechanism wouldn't send the password via email in first place, but rather a one-time link to set a new one.

True, but perhaps they find 0.5% of users get confused by that screen and that 0.5% represents several million £ in revenue.

And imagine how much being hacked affects revenue!

I don't doubt, though, that some sort of similar short-sighted thinking led to this decision. Is it really possible that such a large organization simply doesn't understand password policy? Not to mention, an organization that's on the board of PCI-DSS?

Possibly not that much, as long as their security is good enough that they don't get sued.

At the point where you are worrying about hashed passwords, your system has already been owned.

It also depends on public reaction to the incident, people won't necessarily blame tesco either and blame the "1337 chinese super h4x0rs"

As someone who was once an inexperienced web dev, I bet this probably didn't come down from marketing, and instead is the result of inexperienced/uneducated developers.

It boggles my mind that this is STILL happening. How many leaked databases of plain text passwords, not to mention 'point and shoot' tools like firesheep, will it take before companies start taking security seriously?

Yes it's possible they two way encrypt their passwords, but that's still not as secure as salted hashes, not to mention all the other security blunders.

You can two-way encrypt your password (even with hashes, and repeated rounds). And you can even make it as secure as hashes, if you keep the decryption key offline, on paper, in a safe. (So no: We send your password to you via email, if you forget it.)

Of course, you shouldn't do it, unless you have a good reason. E.g. There was talk a few months ago about a new law being proposed in France requiring companies to provide the police with user passwords.

Whilst I agree with the big one about plain text passwords some of the niggles here seem a little odd.

Tesco are not advising that everyone goes back to IE 3, they are simply stating this as a lowest common denominator since I'm assuming that was the first browser to support whatever version of TLS they were using etc.

Also, is running an old version of ASP.NET and IIS really a problem? Does he advocate going through the expense of rewriting/retesting the entire website every time MS drops a new version? If they are pulling down security patches this should be a non issue.

The post advocates simply staying reasonably up to date, then says that IIS 6 is unreasonably old. relevant bit:

This is not necessarily a high-intensity exercise, once every few years you simply make sure you haven’t fallen too far behind the eight ball. Certainly you don’t let key software components get 9 years old and nearly 5 versions out of date.

This is quite a bit less intensive then you describe and I think it's reasonable to expect that a website taking payments not be more the a couple years out of date.

IIS 6 is part of Windows 2003 Server, therefor it will be on "Extended Support" until 14/07/2015

http://support.microsoft.com/lifecycle/search/default.aspx?a...

This means that if there is some security vulnerability discovered with it then Microsoft will provide a patch, therefor from a security point of view it isn't "out of date".

The number of years and versions is fairly irrelevant, there will be plenty of very secure systems in use by banks and the military that will no doubt pre-date much of what tesco is using by several decades.

The relevance is that none of the additional protections added to the technologies are available. We're in a very different threat landscape today than what we were in 9 years ago and the technologies provide advances to better protect ourselves. If you're using them!

Why rewrite? When there's a new major feature release, take the opportunity to change the target framework. Most servers also have a refresh cycle so update that at the time and roll it into the testing procedure. I'm not saying do this immediately after every new IIS / .NET release, but going 9 years without change is risky.

And yet, they have a very clued up technology department led by Nick Lansley, which many years ago opened up a public API to access to Tesco online shopping.

Yes, I get the impression he is somebody who cares, so probably a good place to start for anyone who wants to see this fixed:

http://www.blogger.com/profile/00087509895945257528

Big company with lots of silos, as far as I can tell. Can't talk too much, since they are one of our customers.

I don't think it's fair to expect a customer service representative to understand the issue here. Maybe it might be better to go through Tesco's corporate arm? I just tried submitting something through the feedback form on the front page of Tesco.com, perhaps this has a better chance of reaching somebody in a position to actually do something about it.

I totally agree, which of course is why they shouldn't be commenting on it! But regardless of the Customer Care's Twitter account, their messaging is consistent with the misunderstandings demonstrated throughout the website.

Tesco have a technology blog that might be worth going through:

http://techfortesco.blogspot.com/

Doesn't some of this fall afoul of PCIDSS? (In particular, leaking information about the webserver's configuration).

I've just bought a Thinkpad from Lenovo via their website. They're doing the same infuriating thing.

    > Dear ****,
    > Thank you for contacting us on Lenovo Outlet.
    > The password you requested is: ******
    > Please note: This e-mail message was sent from a
    > notification-only address that cannot accept
    > incoming e-mail. Please do not reply to this message.
    > Sincerely,
    > Customer Service

Tesco can live without geek business. You'd think a company like this would care though. They send it in plaintext when you sign up too.

How about Ajaxian? They're ONLY geeks, and yet do the same thing.

These are all big problems, but one incredibly common security anti-pattern out there that I never see talked about are the "security questions" that so many websites use to let you reset your password.

It's amazing: a website will make me choose an 8-character (but not more than 14!) password with a number, a symbol, and at least one capital and one lowercase letter, but then it will let anyone who knows my birthday and favorite color change that password to whatever they like.

(Obviously, I can opt out of this feature by typing gibberish into those answer fields, but do you think your grandfather will think to do that?)

One variation that I know of that you can't opt out of it is on some banks' two-factor authentication, where they have you log in by answering a security question first, and then entering your password once you get the question right. The great thing about this is that it makes the bank an easy test-ground for guessing your security questions to use on other sites.

Usually the way this works (or should work) is that you answer the security question and then it emails you a new password.

The reason for the security question is to prevent people who don't know you from being able to lock you out of your account. Of course this doesn't work so well if the person knows who's account it is and can find the answers to security questions online.

The most common implementation is to require to reset a password via a link sent in the email (and only then you answer security questions), which solves the particular problem you describe.

That has thankfully become more common recently, but many smaller sites never caught on.

Shocking stuff. Given the level of ignorance on display here, the size and political clout of Tescos and the detailed summary of possible attack vectors presented by Troy, is there a chance he could be fitted up for 'hacking' charges? What worried me was his trace.axd request: it's definitely using a computer system in a way it was not intended, which has caused problems for other security researchers in the UK in the past.

Just commenting quickly over breakfast but if I find the time later I'll try to look up the cases. (I remember something about a kid ending up in court for using relative paths to explore a web server (/content/../../ etc.)

Thank God there's still Waitrose.

It's fun to bash on the most recent security naiveté, but can someone explain why GNU Mailman still emails users' passwords after subscribing?

Mailman warns users that passwords will be mailed plaintext, but why mail passwords to begin with?

Because nobody has patched it. Go there, download the source, write a patch, submit it.

For accounts that I use rarely and have a low cost even if compromised, I prefer convenience over security.

As mailman has a fairly technical audience and reminds users that passwords are stored/sent in plaintext, I see it as a feature, not a bug.

Great analysis except I'm puzzled by his claim about trace.axd -- is it really a security risk that tracing is enabled, given that it can only be accessed from the local machine?

Depending on the configuration, it can be accessed from a remote computer. In this case, it was configured for localhost access, however it is entirely possible that it could be world-accessible.

Right... that's like saying "The root password was strong, however it is entirely possible that it could be an empty string."

Fortunately, someone on the main article did respond that having trace.axd enabled could result in 500 errors dumping a stack trace. That's a much clearer argument for why having tracing enabled is a bad thing.

I think the point is that it exposes information about the server, like the headers he mentions.

This is an entirely baseless accusation, but I have my cynical hat on today. I'm wondering if the cost to provide the additional customer service that could be involved in helping people deal with stronger security (password reset email, reset pages and confirmations etc) has been weighed against the cost of upgrades and reparation for account breaches, and influenced the decisions here.

I think it's safe to assume that they outsourced this aspect of their online service, given the quality of the copy in some of the pages.

Tesco are fundamentally in the business of selling meat and potatoes to everyone in the UK, not of making highly-secure websites.

This does not excuse this lapse, but it may help us understand why if a computer system seems to work fine, they have little motivation to replace, upgrade or fix it, even if it is running on an old version of the platform.

They are a huge online retailer in the UK, that should automatically mean their website is highly secure. It has my address and credit card details in it!

> They are a huge online retailer in the UK, that should automatically mean their website is highly secure.

You'd think so, but apparently that's not how it's working out.

Well, no, we all know it doesn't work like that. I just wanted to point out that Tesco are doing more than just selling "meat and potatoes", their online services are a huge offering, and they provide credit cards, insurance, phone plans... Tesco online isn't just there for people to "like" their favourite potatoes!

Tesco are third or second largest retailers in the world (measuring by revenues or profits); they led the world in online sales for years; they were early entrants into online sales (being, I think, involved in the first ever online sale); they offer some financial services.

They have the money to pay for expertise to do better.

It is a shame that "it hasn't failed yet" is seen by them as an excuse to keep a broken system in place.

> Tesco are fundamentally in the business of selling meat and potatoes to everyone in the UK

That is changing - it is getting to the point where their business angle is more "renting shelf space to brands" as much as selling what we want to buy (that is a general industry thing, not a Tesco specific comment).

Even ignoring that cynicism, their business is far more than food and I suspect the food sales are dwarfed when you add everything else together. Food is just the product that gets us through the door to see the other stuff: meat, veg, bread and milk are the things that the rest of the occupants of large shopping centres tend to lack.

> not [in the business] of making highly-secure websites.

On the contrary: they are taking in and storing personal details and in some cases banking details (they sell banking services as well as physical products), and getting access to your account may give someone the ability to buy things on your credit card. It is my understanding that both by law and by the agreements they have in place with their chose credit card processing partners they are required to live up to certain security expectations, and if they do not live up to those expectations they should be investigated, fined, and stopped from trading in those ways until they are up to scratch.

The claim that their password storage is "up to industry standards" is both unduly vague (though as the conversation was by tweet the length limitation there may be partly to blame for that) and simply wrong. They are not compliant with PCIDSS (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...) which I believe is considered the industry standard for handling credit card data or accounts that are associated with it.

Good answer. The problem is the mismatch between the business that they think they're in and the business that they are becoming.

However I am not finding anything about "you may not store passwords in plain text or using reversible encryption" in that PCIDSS wikipedia link. If it is part of the standard (as it should be) then it deserves to be in the wikipedia article.

I may be confusing it with other standards that we had to ensure we were compliant with on a project a couple of years ago.

Even if it isn't in PCIDSS, not storing passwords securely is certainly not industry practice for any company that operates as a bank in any of its parts.

I can understand why they do this, sort of, but I can't understand how they have this mindset in the first place.

Imagine if they let criminals run riot through their stores, on the theory that they're in the business of selling meat and potatoes to everyone in the UK, not of policing stores. Well, it's true, but putting their customers at risk is wrong and bad for business.

No, this web site nonsense hasn't been bad for business... so far. I wouldn't be surprised if a major breach would change that in a hurry, though.

… and then he goes and recommends 1Password, a closed-source “security” software. Yes, I’m one to talk, I’m using the OS X password manager. But I wouldn’t recommended it in a security blog.

Sadly, 1Password is probably the best solution there currently is. But this only shows how abysmal the current state of affairs is for security.

This reminds me of "Our security auditor is an idiot. How do I give him the information he wants?"

--> http://serverfault.com/questions/293217/our-security-auditor...

Have anyone seen this? :-)

I really wished there was a bigger followup to this story, including if PCI allowed them to continue with this clueless "security audit"

I think this is a common trait of many large businesses. Recently I reset my Virgin Media password, only to receive an email with my password in plaintext right there.

I considered writing / emailing but didn't think it would do much good.

Reminds me of the banks with their "enter the first and fourth characters of your password"-type enhanced login forms. How are they doing that without storing the plaintext, then?

Technically they could encrypt the password and then just put the 1st and 4th password in a separate column in the db.

Not sure if that happens in practice...

Perhaps when you set the password it generates a bunch of combinations of password chars that might ask you to enter and then hash these. Of course that does make them more exploitable because you can leak information about the password 1 or 2 characters at a time.

However your bank will have so much information stored about you that if your bank gets owned you're basically fucked anyway even if they don't get your password.

I imagine the servers that actually store this data however are secure to a ridiculous degree.

I know Halifax at least uses a separate string for those checks, which presumably is stored unencrypted.

You know a technical blog post was interesting and informative when it spawns 5+ tabs of other articles and Google searches on the topic!

See

http://news.ycombinator.com/item?id=4312128

I'm interested to know what everyone's take on the "use https always for everything" stance is. Does any site actually follow that rule? Even big names like facebook allow you to use http don't they? And what about the "don't put http elements in an https page"? Why not? What benefit is sending the images over https (thus making the page load slower) if they are on a seperate subdomain, so there's no cookies being sent with those requests?

>(thus making the page load slower)

The difference is tiny. If your images are on the same domain as the html, you'll have no extra overhead from the ssl handshake (thanks to http keepalive), and the symmetric encryption used in an existing ssl connection will have a negligible impact on performance.

I can think of two reasons you want https, even for just images:

1) Even though modifying an image in flight will probably not have major security implications, you can't be sure. Perhaps a carefully edited and resized image could alter the layout of a form, tricking the careless user into publishing information they didn't mean to.

2) Perhaps your adversary is just a teenager bothering people trying to be productive at a coffee shop. Including a 10000x10000 image that makes the page unusable, or replacing your logo with porn isn't exactly something you want, even if it doesn't compromise anybody's bank account.

HTTP keepalives just means you only need to negotiate two extra SSL connections instead of n (n being the number of images in the page). The overhead of that is certainly noticeable. If there's no actual benefit, then it shouldn't be in his list of "stuff you have to do (and nobody actually does)".

But for most websites, it is something you have to do. Ruining the layout of your page is about as bad as any other DoS attack for most of the afflicted users.

GMail is a good example of HTTPS everywhere.

When you embed HTTP elements you can no longer trust their authenticity. If, for example, you load JS into your banking app over HTTP it would be possible for a man in the middle attack to substitute it with a script which could re-write the page or siphon off sensitive data.

HTTPS says "We can verify the site you're connecting to and all data transited between it and yourself is encrypted". Embedded HTTP content invalidates that premise.

I know what HTTPS is, I am asking why it matters in this specific context. We're not talking about javascript, we're talking about images. Nobody cares if the images are being sent securely, do they? From a random sampling, it sure doesn't look like very many https sites serve up https images. My current plan for our upcoming site launch is also to serve up images over http, not https. Is there an actual reason not to do this, or is it just "its on my list so do it"?

Any idea why so many sites allow http after logging in? I realize a facebook account isn't a high value target, but it seems crazy that a site that size works over http. I imagine they must have some reason to support http (not implying it has to be a good reason).

Well actually, we are talking about JavaScript, 5 separate .js files actually.

The challenge comes back to the fact that "Secure" in an HTTPS context is an absolute; either everything is loaded over HTTPS and you get a shiny padlock or it's not and you get a red cross (depending on the browser, of course). The browser itself obviously cannot discern what the developer feels should be loaded over a secure channel and what should not nor is there anything in the HTML/HTTP spec to support this (other than HSTS to force HTTPS).

The simple reason not to serve up HTTP content on an HTTPS page is that rightly or wrongly, the browser will tell your users that your site can't be trusted. I understand your point, but that's the implementation you'll find in the browsers of today.

Facebook is definitely a high value target, just ask a Tunisian who was using it early last year: http://www.thetechherald.com/articles/Tunisian-government-ha...

Not having HTTPS everywhere by default (although at least it's now a configurable option) is extremely serious for a site like Facebook. The fallout from governments monitoring political dissidents is just one example, the potential harvesting of personal information (including connections) is another that's closer to home. Remember Firesheep? http://en.wikipedia.org/wiki/Firesheep

Why doesn't Facebook force it everywhere? Perception of processing overhead (although debunked by Google), integration impact with non-HTTPS content (impact on ads has long been claimed as a barrier), re-engineering of one of the world's largest sites, etc. But it's heading in the right direction, Twitter, Facebook and Hotmail, for example have all made positive steps forward, I'm sure we'll see a much greater prevalence of HTTPS as time progresses.

Re: images over HTTPS; most of the attacks involve an active MITM, so it's a question of how seriously you take that threat. Usually, most people ignore this scenario until it gets automated via "coffee shop network attack tools" like firesheep or sslstrip.

As a practical matter, if you embed http images in your HTTPs page I believe you will get mixed content warnings in some browsers. See e.g: http://stackoverflow.com/questions/3278341/help-with-ssl-vul...

Another strike against non HTTPs images is that if you don't have the 'secure' flag set on your cookies, these may get sent with requests, compromising your users' sessions. I guess you could consider not setting this cookie flag as a separate issue. Note that this is a passive threat, exploitable via sniffing.

Thirdly, an active MITM can return any MIME type in response to your <img src> link; you now have to be 100% sure that no browsers will try to process a malicious response of any type when it gets one instead of an image. Probably OK, but are you absolutely 100% sure? What about indefinitely, as browsers implement new features?

Fourthly, think about all the creative ways a malicious user could embed instructions or change the appearance of your site by substituting arbitrary image content. Also note that SVGs can run javascript. One could change an image to be an ad or promotion, for example, to convince the user to carry out an action.

I wouldn't neccesarily follow facebook's lead on security practices.

Modern thinking is that if you care about SSL at all, you should force SSL for everything. For example if your "secure banking site" has an HTTP landing page, an active MITM will just sslstrip the customers and get them to enter their password in the wrong box.

This is why we have HSTS (HTTP Strict Transport Security) header, and why sites that care deeply about security (gmail, paypal, lastpass, etc) use it. (See http://www.chromium.org/sts).

I'll just leave this here... It's rather indicative of their general idea of "Security". Stumbled across this a number of years ago, told them about it, it's still wide open.

http://www. preprod.tescoentertainment. com/Store/Browse/Home/

Reply on news.ycombinator.com