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