On Wednesday 04 January 2012 11:58:07 Bennett Haselton wrote:
> If *everyone* used a 12-char random password, then the odds are that
> *none* of the 10 million machines attacking 100 million servers would
> hit on a success, not when there are 10^21 possible passwords to choose
> from.
It is too naive to identify the statement "something has very low probability"
with the statement "it will not happen".
There are processes in nature that have 1 / 10^21 (or any other) probability
of happening, but they are detected to actually happen every couple of seconds
or so (hint: ask any nuclear physicist).
In a security-related context, relying on low probability is always a risk
(regardless of how small), and it should be avoided if feasible. IOW, chances
of "10^<insert any number here> to one" are *infinitely* bigger than zero.
Proof --- divide that number by zero to find out how many times it is bigger.
;-)
You should never rely on any probability count if you have critical security
concerns. Yes, I also use a strong password rather than ssh key (mostly for
the same reason you do --- convenience), but I understand the risk of doing
so, I don't have any valuable data on the machine, and I never claim that any
password is as effective as a ssh key.
Btw, I am also one of the "lucky" people who managed to get hacked by ssh
brute-forcing. The password was as "random" as it can get, but the attacker
just got lucky (he didn't get root, though, just my user password, so I could
mitigate the damage). After that I installed fail2ban, but I still don't keep
anything valuable on that machine...
> >> However, *then* you have to take into account the fact that,
> >> similarly,
> >> the odds of a given machine being compromised by a man-in-the-middle
> >> attack combined with cryptanalysis of the stream cipher, is *also*
> >> overwhelmed by the probability of a break-in via an exploit in the
> >> software it's running. I mean, do you think I'm incorrect about that?
Are you basically saying that this is a premature optimization problem? If I
understand your argument correctly, some attack vectors are much more probable
than others, so guarding against a low-probability attack vector is
superfluous, given that there are more probable ones still unguarded. Is that
what you are saying here?
If yes, let me stress --- the premature optimization issue is *void* in a
security-related context. The main guideline is rather the "cover all bases"
principle. The fact that something is unlikely to happen does not mean you
should not guard against it, if you can. You may find the pain/gain ratio too
high sometimes, and you are welcome to ignore some obvious security holes for
the sake of convenience if you like, but you cannot argue that low-probability
holes are safe to ignore *in* *principle*. That is where the cover-all-bases
always wins over avoiding premature optimization.
> > The archives of this list already had the information about SELinux
> > contained in this thread. Not to mention the clear and easily
> > accessible documentation from the upstream vendor linked to from the
> > CentOS website.
> Well every one of the thousands of features and functions of Linux is
> indexed by Google on the web *somewhere* :) The question is whether
> you'll get pointed to it if you ask for help.
No, this is not the right question. SELinux is enabled by *default* in CentOS,
and for a good reason. You had to make a conscious choice to disable it, and
if you are security-aware admin, you should have *first* get yourself educated
on what you will lose if you do so.
So you were already pointed to SELinux (and iptables and some other stuff) by
the very fact that you installed CentOS. The real question is why did you
disable SELinux without looking at the documentation or asking on this list is
it useful for you?
If you are ignorant about security software to begin with, you have no right
to bitch about relevant information not being available at your glance.
> I didn't doubt that SELinux or iptables both do what they say they do,
> or that they reduce the risk of a break-in. My point was that other
> pieces of "lore" (like "ssh keys reduce the chance of a break-in more
> than 12-char passwords") have the potential to become part of "folk
> wisdom" despite not having been tested directly and despite not actually
> making any difference.
It's not folk wisdom. The probability of someone guessing your password is
nonzero (regardless of how small). The probability of someone "guessing" your
ssh key is still much smaller than that. There is an extremely big difference
there.
Both methods can be considered "reasonably safe", and at the same time "not
completely safe", but one *can* compare *relative* safeness, and conclude that
keys are much safer than passwords. Why do you think people invented keys in
the first place? Because they were too stupid to see see that a good password
is "good enough"? I doubt.
Again, it is the cover-all-bases principle.
> Yes, the totality of SELinux restrictions sounds like it could make a
> system more secure if it helps to guard against exploits in the services
> and the OS. My point was that some individual restrictions may not make
> sense.
There is a wrong premise here as well. The idea of SELinux is "if it is not
known to be safe/necessary, restrict it", regardless of whether that
restriction "makes sense" or not.
If some particular app is known to be safe to use a random port, it will still
be restricted because *in* *the* *future* the situation may change for the
worse (the app may introduce an unknown exploit via an update). SELinux guards
you against such situations, even if *now* there are no known exploits against
that app, and it doesn't make sense to restrict it. It may make sense in the
future, so it is again the cover-all-bases principle at work.
Security is all about being paranoid, and SELinux is paranoid by design.
Of course, if you have a need to change it's behavior, you also have the means
to do so. But it should be *your* decision, while the *default* setting should
be as paranoid as possible.
> Well yes of course an attacker can try *particular* 12-character
> passwords, I never said they couldn't :) And in this case the attacker
> stole the passwords by grabbing them en masse from a database, not by
> brute-forcing them.
You should also be aware that there is no such thing as "random in general".
Rather, there is only the "random with respect to"-type of randomness. Give me
any 12-character password that is "completely random" by any standards of
yours, and I will give you 10 guessing algorithms that will generate precisely
that password with just 1/1000 probability.
As ssh passwords get ever more "random" as perceived by users, the attacker
scripts will evolve more and more to become efficient at guessing precisely
those passwords. Exlcuding all dictionary-based passwords is just a first step
--- an algorithm can be "hardened" to be more and more effective in guessing
the passwords generated by some other algorithm (even against the "blindly
banging at the keyboard" algorithm). Its efficiency is of course never perfect,
but it can get much higher than you would expect.
Consequently, in the future there will be a race between the efficiency of
password-guessing algorithms and password-generating algorithms, for every n-
character class of passwords. This is a typical usecase of expert systems,
machine learning and AI in general (you may want to get informed a bit on
these topics). ;-)
Therefore, any given password may *look* random (to you, to humans, to some
algorithms), but it cannot actaully *be* random. This is because in principle
there always exist algorithms which will generate that password with higher
probability than some other passwords.
You cannot hide behind randomness.
HTH, :-)
Marko
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
