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 <ros...@gmail.com> wrote: >On Thu, Dec 22, 2016 at 9:10 PM, Frank Millman <fr...@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:o...@ozindfw.net Oz POB 93167 Southlake, TX 76092 (Near DFW Airport -- https://mail.python.org/mailman/listinfo/python-list
