|Thomas Delrue on 12 Jun 2017 12:23:48 -0700|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PLUG] PI being targeted for malware|
On 06/12/2017 02:36 PM, JP Vossen wrote: > On 06/12/2017 02:16 PM, Soren Harward wrote: >> On Mon, Jun 12, 2017 at 12:42 PM Thomas Delrue >> <firstname.lastname@example.org <mailto:email@example.com>> wrote: >> >> On 06/12/2017 11:48 AM, Anthony Martin wrote: Why do we still have >> to tell people not to use the default password or that they should >> use a strong pass-phrase (if you HAVE to use pass-phrases that is, >> instead of key-based or some other stronger authentication)? >> >> At what point can we just revoke someone's privilege of touching >> computing devices ever again until they complete some sort of >> education with a verified skills assessment? >> >> Because you can just as legitimately ask "Why do we still ship >> software that poses a huge security risk in the default >> configuration when we know full well that users cannot or will not >> follow basic setup instructions? At what point do we revoke the >> privileges of software engineers until they complete some kind of >> education with verified skills assessment in creating software >> that's secure by default?" > > +1. It's not the end-user's fault even if it's the end-user's > fault. Our computing industry has failed, in large part, to provide > secure solutions. A lot of that is because the market wants > race-to-the-bottom prices and I don't see that changing easily or > without a lot of regulations, which gets tricky fast. I guess what you're trying to say is: You can lead a horse to water but you can't force it to drink. Perpetuating that falsehood is bad! The customer is NOT always right! I think this attitude is wrong and it is damaging to the goal of secure software and/or computing. It is NOT wrong to demand a level of education on the object you will be working with. Especially if that object has the ability to influence others, which computing devices frequently/almost always do. I find this attitude wrong and detrimental because it gives end-users an excuse to act or continue to act (even worse) irresponsibly. I don't see any reasonable person taking this same approach with (e.g.) driving(*). If I tell you to not do X and you still do X, or if I tell you to do Y and you don't do Y, then that's on you. It is NOT my fault and I flat out refuse to take responsibility for that. Just /imagine/ using the same laxness in other fields as the level of laxness that we allow in software usage because this or that user "doesn't like adhering to instructions". Lemme know how that's working out for ya when you get (for instance) OSHA'ed. When I lead that horse to water and tell it to drink, that's because maybe I know that we won't encounter water for a long while. The horse should bloody well drink the water! A horse that refuses to drink, could die from dehydration when it's in the middle of the desert and there's no oasis around for miles. (You know what I call a horse like that? I call it "my previous horse" or "glue" - depending on my mood!) You are entirely correct about the race-to-the-bottom and I'll just add the following: "If you think hiring a professional is expensive, wait until you hire an amateur". > In this case, yes--nothing, but nothing, should ever ship with a > "default password." If you can't figure out a way to provide or set > a decent password on first use, you have no business providing > whatever it is. Entirely agreed. Providing documentation on how to set up a strong password is also "a way to provide or set a decent password". Could it be simpler? Sure, but that doesn't give you a pass on not doing it. > I get why the rPi works the way it does, but they need to do better. > Use the serial number of the device, print a default password on the > board, use part of a MAC address...something. Figure it out... > Maybe now they will... Agreed, they can afterwards update their docs (that the user would need to read because it'll tell them how to know the password), which -as we've learned- the user will ignore anyway and will set up a password "password1" and that's just hunky-bleepin-dory. But, hey, that's MY fault and not theirs! (*) As I'm sure you're aware, this is /one/ of the issues with self-driving cars, namely "who is liable"? The operator or the manufacturer? If everyone has self-driving cars, who do car-insurers go to to collect the premium? If I have zero control over the car, do *I* have a level of liability?
Description: OpenPGP digital signature
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug