Knuddels: Chat platform must pay after hacker attack fine • Hacker News Board

Re: Knuddels: Chat platform must pay after hacker attack fine

#61

Post by johannes1234321 » Thu, Nov 22, 2018, 3:37 PM UTC

pbhjpbhj wrote: post #51

johannes1234321 wrote: post #34

Earlier quoted context omitted.

The fine is small since they completely complied with all inquiries and took proper steps to inform users and improve security. Thus do what the actual goals is. Making money is no a goal of GDPR, but ensuring data safety.

Fines need to be extremely punitive to make the risk-reward analysis favour fixing security _before_ the company gets caught.

Even the threat of death penalty doesn't stop crimes.

True, if there is no punishment and a threat is teethless nobody acts on it (that's why the big GDPR outcry also came only this year after the two year introductory phase)

However if you have too high fines what happens s that companies try everything to hide the fault and lie to avoid the fines. Here a company complied to all things, improved security (which according to the data privacy agency let to six digit costs (while a question is how you measure this) - see other comments) and therefore got a low punishment.

The punishment also has another effect: It makes it clear that fines are being collected. If it were higher the Knuddels company would go to court and we'd have an example case only in two or more years.

The goal is to improve data safety. That goal was achieved.

Re: Knuddels: Chat platform must pay after hacker attack fine

#62

Post by ygra » Thu, Nov 22, 2018, 3:37 PM UTC

crummy wrote: post #58

Drakim wrote: post #46

Earlier quoted context omitted.

It's possible to do that without storing the passwords in plain text though! Run each word of the chat though the same hash+salt mechanism and compare to what you have stored.

If they allow whitespace in passwords I could imagine complexity issues though.

I thought the same, although such a filter would be intended to help out unknowing users who might give their password to a stranger. People who use passphrases may know enough to not do that in the first place.

It could however in general have a problematic side-effect if the password is a common word that could be guessed from surrounding context when censored that way. Something I'd find a lot more likely here than passwords with spaces.

Re: Knuddels: Chat platform must pay after hacker attack fine

#63

Post by folkrav » Thu, Nov 22, 2018, 3:37 PM UTC

heavenlyblue wrote: post #25

hnaj wrote: post #16

Earlier quoted context omitted.

I've looked at many of those Tumblr posts; most of them show that the website sends you a welcome email with your password in plain text, which is bad practice, but doesn't prove that the password is stored in plain text in the database.

But which proves that access to the website codebase will grant you access to those passwords.

It's a matter of storing it in plaintext or not, which any sane developer knows not to. The codebase will always have access to your plaintext password at one point or another, whether it's on signup before they hash and store it, or when you login before comparing hashes.

If someone has access to your codebase you've got bigger problems than plaintext passwords anyway.

Re: Knuddels: Chat platform must pay after hacker attack fine

#64

Post by donaltroddyn » Thu, Nov 22, 2018, 3:39 PM UTC

Drakim wrote: post #46

hnaj wrote: post #42

According to the link: https://www.baden-wuerttemberg.datenschutz.de/lfdi-baden-wue... They were doing this so they could filter out the passwords from chats (i.e. to make it so users can't give out their passwords to other users). Not saying this justifies it, but it's interesting.

It's possible to do that without storing the passwords in plain text though! Run each word of the chat though the same hash+salt mechanism and compare to what you have stored.

Assuming they're using a suitable hashing algorithm for passwords (ie, Argon2, bcrypt, scrypt, PBKDF2), this approach would be prohibitively expensive, especially for a chat platform, with presumably lots of messages.

Also, you probably can't just try hashing each word, since there could be whitespace and punctuation in the password text, so I think you'd have to hash all possible substrings of each message to be able to reliably catch passwords.

Obviously, though, they shouldn't have been storing them in plaintext.

Re: Knuddels: Chat platform must pay after hacker attack fine

#65

Post by kurtisc » Thu, Nov 22, 2018, 3:40 PM UTC

tyingq wrote: post #23

dorianm wrote: post #7

Full list of 5000+ websites that store their passwords in plain text: https://github.com/plaintextoffenders/plaintextoffenders/blo...

http://plaintextoffenders.com/post/4629405305/discovercardco... Ugh. A credit card company...really?

IME banks often have poor security. And why not? They managed to rebrand robbery as identity fraud.

Re: Knuddels: Chat platform must pay after hacker attack fine

#66

Post by tyingq » Thu, Nov 22, 2018, 3:41 PM UTC

dpwm wrote: post #60

tyingq wrote: post #55

Earlier quoted context omitted.

"Passwords were hashed as a hash in 2016, but the unchanged version of the passwords has been retained, so users can not filter their own password via our platform via a filter" https://www.archynety.com/tech/why-knuddels-saved-his-passwo... Which sounds odd. You could just hash/compare filter words. I'm guessing similar issues too, like "no salt" or "same salt for all passwords".

If you do password hashing properly, using a key derivation function, you shouldn't be able to do that filtering efficiently at all.

It just has to run once, at filter creation time. Disallow creation of the filter if your password is in it.

Note the quoted reason from Knuddles is different from what others are saying the reason is: "so users can not filter their own password via our platform via a filter"

Edit: Apparently, the posted articles on this are misquoting things. Here's the original company response: https://forum.knuddels.de/ubbthreads.php?ubb=showflat&Number...

It does appear they were screening all chat text for the user's password after all.

Re: Knuddels: Chat platform must pay after hacker attack fine

#67

Post by wpietri » Thu, Nov 22, 2018, 3:44 PM UTC

pbhjpbhj wrote: post #28

StavrosK wrote: post #3

Earlier quoted context omitted.

In my experience, this is mostly what the GDPR is. There is no excuse for storing plaintext passwords in 2014+ and 20k is a fair fine for a mid-size company.

€20k doesn't seem much to me. Cheaper than taking on a security consultant. Not that you need a security consultant to know passwords shouldn't be stored (at all, nevermind plaintext). If they're doing that then they're likely being sloppy elsewhere, and by only paying €20k across the last n years they might have saved a €million. If your company is in the same boat probably worth not bothering to get any security is…

If bad security is a consciously chosen company strategy, then sure, the fine is too small.

But most places don't do dumb stuff like this because they've smartly chosen to be dumb. It's just thoughtlessness, just focusing on the wrong things. And one of those wrong things is "saving" money by being too cheap.

If a cheapskate client asked me to store passwords in plaintext on the theory they could save a few days of dev work, I'd love to be able to say, "Sorry, that's such a bad idea it's illegal. Fines start at €20k and go up." Their cheapness meter would swing into the red and they'd leave me alone.

If they company had actually chosen to be broadly negligent, it's clear the regulator could have imposed a much bigger fine, so I think your case is covered too.

Re: Knuddels: Chat platform must pay after hacker attack fine

#68

Post by daveFNbuck » Thu, Nov 22, 2018, 3:44 PM UTC

tyingq wrote: post #55

Double_a_92 wrote: post #40

Earlier quoted context omitted.

The passwords to login where actually hashed. But they stored another copy in plaintext on purpose, to censor the users password if they wrote it into chat...

"Passwords were hashed as a hash in 2016, but the unchanged version of the passwords has been retained, so users can not filter their own password via our platform via a filter" https://www.archynety.com/tech/why-knuddels-saved-his-passwo... Which sounds odd. You could just hash/compare filter words. I'm guessing similar issues too, like "no salt" or "same salt for all passwords".

What does filtering your own password mean on that platform?

Re: Knuddels: Chat platform must pay after hacker attack fine

#69

Post by usrusr » Thu, Nov 22, 2018, 3:46 PM UTC

pbhjpbhj wrote: post #28

StavrosK wrote: post #3

Earlier quoted context omitted.

In my experience, this is mostly what the GDPR is. There is no excuse for storing plaintext passwords in 2014+ and 20k is a fair fine for a mid-size company.

€20k doesn't seem much to me. Cheaper than taking on a security consultant. Not that you need a security consultant to know passwords shouldn't be stored (at all, nevermind plaintext). If they're doing that then they're likely being sloppy elsewhere, and by only paying €20k across the last n years they might have saved a €million. If your company is in the same boat probably worth not bothering to get any security is…

> I couldn't find Knuddels annual profit but they appear to have a dozen staff, which suggests to me the fine is too small.

On the other hand they seem to have at least as many open positions. This is either a sign of strong growth or a sign of inability to offer competitive pay. For a struggling pre-Facebook social web relic, it's easy to guess which one it is.

Re: Knuddels: Chat platform must pay after hacker attack fine

#70

Post by imtringued » Thu, Nov 22, 2018, 3:47 PM UTC

Arnt wrote: post #36

heavenlyblue wrote: post #25

Earlier quoted context omitted.

But which proves that access to the website codebase will grant you access to those passwords.

No. I've implemented precisely that and it doesn't prove what you think. What you do is have one single function create the user, pick a random password, set it in the database (which in my case uses a perfectly sensible hash) and send the user email. The cleartext password in the mail comes from the function's local string variable, not from the database. Whether doing this is a good idea is another question. IMO it…

What if the email with the plain text password is sent after a user pressed on the "I forgot my password button"? Because so far I only have encountered this type of email where the password is sent in plain text.