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

81–90 of 120 posts

Re: Lessons in website security anti-patterns by Tesco

#81

Post by jiggy2011 »

metachris wrote: post #80
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.

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.

Re: Lessons in website security anti-patterns by Tesco

#82

Post by skue »

alastairpat wrote: post #56
skue wrote: post #53

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.

Re: Lessons in website security anti-patterns by Tesco

#83

Post by polshaw »

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…

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

Re: Lessons in website security anti-patterns by Tesco

#84

Post by Sottilde »

jiggy2011 wrote: post #81
metachris wrote: post #80

Earlier quoted context omitted.

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?

Re: Lessons in website security anti-patterns by Tesco

#85

Post by bct »

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/

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.

Re: Lessons in website security anti-patterns by Tesco

#86

Post by jiggy2011 »

Sottilde wrote: post #84
jiggy2011 wrote: post #81

Earlier quoted context omitted.

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"

Re: Lessons in website security anti-patterns by Tesco

#87

Post by kyrra »

albahk wrote: post #50
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. ----------------------------------------…

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

Re: Lessons in website security anti-patterns by Tesco

#88

Post by h2s »

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.

Re: Lessons in website security anti-patterns by Tesco

#89

Post by paulgb »

AncientPC wrote: post #33

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?

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.

Re: Lessons in website security anti-patterns by Tesco

#90

Post by web007 »

h2s wrote: post #88

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

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