8 ms·

They should have been fined more than a measly €20k in my opnion. As a developer I'm deeply ashamed that people are still storing user passwords in plain text.

They should have been fined more than a measly €20k in my opnion. As a developer I'm deeply ashamed that people are still storing user passwords in plain text. There is no reason behind this behaviour what so ever, other than pure laziness ...

fredley 8y ago
Laziness implies you know the right thing to do but don't do it due to the extra effort. I'd put this more likely down to incompetence.
- da_murvel 8y ago
  So you think that someone who's capable of building a system like this, has somehow missed the fact that you should store passwords safely? Nah, I don't buy that.
  - fredley 8y ago
    I do. You do an online tutorial, and together with bits of code from Stack Overflow you can tie together APIs, including payment processing APIs relatively easily into what you want. You don't read the documentation, you just google till you get the code you want from SO, so any warnings in there are lost. Your boss is on your back about it and you're on your 4th straight 20 hour day, so you just do whatever to get the result your boss requires.
moviuro 8y ago
I'm sure that Orange (Telecom) does that as well for Consumer password. "Technical debt" probably. (My password was reset by something/someone, as it contained a '*'; when trying to set it anew, 'star' was a forbidden character...)
- fredley 8y ago
  I find this kind of error the most unsettling, it implies the people writing the authentication system don't trust the underlying ORM/database sanitisation layer (if there even is one!) enough, so to 'play it safe' they manually filter out 'suspicious characters'. It makes you wonder that if there's a team that isn't as rigorous elsewhere (or a team on which pressure has been applied to accidentally leave in some such 'mistakes') what kind of SQL injection possibilities exist.
  - MertsA 8y ago
    I was once doing some SEO work for a client and noticed something similar. Any URL that contained an apostrophe would return a completely blank page. I asked my manager if I could spend a little time investigating that as a security vulnerability that would have been out of scope for the project and within 45 minutes I had a working SQL injection proof of concept that would return credit card details from their order table. 1. They tried to prevent SQL injection attacks by stopping the page from loading instead of properly escaping data. 2. They failed to actually check if parameters had the forbidden characters they were looking for (they checked the URL, instead of the parameters after they were parsed so all it took was URL encoding an apostrophe) 3. They stored credit card details that they should have never recorded in the first place (including CVV code) rather than just storing the transaction ID from Authorize.net 4. They never bothered to archive old order data even though their ecommerce site didn't even have a customer login and they had absolutely no use for old orders after they were complete. If you spot that kind of incompetence on something inconsequential from a small team, dollars to donuts they're making the same kind of mistakes with far more serious code. And due to the Dunning-Kruger effect, they're probably too incompetent to realize that they shouldn't be touching anything related to i.e. payment processing or authentication.
Grumbledour 8y ago
When the breach was announced, they revealed that they did not store the passwords themselves in plain text, but had a second store that did, so they could prevent users from posting their passwords in chats. [0] Still stupid, but at least the had good intentions, just bad execution. [0] https://www.golem.de/news/datenleck-warum-knuddels-seine-passwoerter-im-klartext-speicherte-1809-136483.html https://www.golem.de/news/datenleck-warum-knuddels-seine-pas... (in german)
- contravariant 8y ago
  This just goes to show that badly designed security measures can be worse than no security measures at all.
- crazygringo 8y ago
  Huh, that's actually... a decent-sounding intention. Is there any way to do that in a secure manner? Because a hash says nothing about the length of a password (and you certainly don't want to store the length, which would make the attack space much smaller)... so if passwords are anywhere, say, from 8-64 characters, then for each chat message you'd need to hash every possible consecutive string of characters for every possible window size separately, which if the hash is even remotely computationally intensive could possibly turn into too much -- especially if being done on the server instead of the client (in order not to expose the hash and salt). Is this just something it's not possible to protect against?
  - y7 8y ago
    Easiest way is to do it on the client. The client has the plaintext password anyway.
    - crazygringo 8y ago
      Good point. But is storing a plaintext password, even on the client, good practice? E.g. in a browser that uses a cookie with something like a session ID to make sure you're logged-in... is storing a plaintext password in localStorage considered a valid security practice? I would have assumed not, although it's certainly not close to as bad as storing it on the server...

fredley 8y ago

Laziness implies you know the right thing to do but don't do it due to the extra effort. I'd put this more likely down to incompetence.

da_murvel 8y ago
So you think that someone who's capable of building a system like this, has somehow missed the fact that you should store passwords safely? Nah, I don't buy that.
- fredley 8y ago
  I do. You do an online tutorial, and together with bits of code from Stack Overflow you can tie together APIs, including payment processing APIs relatively easily into what you want. You don't read the documentation, you just google till you get the code you want from SO, so any warnings in there are lost. Your boss is on your back about it and you're on your 4th straight 20 hour day, so you just do whatever to get the result your boss requires.

moviuro 8y ago

I'm sure that Orange (Telecom) does that as well for Consumer password. "Technical debt" probably. (My password was reset by something/someone, as it contained a '*'; when trying to set it anew, 'star' was a forbidden character...)

fredley 8y ago
I find this kind of error the most unsettling, it implies the people writing the authentication system don't trust the underlying ORM/database sanitisation layer (if there even is one!) enough, so to 'play it safe' they manually filter out 'suspicious characters'. It makes you wonder that if there's a team that isn't as rigorous elsewhere (or a team on which pressure has been applied to accidentally leave in some such 'mistakes') what kind of SQL injection possibilities exist.
- MertsA 8y ago
  I was once doing some SEO work for a client and noticed something similar. Any URL that contained an apostrophe would return a completely blank page. I asked my manager if I could spend a little time investigating that as a security vulnerability that would have been out of scope for the project and within 45 minutes I had a working SQL injection proof of concept that would return credit card details from their order table. 1. They tried to prevent SQL injection attacks by stopping the page from loading instead of properly escaping data. 2. They failed to actually check if parameters had the forbidden characters they were looking for (they checked the URL, instead of the parameters after they were parsed so all it took was URL encoding an apostrophe) 3. They stored credit card details that they should have never recorded in the first place (including CVV code) rather than just storing the transaction ID from Authorize.net 4. They never bothered to archive old order data even though their ecommerce site didn't even have a customer login and they had absolutely no use for old orders after they were complete. If you spot that kind of incompetence on something inconsequential from a small team, dollars to donuts they're making the same kind of mistakes with far more serious code. And due to the Dunning-Kruger effect, they're probably too incompetent to realize that they shouldn't be touching anything related to i.e. payment processing or authentication.

Grumbledour 8y ago

When the breach was announced, they revealed that they did not store the passwords themselves in plain text, but had a second store that did, so they could prevent users from posting their passwords in chats. [0] Still stupid, but at least the had good intentions, just bad execution. [0] https://www.golem.de/news/datenleck-warum-knuddels-seine-passwoerter-im-klartext-speicherte-1809-136483.html https://www.golem.de/news/datenleck-warum-knuddels-seine-pas... (in german)

contravariant 8y ago
This just goes to show that badly designed security measures can be worse than no security measures at all.
crazygringo 8y ago
Huh, that's actually... a decent-sounding intention. Is there any way to do that in a secure manner? Because a hash says nothing about the length of a password (and you certainly don't want to store the length, which would make the attack space much smaller)... so if passwords are anywhere, say, from 8-64 characters, then for each chat message you'd need to hash every possible consecutive string of characters for every possible window size separately, which if the hash is even remotely computationally intensive could possibly turn into too much -- especially if being done on the server instead of the client (in order not to expose the hash and salt). Is this just something it's not possible to protect against?
- y7 8y ago
  Easiest way is to do it on the client. The client has the plaintext password anyway.
  - crazygringo 8y ago
    Good point. But is storing a plaintext password, even on the client, good practice? E.g. in a browser that uses a cookie with something like a session ID to make sure you're logged-in... is storing a plaintext password in localStorage considered a valid security practice? I would have assumed not, although it's certainly not close to as bad as storing it on the server...