Re: [PLUG] PI being targeted for malware

Thomas Delrue <delrue.thomas@gmail.com> · Mon, 12 Jun 2017 15:23:32 -0400

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 
>> <delrue.thomas@gmail.com <mailto:delrue.thomas@gmail.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?