On Fri, Feb 13, 2015 at 7:57 AM, Eric H. Christensen <sparks@xxxxxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Thu, Feb 12, 2015 at 05:09:56PM -0700, Chris Murphy wrote: >> I don't have an easy way to prove this, but in a millions+ attempt >> brute force attack, I find it difficult to believe that >> correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted. >> I had recently read that up to 100 character dictionary only word >> based passwords were routinely attempted in brute force attacks. > > I have a really awesome white paper sitting on a hard drive around here somewhere that explains this perfectly. It comes down to the math involved. Assuming all characters are available, letters (upper case and lower), numbers, and symbols, creates a good number of available choices for each password character. It turns out, however, that using more characters in your password, assuming just letters, is far better than using a shorter password with everything. Combine both of these, long password with all available character sets, and you get a really difficult password to break. The goal of the brute force attack is to gain access, quickly. So the strategy is always changing on both sides. What's true a few years ago isn't necessarily true today. http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/ I think it's much more likely a user has a 2, 3, or possibly a 4 word password based on dictionary words, than truly random 8 using all available ASCII characters. I'd expect at least 2 word combinations from a dictionary to be attempted before random 8, and probably 3 word combinations are. Diceware is recommending 5 word passphrases as the minimum. I just don't see that being accepted by users for a device. Sure for Twitter but the context and consequences are totally different. > Yeah, but users are dumb. They think their use case is a computer sitting in their house and that with this they are fine. And this works great until their house is broken into or they leave their backpack, with their computer inside, on the subway and only then do they realize (or maybe they don't) that their security could have been better. a. The contra argument is that software engineers are dumb, they should design this stuff better instead of dumping more complexity onto the user. Ergo, be careful with flinging ad hominem attacks. Once they're in bounds, the monkey on the other side of the debate is just as full of crap. b. Your example are bad ones. The installer doesn't mandate encrypted volumes, and only encrypted volumes protect against your examples. A stronger user or root password does exactly nothing. It doesn't alter the time it takes me to own your data by even 1 second. > Never never never look to Windows or OS X as a way to show how things should be. These operating systems are horrible. From my experience, Linux users typically see Linux as more secure because we have better code and we don't allow dumb things (or we used to not do dumb things anyway). Sometimes you just have to lead by example instead of looking around and trying to built other people's bad ideas into your product. Or you can lead by example with your own bad ideas into your product. I have examples of this in Fedora if you ask. But your style of debate above is sloppy, it contains no facts, it's hand waiving and glittering generalities. I'll take on your disk encryption non-suggestion from earlier since that's still peripherally on topic: OS X simply does it loads better than anyone. It can be opted into at any time, post-install. Click two buttons and conversion begins. The system can continue to be used, put to sleep, or even rebooted. The user login is tied to unlocking the volume. This makes it more likely the user will use disk encryption, only one password to know. It also means the singular location for changing user password means disk unlocking password is updated at the same time, the old password will not unlock the volume. Further it means adding users causes no change in UI from a non-encrypted system. Linux: Well, we know how it works, it it's not like this. It's viciously user hostile in comparison. It's in strictly in the realm for sysadmin, esoteric level knowledge to manage this at all. So give up the cave man style debate tactic. "Windows bad! UGHH! Mac bad! UGHH!" isn't exactly convincing to any of my house plants, or me. > Oh, I said above that live attacks are more difficult than ones specifically looking at password hashes. I'll explain this part a bit as I think it shows where we can balance user and backend burden. When I have a hash table I can pour over it, almost indefinitely, to try to break a password. I generally cannot do this on a properly configured system because of rate limiting and maximum retries. If a system only allows for three tries before the account is locked I will likely not be able to break the password using brute force but would rather require some intelligence information (and I always start with sports team names). > > In the end, passwords are all rubbish and should be done away with. What are the other options, though? I suspect most people aren't using smartcards to log into their systems (or any other kind of multi-factor authentication). Until these options become more in use we need to raise the bar for password use. People are carrying around more sensitive infromation with them in their pockets and on their backs and by not properly securing their system they are just asking for trouble. Do you not see how your password policy defend hinges on grandiose assumptions? I have many devices lying around without any information on them, they're used strictly for testing, so there isn't anything but an OS and some cache files for ycombinator and cnn, BFD. Oh but I need to use strong passwords because someone ELSE might be an idiot and have sensitive information on their laptop. So you are drawing me into becoming responsible for other people's behavior too. Everyone is baby sitting users who don't give a crap. But let's say you're right, you thus far haven't argued for mandatory disk encryption, which is really the only way to solve the problems you keep using as examples. And yet it's a good thing you aren't arguing for mandatory disk encryption because that UX is such complete utter shit on Linux right now it is a Do Not Pass Go scenario. It could never happen. Meanwhile over on OS X, Apple is quite well situated for the next version of the OS to default to disk encryption enabled, and the user's workflow won't be impacted at all. But I agree passwords are rubbish and solving that problem is one of the Holy Grails. But this doesn't mean forcing users is better than getting their compliance voluntarily. Do you really think it'll go over well that Fedora *forces* users to do something other platforms don't? I don't think there's an award for this waiting. > >> Conclusion: I think the concerning services need to be disabled by >> default, and use OOB management to enable those services, since it's a >> long standing practice elsewhere. If we can do better than this, fine, >> but not by shifting the security burden. > > I really hate it when people say to disable security features by default. It's just really short sighted. I really hate it when people say to enable security features by default. It's just really short sighted. See how two can play that game? Do better. First, sshd is not a security feature, it's a remote connection service and increases the attack surface. Disable that. It has a lower burden on more people, and it's also an expected burden for anyone come from other enterprise cultures. The idea a Windows Server would have remote services enabled by default? I think most any hard core Windows sysadmin who also doesn't make bad excuses for Microsoft would admit this could be a liability lawsuit waiting to happen if they were to do that. That's how bad an idea it is. And stronger password requirements is not a security feature, it's an imposition. >People don't want to have to go through their system changing switches and adding configuration just to have a secure system. I honestly have no idea what you're talking about. Users can have stronger passwords if they want to opt into this, at any time. Force is not required. Flipping switches not required. >Users expect their system to be secure by default. If it's too much work to secure their systems properly they will either lose interest or forget to check a box and then get into trouble later. It's much easier to remove a security feature someone feels strongly about instead of trying to implement everything with the potential of forgetting something or the inability to properly test a particular functionality. Users expect their system to be secure by default, meanwhile sshd is enabled by default on Fedora 21 Server. Can you honestly not connect the dots here? The very thing that's enabled by default is the very thing being held up as the #1 reason why stronger passwords are needed by default. If that service is disabled, a massive bulk of the argument for stronger login passwords at install time is reduced. Further, weak passwords are immediately, visually communicated in the installer UI. The user always has this information available to them. Meanwhile, the fact sshd is enabled is not ever communicated in the installer UI. The user lacks this information. But what you're saying is, it's the user that's the problem? The user has perfect information of the former, not the later, yet it's the former that needs enhancement? What? Even if I accept the absurdity of full disclosure needing more enhancement vs no disclosure, it means you don't trust the user. If you trusted the user, simply informing them would be enough. But informing them isn't enough, you have to force them. Therefore it's clear they aren't trusted. If they aren't trusted, then why do you trust they know the risk behind sshd enabled by default? -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
