Lessons in website security anti-patterns by Tesco • Hacker News Board

Re: Lessons in website security anti-patterns by Tesco

#91

Post by danudey » Mon, Jul 30, 2012, 5:05 PM UTC

sp332 wrote: post #46

jrsimmons wrote: post #36

Earlier quoted context omitted.

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.

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.

Re: Lessons in website security anti-patterns by Tesco

#92

Post by papsosouid » Mon, Jul 30, 2012, 6:17 PM UTC

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?

Re: Lessons in website security anti-patterns by Tesco

#93

Post by bmj » Mon, Jul 30, 2012, 6:22 PM UTC

jiggy2011 wrote: post #61

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.

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.

Re: Lessons in website security anti-patterns by Tesco

#94

Post by freditup » Mon, Jul 30, 2012, 6:32 PM UTC

legutierr wrote: post #43

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

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.

Re: Lessons in website security anti-patterns by Tesco

#95

Post by tbrownaw » Mon, Jul 30, 2012, 6:34 PM UTC

gizmo686 wrote: post #77

codeka wrote: post #26

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

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.

Re: Lessons in website security anti-patterns by Tesco

#96

Post by praxulus » Mon, Jul 30, 2012, 7:30 PM UTC

papsosouid wrote: post #92

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

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

Re: Lessons in website security anti-patterns by Tesco

#97

Post by papsosouid » Mon, Jul 30, 2012, 7:37 PM UTC

praxulus wrote: post #96

papsosouid wrote: post #92

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

>(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 prob…

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

Re: Lessons in website security anti-patterns by Tesco

#98

Post by gizmo686 » Mon, Jul 30, 2012, 8:17 PM UTC

tbrownaw wrote: post #95

gizmo686 wrote: post #77

Earlier quoted context omitted.

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.

Re: Lessons in website security anti-patterns by Tesco

#99

Post by troyhunt » Mon, Jul 30, 2012, 8:36 PM UTC

lengarvey wrote: post #20

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

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.

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.

Re: Lessons in website security anti-patterns by Tesco

#100

Post by troyhunt » Mon, Jul 30, 2012, 8:42 PM UTC

papsosouid wrote: post #92

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

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.