[OT] Security question

[Chris Angelico]

On Thu, Dec 22, 2016 at 9:10 PM, Frank Millman <frank at chagford.com> wrote:
> What about the second part of my query? Is it acceptable that they keep
> passwords on their system in clear text?

Well no, absolutely not. I referred to "decrypting" the password,
which is all you can actually be certain of here - they may well be
storing the passwords in an encrypted form, but it can be decrypted.

> From my first encounter with Unix over 30 years ago I was impressed with the
> fact that no passwords are stored in clear text. Even with my own little
> accounting system, I only store the SHA-1 hash of the password. I cannot
> imagine why anyone would think that this is a good idea.

>From worst to best, here's some ways you can store passwords:

1) Clear text. If anyone even just glances at your database, it's game
over in one shot.
2) Reversibly encrypted. If someone gets your database, s/he can
decrypt the contents, but accidentally flashing a long string of
nonsense won't instantly reveal everything.
3) Encrypted with a key. To decode all the passwords, you would need
additional information. That might come from the code, or from
environment variables, or something, but you would need to attack
something other than the database to completely decrypt people's
passwords.
4) Unsalted hashes. Instead of storing "password", you store
"5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8". Can be broken with rainbow
tables (or for common passwords, just Google the thing).
5) Hashes salted with something predictable or calculable. Maybe you
hash username+"blargh"+password, or something. Means the hashes don't
look the same even for the same password.
6) Hashes salted with arbitrary data that then gets stored alongside
the password.

Any of the first three could give the phenomenon you describe. And
while the security is better on #3, it's still entirely vulnerable to
the "disgruntled employee" attack (someone on the inside with complete
information about the system).

The last three all look similar in the database, but #4 is vulnerable
to XKCD 1286 attacks, and even #5 has its vulnerabilities (for
instance, setting your password to the same thing as it's previously
been will set the hash to the same value). I would recommend the use
of #6, but if someone's using #5, I wouldn't hate on them too hard -
that's pretty secure.

> The ISP is MWEB, one of the biggest service providers in South Africa, with
> (I guess) millions of users.

Thanks. MWEB, listen up: you are betraying your users' trust. A data
breach could cost you dearly. Act *now*, before there is actually a
breach, and go and hash all your passwords. And, of course, change
your systems so you never need to send people their passwords.

> If this is the standard of security out there, it is no wonder we hear of so
> many attacks (and how many don't we hear of?)

There are definitely a lot of nasty attacks out there, but these days,
the most dangerous attacks are the social ones. It doesn't matter how
good your password policy is if people will click on links in spam
email and type their passwords into imitation login screens. It
doesn't matter how well you salt your passwords if people write them
down in insecure scribble pads. It makes no difference what you do on
the back end if your users sign up for new services and use the same
email address and password on them all. But here's the thing: social
attacks are under the control of the individual user; database attacks
are under the control of the central service. MWEB is responsible for
what they do with their users' passwords, even if some of those users
are vulnerable elsewhere.

ChrisA