On Thu, Jul 30, 2015 at 9:10 AM, Lamar Owen <lowen at pari.edu> wrote: > On 07/29/2015 07:40 PM, Chris Murphy wrote: >> >> On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at etr-usa.com> wrote: >> >>> Security is *always* opposed to convenience. >> >> False. OS X by default runs only signed binaries, and if they come >> from the App Store they run in a sandbox. User gains significant >> security with this, and are completely unaware of it. There is no >> inconvenience. > > > While I agree with you about the long-term viability of passwords, I'll > disagree with this statement. There is a loss of convenience with signed > binaries from a store: the user can no longer install directly from the > program vendor's website but must go through the walled garden of the store, This is untrue. Apple's developer program and OS X support two kinds of code signed applications: App Store programs are signed by the developer and Apple and only run in a sandbox limiting their interaction with each other; and developer only signed applications, which can opt into App Sandbox, and users can install these applications normally including from the vendor's web site. Both types of applications can be installed and executed by default. Unsigned applications will not execute by default. An admin user can change this and permit those applications to run - in fact the user has the ability to grant an exception *per application*. I have a litany of criticisms of the Apple developer program, but those aren't relevant to this discussion. What is relevant is that both developers and users in the OS X "walled garden" have a security advantage with almost no inconvenience. Now I see that the "Docker Engine will now automatically verify the provenance and integrity of all Official Repos using digital signatures." So that's a good thing on Linux, but it is far away from ubiquitous let alone a default behavior. > and developers are held hostage to having to meet the store's policy or get > their signing key revoked and/or their app 'de-stored' or worse. There is > significant inconvenience to users when their app is removed from the store > for whatever reason and they cannot get updates (or reinstall their app, for > which they may have paid a fee) anymore because the app is no longer in the > store (and that could be for arbitrary reasons, including political ones). These are all implementation criticisms. The idea of code signing is valid and useful. Apple made it really quite easy for users, mostly easy for developers, and that's the part that absolutely should be replicated in free software. But that part is orthogonal to the thick layer added on that is Apple's unique process, and I'm in no way suggesting that part is a model, nor should it be suggested its inextricably attached to the code signing concept. I very much disagree with any sentiment that users, even sysadmins, should be security experts. This shit is too complicated for that. The penalty for getting it wrong is too high. This idea that minimally better password quality is going to stop jack shit? I don't buy it. It will stop Tonka Toy type attacks. It's not going to stop anything moderately serious or more, to do that means adopting best practices. Again, I don't know who puts computers with sshd enabled with challengeresponseauth directly facing the Internet, but that to me sounds like a bad choice. I have to access all clients' servers through a VPN first, none of them have such services Internet facing. > Or a hackable remote kill that allows an attacker to wipe you device out > from under you. Or now the inconvenience of losing access to the encrypted > volume because you forgot the exact spelling of that ten word seventy-five > character passphrase and you're locked out and no data recovery tool out > there will get your files back. > > Security and convenience are always at odds with each other; more secure = > less convenient in some form or fashion; even if you have to dig for the > loss of convenience there will be a loss of convenience somewhere for > increased security. The security increase of even minimally higher quality passphrases is less than the increase in inconvenience to the end user. And that includes sysadmins. So full circle is that I think it's a bad idea for sysadmins to be coddled into thinking that a GUI installer enforcing 8 character passwords instead of 6 means anything has actually improved. It's still merely just treading water (or maybe sinking to the bottom at the same rate). And in contrast to that, the same system blindly enables sshd by default and also with challengeresponseauth. When I called this password quality change concept turd polishing, I mean leaving sshd enabled by default with challengeresponseauth is the turd and polishing it is trying to protect this with an 8 character password instead of 6 makes the former OK (and shinier). It's an absurd juxtaposition. Had the proposal been a compulsory 16 character passphrase, I merely would have gone and made some popcorn. I'd have nothing to say about that. Because at least *that* would be a meaningful increase in minimum password quality, but holy hell people would have totally f'n flipped out if they had to pick a 16 character password to install an OS. -- Chris Murphy