[Link Posting] Another day, another breach: At what point does storing passwords in plaintext become criminally negligent?

[Rich]

####################################################################
# ATTENTION: This post is a reference to a website. The poster of #
# this Usenet article is not the author of the referenced website. #
####################################################################

<URL:https://www.privateinternetaccess.com/blog/2018/04/another-day-anot
her-breach-at-what-point-does-storing-passwords-in-plaintext-become-crim
inally-negligent/>

The third largest breach ever in Finland happened yesterday. Passwords
were stored in plaintext. At T-Mobile Austria, they explain that of
course they store the password in plaintext, but they have so good
security so it's nothing to worry about. At what point does this become
criminally negligent?
News of the Finnish breach (Google Translate) arrived yesterday, and
while there isn't a lot of details, we learn two important things: the
leak was relatively big (the third largest in Finland), and cleartext
passwords with usernames leaked, because they had hundreds of thousands
of passwords stored in cleartext.
... and they had passwords stored in cleartext.
This is so bad security, it should not exist anywhere, period. It should
not even be taught in a coding class as an intermediate step on the way
to how to do it the right way.
1) You don't need to store a password in cleartext to check it against a
new input of the same password. You use something called a salted hash
of the password, which means that you scramble it in a one-way method
that it can't be unscrambled, but the scrambled result can be compared
to a second scramble with the same method of the typed password (and if
they match, it was the same password to begin with).
2) The leak of a plaintext password can be catastrophic for the user
concerned, and the possibility of an external or internal breach must
always be taken into account. No matter how small the possibility, if
the consequences are big enough, we need to take precautions.
...

[Marko Rauhamaa]

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

2) The leak of a plaintext password can be catastrophic for the user
concerned,

That's true in the case of bots as well but hard to avoid.


Marko

[Huge]

Post by Marko Rauhamaa

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than just
bunging it in a database and hoping for the best.

[Marko Rauhamaa]

Post by Huge

Post by Marko Rauhamaa

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

What other means do you have in mind? The system should be able to
reboot without human intervention.


Marko

[Huge]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

:-O

Post by Marko Rauhamaa
What other means do you have in mind?

Depends on how important it is. For less important systems, I used to use
secret splitting to store it,

https://en.wikipedia.org/wiki/Secret_sharing

for the more important, an HSM.

https://en.wikipedia.org/wiki/Hardware_security_module

[Marko Rauhamaa]

Post by Huge

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

:-O

Post by Marko Rauhamaa
What other means do you have in mind?

Depends on how important it is. For less important systems, I used to use
secret splitting to store it,
https://en.wikipedia.org/wiki/Secret_sharing
for the more important, an HSM.
https://en.wikipedia.org/wiki/Hardware_security_module

I still don't get it. How does a bot authenticate itself without human
intervention?

An example: a build server. It needs authorization to access source
code. For that, it needs to be authenticated in a way that cannot be
spoofed. The build server needs to possess some secret information
which, if it should leak out, will make it possible to spoof the server.

Instead of a file, you could store the secret in memory, but if the
system should crash, it would need to recover autonomously and retrieve
the secret from a persistent store of some sort.


Marko

[Rich]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

:-O

Post by Marko Rauhamaa
What other means do you have in mind?

Depends on how important it is. For less important systems, I used to use
secret splitting to store it,
https://en.wikipedia.org/wiki/Secret_sharing
for the more important, an HSM.
https://en.wikipedia.org/wiki/Hardware_security_module

I still don't get it. How does a bot authenticate itself without human
intervention?

A 'bot' (defined as an intended automated login, not a 'web scraper
bot' or the like) should not be using password auth. in the first
place. A 'bot' should be using public/private keys (i.e., ssh keys) to
authenticate itself.

[Huge]

Post by Rich

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

:-O

Post by Marko Rauhamaa
What other means do you have in mind?

Depends on how important it is. For less important systems, I used to use
secret splitting to store it,
https://en.wikipedia.org/wiki/Secret_sharing
for the more important, an HSM.
https://en.wikipedia.org/wiki/Hardware_security_module

I still don't get it. How does a bot authenticate itself without human
intervention?

A 'bot' (defined as an intended automated login, not a 'web scraper
bot' or the like) should not be using password auth. in the first
place. A 'bot' should be using public/private keys (i.e., ssh keys) to
authenticate itself.

Quite, but that isn't always possible.

[Marko Rauhamaa]

Post by Rich
A 'bot' (defined as an intended automated login, not a 'web scraper
bot' or the like) should not be using password auth. in the first
place. A 'bot' should be using public/private keys (i.e., ssh keys) to
authenticate itself.

A private key is a password (ie, a secret), and needs to be stored in
the clear for the bot to be able to use it.


Marko

[Huge]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa

1) You don't need to store a password in cleartext to check it
against a new input of the same password.

No, but you do need a cleartext password to authenticate a bot, a
commonplace situation in a lot of automated setups.

And there are multiple means of doing that, all of them better than
just bunging it in a database and hoping for the best.

I just put it in a file in the clear.

:-O

Post by Marko Rauhamaa
What other means do you have in mind?

Depends on how important it is. For less important systems, I used to use
secret splitting to store it,
https://en.wikipedia.org/wiki/Secret_sharing
for the more important, an HSM.
https://en.wikipedia.org/wiki/Hardware_security_module

I still don't get it. How does a bot authenticate itself without human
intervention?

You need to store the password, but just putting it in a file and relying
on O/S filesystem protections is, IMNHO, insufficient. So, I used to
specify that the password should be split into 'n' parts, using one of
the algorithms in the Wiki article above, and those parts stored in
disparate parts of the system, e.g. one part in the database and one
in a configuration file (and not labelled "password"!) That way, there's
nothing obvious to search for, even if someone does screw up the filesystem
protections.

[Marko Rauhamaa]

Post by Huge

Post by Marko Rauhamaa
I still don't get it. How does a bot authenticate itself without
human intervention?

You need to store the password, but just putting it in a file and
relying on O/S filesystem protections is, IMNHO, insufficient. So, I
used to specify that the password should be split into 'n' parts,
using one of the algorithms in the Wiki article above, and those parts
stored in disparate parts of the system, e.g. one part in the database
and one in a configuration file (and not labelled "password"!) That
way, there's nothing obvious to search for, even if someone does screw
up the filesystem protections.

So security through obscurity.

The simplest way to scramble the secret is to bake another secret in the
authenticating executable binary itself. I have practiced that, too, but
the reverse engineering hurdle is nowhere near the level of real
cryptography.


Marko

[Huge]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
I still don't get it. How does a bot authenticate itself without
human intervention?

You need to store the password, but just putting it in a file and
relying on O/S filesystem protections is, IMNHO, insufficient. So, I
used to specify that the password should be split into 'n' parts,
using one of the algorithms in the Wiki article above, and those parts
stored in disparate parts of the system, e.g. one part in the database
and one in a configuration file (and not labelled "password"!) That
way, there's nothing obvious to search for, even if someone does screw
up the filesystem protections.

So security through obscurity.

Oh, indeed. Beats the crap out of no security through putting it in a
file.

Post by Marko Rauhamaa
The simplest way to scramble the secret is to bake another secret in the
authenticating executable binary itself.

Thereby making it difficult to change.

[Marko Rauhamaa]

Post by Huge

Post by Marko Rauhamaa
The simplest way to scramble the secret is to bake another secret in
the authenticating executable binary itself.

Thereby making it difficult to change.

On the other hand, I/O sources are trivial to eavesdrop using strace.


Marko

[Huge]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
The simplest way to scramble the secret is to bake another secret in
the authenticating executable binary itself.

Thereby making it difficult to change.

On the other hand, I/O sources are trivial to eavesdrop using strace.

Why would you have strace installed on a production machine?

[Marko Rauhamaa]

Post by Huge

Post by Marko Rauhamaa
On the other hand, I/O sources are trivial to eavesdrop using strace.

Why would you have strace installed on a production machine?

The intruder can install it and patiently roam around and diagnose the
system.

The question is, how do you protect your secret against an intruder who
has broken in with root access?


Marko

[Richard Kettlewell]

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
On the other hand, I/O sources are trivial to eavesdrop using strace.

Why would you have strace installed on a production machine?

The intruder can install it and patiently roam around and diagnose the
system.
The question is, how do you protect your secret against an intruder who
has broken in with root access?

There’s a variety of approaches to making root less powerful.

Still, a sufficiently powerful attacker may take complete control of the
system, whatever that means in context. But being able to imagine a
hypothetical all-powerful attacker doesn’t make it pointless to mitigate
threats from the less capable real ones.

For example, when it comes to secret credentials, one of your risks is
unauthorized access to secret data at rest, not just on the running
system but after theft or disposal, on backup tapes, in source code,
etc. So you use some strategy for getting the credentials off the disks
of application hosts and into centrally managed storage - which may
still have a similar chicken-and-egg problem at reboot, but now you only
have one instance of that problem, rather than one per application.

[Huge]

Post by Richard Kettlewell

Post by Marko Rauhamaa

Post by Huge

Post by Marko Rauhamaa
On the other hand, I/O sources are trivial to eavesdrop using strace.

Why would you have strace installed on a production machine?

The intruder can install it and patiently roam around and diagnose the
system.
The question is, how do you protect your secret against an intruder who
has broken in with root access?

There’s a variety of approaches to making root less powerful.
Still, a sufficiently powerful attacker may take complete control of the
system, whatever that means in context. But being able to imagine a
hypothetical all-powerful attacker doesn’t make it pointless to mitigate
threats from the less capable real ones.

(Phew, someone's got more patience than I do!)

Post by Richard Kettlewell
For example, when it comes to secret credentials, one of your risks is
unauthorized access to secret data at rest, not just on the running
system but after theft or disposal, on backup tapes, in source code,
etc. So you use some strategy for getting the credentials off the disks
of application hosts and into centrally managed storage - which may
still have a similar chicken-and-egg problem at reboot, but now you only
have one instance of that problem, rather than one per application.

E.g., a HSM, as I mentioned at the beginning of this.

[Huge]

Post by Rich
####################################################################
# ATTENTION: This post is a reference to a website. The poster of #
# this Usenet article is not the author of the referenced website. #
####################################################################
<URL:https://www.privateinternetaccess.com/blog/2018/04/another-day-anot
her-breach-at-what-point-does-storing-passwords-in-plaintext-become-crim
inally-negligent/>

The third largest breach ever in Finland happened yesterday. Passwords
were stored in plaintext. At T-Mobile Austria, they explain that of
course they store the password in plaintext, but they have so good
security so it's nothing to worry about. At what point does this become
criminally negligent?

It already is. Hopefully they will be prosecuted about 90 seconds after
the GDPR starts.

[Sylvia Else]

Post by Huge

Post by Rich
####################################################################
# ATTENTION: This post is a reference to a website. The poster of #
# this Usenet article is not the author of the referenced website. #
####################################################################
<URL:https://www.privateinternetaccess.com/blog/2018/04/another-day-anot
her-breach-at-what-point-does-storing-passwords-in-plaintext-become-crim
inally-negligent/>

The third largest breach ever in Finland happened yesterday. Passwords
were stored in plaintext. At T-Mobile Austria, they explain that of
course they store the password in plaintext, but they have so good
security so it's nothing to worry about. At what point does this become
criminally negligent?

It already is. Hopefully they will be prosecuted about 90 seconds after
the GDPR starts.

Perhaps you're thinking of article 32.

https://gdpr-info.eu/art-32-gdpr/

But it's written in vague terms. I think any decent lawyer would manage
to get an acquittal for their client if the only failing was storing
plaintext passwords.

The regulator needs to bite the bullet and prescribe salted hashes (and
specify the hash algorithm and length) as the mechanism for storing
passwords.

Sylvia.

[Huge]

Post by Sylvia Else

Post by Huge

Post by Rich
####################################################################
# ATTENTION: This post is a reference to a website. The poster of #
# this Usenet article is not the author of the referenced website. #
####################################################################
<URL:https://www.privateinternetaccess.com/blog/2018/04/another-day-anot
her-breach-at-what-point-does-storing-passwords-in-plaintext-become-crim
inally-negligent/>

The third largest breach ever in Finland happened yesterday. Passwords
were stored in plaintext. At T-Mobile Austria, they explain that of
course they store the password in plaintext, but they have so good
security so it's nothing to worry about. At what point does this become
criminally negligent?

It already is. Hopefully they will be prosecuted about 90 seconds after
the GDPR starts.

Perhaps you're thinking of article 32.

TBH, I'm not thinking of anything specific. I'm retired, and no longer
care very much about cyber security, other than as a user. Except to sigh
and shake my head head when these fuckwit stories crop up, and think that
perhaps we were better at this stuff than we gave ourselves credit.

Post by Sylvia Else
https://gdpr-info.eu/art-32-gdpr/
But it's written in vague terms. I think any decent lawyer would manage
to get an acquittal for their client if the only failing was storing
plaintext passwords.
The regulator needs to bite the bullet and prescribe salted hashes (and
specify the hash algorithm and length) as the mechanism for storing
passwords.

I much prefer regulators to prescribe *outcomes*, rather than methods. That
way, one can use whatever's the best currently available. If they do it
your way, and something better comes along, one ends up using an inferior
method for legal reasons.

[Richard Kettlewell]

Post by Sylvia Else

Post by Huge
It already is. Hopefully they will be prosecuted about 90 seconds
after the GDPR starts.

Perhaps you're thinking of article 32.
https://gdpr-info.eu/art-32-gdpr/
But it's written in vague terms. I think any decent lawyer would
manage to get an acquittal for their client if the only failing was
storing plaintext passwords.

They would have to persuade the judge that password hashing was not an
appropriate technical measure, in the face of an entire industry that
believes it necessary and considerable practical evidence supporting
them. I would not want to be that lawyer.

Post by Sylvia Else
The regulator needs to bite the bullet and prescribe salted hashes
(and specify the hash algorithm and length) as the mechanism for
storing passwords.

I’d rather regulation leave scope for doing better than the minimum
required and for responding to new attacks faster than the regulator
does. You shouldn’t be discouraged from using scrypt just because the
regulator has only heard of PBKDF2, as a (non-hypothetical) example.

[Computer Nerd Kev]

Post by Rich
<URL:https://www.privateinternetaccess.com/blog/2018/04/another-day-anot
her-breach-at-what-point-does-storing-passwords-in-plaintext-become-crim
inally-negligent/>

The third largest breach ever in Finland happened yesterday. Passwords
were stored in plaintext. At T-Mobile Austria, they explain that of
course they store the password in plaintext, but they have so good
security so it's nothing to worry about.

I'm in full agreement that there's no excuse for storing passwords in
plain text, but I do sometimes worry about the opposite situation,
where overall security is allowed to slip slightly because of the
secure knowledge that "all the passwords are encrypted anyway".

I get this impression from the way some companies respond when there
is a data leak, often playing heavily from the angle of "it doesn't
really matter because they'll never figure out your password". This
really gives me the irks because I have a different password for
every account, and I'll change it after the leak, so the password
is actually the least important bit of information that the hackers
could have obtained.

Am I meant to be reassured by the fact that it could have been so
much worse if I'd been an idiot?