
Knuddels: Chat platform must pay after hacker attack fine - MSeven
http://www.tellerreport.com/tech/--knuddels--chat-platform-must-pay-after-hacker-attack-fine-.S1xs7l4Am.html
======
kodablah
I see this is based on a Spiegel article. Can someone link to the full ruling?
One thing I am curious about is how the number was derived.

Regardless, even if you disagree with the scope of the law (which I do but not
the intent of course), it is a very welcoming sign to see some actual
enforcement happening. An under/subjectively enforced law of this size is much
worse than a reasonably enforced one.

~~~
lorenzhs
Here's the Data Protection Officer's press release (in German):
[https://www.baden-wuerttemberg.datenschutz.de/lfdi-baden-
wue...](https://www.baden-wuerttemberg.datenschutz.de/lfdi-baden-wuerttemberg-
verhaengt-sein-erstes-bussgeld-in-deutschland-nach-der-ds-gvo/) \- the
relevant paragraph is towards the end. The tl;dr is that the fine is rather
low because they were very cooperative and quick to follow suggestions for
improvement, and have additional improvements planned. Also, they likely
couldn't afford more, and the goal of GDPR fines is not only to be effective
and a deterrent, but also proportionate. The DPO says that including the cost
of IT security measures taken and planned, the total expense for Knuddels is a
six-digit figure.

~~~
nf05papsjfVbc
I think the cost of complying with the law is just cost of conducting a
business lawfully. So, those parts should not be spoken of as if they were
part of the damages.

~~~
lorenzhs
Well obviously they should have improved their security practices years ago.
Nonetheless, they incurred the costs now, as a result of self-reporting a data
breach (which is mandatory). That's the number that's relevant as a deterrent
for others, so I think it's fine to report it this way.

------
dorianm
Full list of 5000+ websites that store their passwords in plain text:
[https://github.com/plaintextoffenders/plaintextoffenders/blo...](https://github.com/plaintextoffenders/plaintextoffenders/blob/master/offenders.csv)

~~~
invisiblea
That list is very out of date. One of my clients appears on there and when we
took over in 2012 we encrypted all their user credentials.

~~~
whyever
Their FAQ [1, 2] suggests that using an encrypted password still warrants an
entry.

[1]
[http://plaintextoffenders.com/faq/devs](http://plaintextoffenders.com/faq/devs)

[2] [http://plaintextoffenders.com/faq/non-
devs](http://plaintextoffenders.com/faq/non-devs)

------
tyingq
_" Knuddels is safer than ever."_

Corporate speak is just so funny. The bar for "safer than ever" is pretty low
when your dev team hasn't heard of password hashing.

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

~~~
tyingq
_" 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...](https://www.archynety.com/tech/why-knuddels-saved-his-passwords-in-
plain-text/)

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

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

~~~
tyingq
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...](https://forum.knuddels.de/ubbthreads.php?ubb=showflat&Number=2916515#Post2916515)

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

------
ronreiter
This is actually a cool idea - paying idiot tax

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

~~~
pbhjpbhj
€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 issues addressed. Why address security, just pay the much smaller
fine if you ever get caught ...

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

~~~
lorenzhs
Well, the fine is only 20k€ because they were very cooperative, quick to fix
the worst issues, and promised to continue improving their security further.
According to the Data Protection Officer's statement their total expenses were
in the six figures. They also explicitly state that the fine wasn't higher as
not to place a disproportionate burden on the company's finances, which
probably means that they wouldn't have been able to afford a significantly
higher fine. Contrary to the fear-mongering on this site, the purpose of GDPR
isn't to fine companies out of existence.

~~~
pbhjpbhj
Yes, I saw that elsewhere when I'd finished writing.

More cooperative still would be doing the changes before you're caught.

If you could skip your tax bill for a few years, but get a much smaller fine
if you cooperated when caught then you'd be silly to actually pay.

In short, in terms of _pour encourage les autres_ this fails badly IMO.

~~~
AnthonyMouse
> If you could skip your tax bill for a few years, but get a much smaller fine
> if you cooperated when caught then you'd be silly to actually pay.

If you do the work ahead of time, you pay the cost of doing the work. If you
wait for the fine, you pay the cost of doing the work plus the fine. It
doesn't take a lot of fine to make doing the work to begin with worth it --
basically just accounting for chance of getting away with it and time value of
money, which goes _down_ as the government gets better at catching more people
quicker, as should be their primary goal for something like this.

~~~
pbhjpbhj
Maybe, but there's much more work that needs doing to secure PII than just not
having plaintext passwords. So, they can seemingly avoid doing all that work
too, and maintaining those systems (with staffing costs). And you get a leg-up
over the competition who can't use the cash that they put in to security.

That means those with poor security regimes may "win" because the costs of
poor PII hygiene are externalised.

It would certainly be nice to imagine all the 2 million UK corporations are
addressing PII security rather than hiding and hoping not to get a fine ...

~~~
AnthonyMouse
> Maybe, but there's much more work that needs doing to secure PII than just
> not having plaintext passwords. So, they can seemingly avoid doing all that
> work too, and maintaining those systems (with staffing costs).

If the regulators catch someone breaking a rule like this, the consequence
should obviously involve an audit that looks for other violations and requires
them to fix those too.

But even if it didn't, your conclusion wouldn't follow, because they would
still have no incentive to fix the other problems unless they expected to get
caught for not fixing them. But if they did expect to get caught then the
numerous predicted small fines would be a sufficient deterrent.

> It would certainly be nice to imagine all the 2 million UK corporations are
> addressing PII security rather than hiding and hoping not to get a fine

It's the hiding and hoping not to get a fine that's the reason large fines
don't work. Higher penalties can't deter someone who doesn't expect to be
caught.

What works is smaller penalties with vigorous enforcement.

~~~
pbhjpbhj
Thanks for expounding your position, I still disagree however.

The analysis is similar to a parking fine, if the fine is €1 but parking is €2
per hour then people will chance it.

If the fine is having your car towed and €200 then people will be damned sure
not to go even a minute over their paid time.

~~~
AnthonyMouse
Parking fines aren't designed for deterrence, they're designed for revenue
generation. If parking is €2 and the fine is €1 on top of the parking cost if
you get caught (plus €5 worth of inconvenience doing fine paperwork), and
there is a 90% chance of getting caught, nobody parks illegally -- and
therefore there is no fine revenue.

But if you make it a $200 fine with a one in a thousand chance of getting
caught, then it's profitable, because then many people rationally take the
risk and become a source of citation revenue. But the violation rate is
higher, so if that was your goal, it fails -- unless you're still doing
vigorous enforcement, in which case high fines are once again unnecessary.

------
mark_sz
Maybe [https://www.plus.net/](https://www.plus.net/) should be next. Reported
few times without any result.

~~~
johnnyfaehell
Report for what? Storing plain text passwords?

~~~
mark_sz
Reported to them that it's not a good idea.

------
ru999gol
Seems like they got punished for informing the government about the hack,
obviously gives the next company that gets hacked a reason to try to hide it.

~~~
the8472
The fine was set low for cooperating with the DPO. If you hide it and someone
leaks it then the agency could ask for much more.

------
codeulike
I read the headline as saying that Knuddels was a platform for chatting about
GDPR, which made it all seem very ironic.

edit: title has been changed, nevermind

------
jeandejean
Funny to speak about security and a GDPR fine for a website that hasn't HTTPS
activated...

~~~
bausshf
I don't see much reason why their website should have HTTPS though.

There are no input fields, no requests sent with personal information at all
etc.

Everything that's questionable already comes over HTTPS on their site though,
like Facebook content etc.

------
pmontra
Attack, succeed and blackmail could become a business. "If you don't pay me X
we'll report you under GDPR and you'll have to pay much more."

~~~
claudius
"If you don’t pay me X we’ll report you under criminal law and you’ll have to
pay much more."

"If you don’t pay me X we’ll report you under environmental protection law and
you’ll have to pay much more."

"If you don’t pay me X we’ll report you under labour regulations law and
you’ll have to pay much more."

How would GDPR be special?

~~~
TomMarius
In the extreme large fines.

~~~
lorenzhs
They paid a 20.000€ fine. How is that extremely large?

~~~
TomMarius
I wasn't talking about this specific case. The regulation allows larger fines
than that, and some people fear that. I myself disagree with them, btw.

------
anotheryou
laughably little though (20k)

------
hnaj
According to the link: [https://www.baden-wuerttemberg.datenschutz.de/lfdi-
baden-wue...](https://www.baden-wuerttemberg.datenschutz.de/lfdi-baden-
wuerttemberg-verhaengt-sein-erstes-bussgeld-in-deutschland-nach-der-ds-gvo/)

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.

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

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

~~~
Someone
Store the length L of the password, its salted hash H, and its bytes, XOR-ed,
X.

For every message typed, compute a running XOR of each sequence of L bytes (2
XOR’s per character, so as good as free). Whenever it equals X (about once
every 64 letters or so, because typical text doesn’t use all bits in each byte
equally), compute the salted hash of the last L characters, and compare with
H.

Unicode and Unicode normalization will complicate that, but I think it should
be fast enough for a chat.

You probably can also improve on that factor 32 by storing multiple XOR-like
(but slightly more computationally expensive) hashes and computing multiple
running totals.

Given that this is to protect users from falling for scammers who claim they
need their password to help them, you may be able to run it on the user’s
machine.

I fear, however, that a scammer will just ask them to type their password with
a space inserted, spell it in the NATO spelling alphabet, or whatever. If you
fall for a scammer, that won’t stop you from giving them your password.

~~~
donaltroddyn
I did think of similar approaches, but anything I could think of that helps
you to quickly determine if a given string contains the password also helps an
attacker if the passwords and salts are compromised.

In the suggested case, storing the length of the password alone massively
reduces the search space, and storing the XOR (of the plaintext with the hash,
I think you're suggesting?) negates the value of using a hashing algorithm
suitable for passwords, since the point is that checking if a password matches
a hash is an expensive operation.

------
sbhn
Who gets the money, after those who administer it take there cut

~~~
Tomte
The state, Baden-Württemberg.

------
mirages
GDPR is not supposed to be enforced after a 2 year grace period ?

~~~
NewsAware
That 2 year grace period ended in May 2018

