Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons in website security anti-patterns by Tesco

troyhunt.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Lessons in website security anti-patterns by Tesco

#111

Post by troyhunt »

papsosouid wrote: post #104
troyhunt wrote: post #100

Earlier quoted context omitted.

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 your…

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 t…

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: Lessons in website security anti-patterns by Tesco

#112

Post by qxcv »

jrsimmons wrote: post #36
lengarvey wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: Lessons in website security anti-patterns by Tesco

#113

Post by damncabbage »

Smerity wrote: post #38
omh wrote: post #31

Earlier quoted context omitted.

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'…

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

Twitter or LinkedIn?

Re: Lessons in website security anti-patterns by Tesco

#114

Post by mistercow »

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.

Re: Lessons in website security anti-patterns by Tesco

#115

Post by jiggy2011 »

mistercow wrote: post #114

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…

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.

Re: Lessons in website security anti-patterns by Tesco

#116

Post by obiterdictum »

mistercow wrote: post #114

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…

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.

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.

Re: Lessons in website security anti-patterns by Tesco

#117

Post by mistercow »

obiterdictum wrote: post #116
mistercow wrote: post #114

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…

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. 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)…

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

Re: Lessons in website security anti-patterns by Tesco

#118

Post by path411 »

SideburnsOfDoom wrote: post #35
Smerity wrote: post #9

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…

> 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/

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.

Re: Lessons in website security anti-patterns by Tesco

#119

Post by Smerity »

damncabbage wrote: post #113
Smerity wrote: post #38

Earlier quoted context omitted.

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'…

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.

Re: Lessons in website security anti-patterns by Tesco

#120

Post by duncan_bayne »

chrisacky wrote: post #14

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. ----------------------------------------…

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 :-(

Post reply on HN