Albert van der Horst wrote: > In article <h9gqob-c3e....@esprimo.zbmc.eu>, <c...@isbd.net> wrote: >>Michael Torrie <torr...@gmail.com> wrote: >>> On 01/17/2015 07:51 AM, Albert van der Horst wrote: >>> > In article <mailman.17471.1420721626.18130.python-l...@python.org>, >>> > Chris Angelico <ros...@gmail.com> wrote: >>> > <SNIP> >>> >> >>> >> But sure. If you want to cut out complication, dispense with user >>> >> accounts altogether and run everything as root. That's WAY simpler! >>> > >>> > I didn't except this strawman argument from you. >>> > Of course you need a distinction between doing system things as >>> > root, and working as a normal user. You just don't need sudo. >>> >>> I just don't see the distinction. What's the difference between having >>> to type in a root password and having to type in your own administrative >>> user password? Guess we're all just struggling to understand your logic >>> here. >>> >>One big distinction is that you need to know two passwords to get root >>access if there's a real root account as opposed to using sudo. This >>only applies of course if direct root login isn't allowed (via ssh or >>whatever). > > The other is that if a dozen users have sudo possibility, one compromised > password compromises the whole system. The same administrators that like > sudo will force the users into a "safe" password of at least 8 characters > a special sign a number and a capital, instead of educating them to > use a strong password like the_horse_eats_yellow_stones. 1]
Sigh. I like XKCD, I really do, but anyone who thinks that brute force attacks cannot simply replace words for characters is deluding themselves. Consider a password like "mg93H$8s". Each character is taken from an alphabet of lowercase and uppercase letters plus digits, plus 32 punctuation characters and other symbols available on a US keyboard. There are 26+26+10+32 = 94 different "letters" in this alphabet. If your password is ten characters long, there is a potential pool of 94**10 available passwords. Let's say we strip out 90% of them for being "too easy to guess" (say, eight "A"s in a row, or it happens to contain your username). That still leaves us with: 94**10//10 = 5386151140948997017 potential passwords. Now consider the XKCD scheme. You pick four words from a dictionary and concatenate them. On my system, /usr/share/dict/words has a little less than 500,000 words. The problem is, most of them are not really memorable, and many of them are very low entropy. Here's a selection from the first few starting with A: A A. a a' a- a. A-1 A1 a1 A4 A5 AA aa A.A.A. AAA aaa AAAA So in practice people are going to choose words from a much, much smaller selection. I estimate that most people are going to choose words from a pool of about 10,000 words or so, but let's imagine that you have four times the vocabulary (or imagination) of the average person and pick from a pool of 40,000 words, specially crafted to avoid low-entropy selections such as "AAA A4 aa a". That gives: 40000**4 = 2560000000000000000 potential passwords, half that of the conventional scheme. And if people have biases in the words they pick -- and you better believe they will -- that will be reduced even further. Password crackers will take advantage of the fact that most XKCD-style passwords will include at least one of the most common thousand or so words, reducing the search space significantly. I believe that the state of the art of password cracking is such now that people cannot realistically expect to remember sufficiently strong passwords for all the things they need passwords for. I believe that the only good solution is to have one strong passphrase that you use to protect a password manager, which in turn uses long (12 character or more), completely random passwords. Even that doesn't protect you, because your security is controlled by websites and banks etc. with stupid security policies. E.g. I am forced to deal with one bank that uses a cryptographic key to sign in to their bank, but your passphrase is limited to exactly eight characters. Another bank I use limits you to SIX characters, taken from case-insensitive(!) letters, digits, and a small set of punctuation. At least they do enforce rate limiting on account logins: three wrong login attempts and they lock your account and force you to go to a branch in person to recover it. (Can you say "Denial Of Service Attack"? I can.) > Compare that to > "Dear administrator, I've to do this. Can I have the root password." > "Sure here it is" Looks over users shoulder. "Are you ready?" > Make sure he's logged out. Uses random generator for a new password. That is a ridiculously impractical system for anything other than a home system. Problems include: - You have a single point of failure, the one administrator who controls access to the root password. The day he stays home with his phone switched off to play WOW is the day the mail server dies and you need root to fix it. The "Bus Factor" (what do you do when the administrator gets hit by a bus?) is critical. - You might be changing the root password dozens of times a day; if you have to restore your system from backup, chances are nobody will know what the root password was this time two days ago. - Lack of accountability: somebody used the root account to delete files they're not supposed to. Who was it? No idea, it was somebody with root, which could mean anyone who could have come up with a sufficiently plausible excuse to convince the trusted admin to give them root access that day. With sudo, all commands are logged, and even if the sudoer runs "bash" to defeat the logging, it is obvious that they have done so and can be asked to explain why they shouldn't be fired for breaching company policy. - Completely impractical for big sites. Imagine Google, with tens of thousands of machines, and thousands of administrators across multiple timezones, if they all had to go through a single admin to request the root password. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
