[OT] Security question

[Rich Osman]

Chris,

I compliment you on your succint and accurate summary of the issue.

Sounds like Frank's ISP is aspiring to be the next Yahoo...

On December 22, 2016 4:33:52 AM CST, Chris Angelico <rosuav at gmail.com> wrote:
>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
>-- 
>https://mail.python.org/mailman/listinfo/python-list

-- 
mailto:oz at ozindfw.net    
Oz
POB 93167 
Southlake, TX 76092 (Near DFW Airport