steve+comp.lang.python at pearwood.info
Sun Jan 18 03:37:54 CET 2015
Albert van der Horst wrote:
> In article <h9gqob-c3e.ln1 at esprimo.zbmc.eu>, <cl at isbd.net> wrote:
>>Michael Torrie <torriem at gmail.com> wrote:
>>> On 01/17/2015 07:51 AM, Albert van der Horst wrote:
>>> > In article <mailman.17471.1420721626.18130.python-list at python.org>,
>>> > Chris Angelico <rosuav at 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
>>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
> 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
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
- 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
- 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
More information about the Python-list