5 ms·

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think t

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html http://www.troyhunt.com/2012/07/lessons-in-website-security-...

nwh 14y ago
I emailed my ISP today to ask them why my password was being stored in plain text (and not even escaped) in a MySQL database. Their response was that everything was "working", so I didn't have to worry. Bear in mind, this is a company with my banking details. I have absolutely no expectation that it is going to be fixed either.
- devcpp 14y ago
  How do you know they do? That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.
  - nwh 14y ago
    Their tools truncated my changed password to 25 characters silently (first clue), their password reset tool emailed the plaintext password back to me (second clue), and their "api" endpoint errors out when I use special characters in my password (last clue).
claudius 14y ago
Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with hashes.
- eurleif 14y ago
  What users do is not necessarily the same as what they should do.
- EvilTerran 14y ago
  Users do reuse passwords, even if they shouldn't. Defence in depth.
  - claudius 14y ago
    > Defence in depth. Thanks.
- webignition 14y ago
  Firstly, an attacker with access to your backend database will have full access to user credentials if passwords are not salted and hashed. An attacker can then sign in as any user. The attacker may not be trying to steal all your have and may instead be looking to make life difficult for a single specific user. Secondly, users will reuse passwords. An attacker with access to the plaintext password and the user's email address can use this to try to gain access to other services. Thirdly, the attacker in the first example could be a disgruntled employee. You don't want a disgruntled employee causing trouble. Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen.
  - claudius 14y ago
    I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user. However, > Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen. sounds odd, since the user transmitted their password in clear text to the server at least once when registering, unless you use browser-side hashing/salting, in which case this hash would then take on the role of a password (i.e. wouldn’t help at all). Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.
WatchDog 14y ago
These companies likely have staff that already are acutely aware of the problems. It is sometimes very difficult to change anything from the inside, sometimes you need some negative PR to actually get the ball rolling.

nwh 14y ago

I emailed my ISP today to ask them why my password was being stored in plain text (and not even escaped) in a MySQL database. Their response was that everything was "working", so I didn't have to worry. Bear in mind, this is a company with my banking details. I have absolutely no expectation that it is going to be fixed either.

devcpp 14y ago
How do you know they do? That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.
- nwh 14y ago
  Their tools truncated my changed password to 25 characters silently (first clue), their password reset tool emailed the plaintext password back to me (second clue), and their "api" endpoint errors out when I use special characters in my password (last clue).

claudius 14y ago

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with hashes.

eurleif 14y ago
What users do is not necessarily the same as what they should do.
EvilTerran 14y ago
Users do reuse passwords, even if they shouldn't. Defence in depth.
- claudius 14y ago
  > Defence in depth. Thanks.
webignition 14y ago
Firstly, an attacker with access to your backend database will have full access to user credentials if passwords are not salted and hashed. An attacker can then sign in as any user. The attacker may not be trying to steal all your have and may instead be looking to make life difficult for a single specific user. Secondly, users will reuse passwords. An attacker with access to the plaintext password and the user's email address can use this to try to gain access to other services. Thirdly, the attacker in the first example could be a disgruntled employee. You don't want a disgruntled employee causing trouble. Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen.
- claudius 14y ago
  I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user. However, > Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen. sounds odd, since the user transmitted their password in clear text to the server at least once when registering, unless you use browser-side hashing/salting, in which case this hash would then take on the role of a password (i.e. wouldn’t help at all). Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.

WatchDog 14y ago

These companies likely have staff that already are acutely aware of the problems. It is sometimes very difficult to change anything from the inside, sometimes you need some negative PR to actually get the ball rolling.