
Stop Trying to Fix the User (2016) - mikecarlton
http://ieeexplore.ieee.org/document/7676198/
======
userbinator
This article scares me, and probably not in the way the author intended.

 _We must stop trying to fix the user to achieve security. We 'll never get
there, and research toward those goals just obscures the real problems. Usable
security doesn't mean “getting people to do what we want.” It means creating
security that works, given (or despite) what people do._

In other words, "lock the users up so they can't hurt themselves"?

Quite frankly, that's disturbingly authoritarian. In the real world, the
analogy would be the government deciding a long time ago that crime can't be
fixed, and enforcing complete control over everything the population does.

That's fortunately not how things turned out, although it now seems to be
rapidly heading in that direction...

My personal view: people are going to continue do bad things either
accidentally or maliciously, and trying to stop that completely means
eliminating all personal freedom (and responsibility.) The ideal is somewhere
in the middle between freedom and security.

~~~
antientropic
> In other words, "lock the users up so they can't hurt themselves"?

No, it means that supposedly "dumb" actions by users like inserting a USB
stick or opening a Word attachment shouldn't break the security of the system.
(In fact, they're only "dumb" actions because our systems are designed without
security in mind.) That's hardly authoritarian.

~~~
WillReplyfFood
How would you sandbox such dumb "actions"? Draw a copy of everything afflicted
by the actions of the thumbdrive- and kick the container, once it touches the
system in a bad spot?

We are talking about tradeoffs- and the truth is, we traded security for
development speed and low price, because security has a tendency to arrive
very, very late in the game, the moment people want to abandon the system or
concept.

~~~
Doxin
There is exactly no reason whatsoever for executing code from an usb stick the
user has just inserted.

------
davidgerard
I remember working antivirus support and being able to say as late as 1999 "no
sir, you can't get a virus just by reading an email." Fortunately, Microsoft
fixed that, for all our comfort and convenience. Thanks, Microsoft!

------
digi_owl
I wonder how much boils down to having data and code share the same IO
channel. In the end, all of security boils down to tricking the OS and the CPU
into treating what was first presented as data as code.

~~~
averagewall
Not common trojans that just pretend to be a harmless program. How could you
possibly separate data and code anyway? Javascript not being on web pages? No
PDFs allowed in the data channel?

~~~
digi_owl
[https://en.wikipedia.org/wiki/Harvard_architecture](https://en.wikipedia.org/wiki/Harvard_architecture)

[https://en.wikipedia.org/wiki/Modified_Harvard_architecture](https://en.wikipedia.org/wiki/Modified_Harvard_architecture)

------
convolvatron
I think Schneier has been around long enough he probably had some thoughts
about what to do instead of blaming the victim. Is there an analogous
prescriptive article? PKI and chain of trust models never really happened for
the same user facing reasons that the state of things is a mess today.

~~~
gigs
Yeah, I mean, what is he suggesting as an alternative for passwords for
something like a small/medium ecommerce site?

You can have a guest checkout so they don't need to have an account, but some
people want them.

~~~
averagewall
How about not remembering the user. If they're not going to come back for
another year, if ever, they can enter their credit card info and address again
next time they buy something. Browsers autofill some of that stuff anyway so
it's not even hard.

~~~
GuB-42
This may be a problem for tracking orders.

The user may want to know in what state the order is, maybe change something
after payment, return product, things like that. There is something reassuring
about it too.

It is users who want to be remembered.

~~~
falcor84
You do of course need to remember each order, keeping track of invoices etc.
But I don't understand why that would require keeping track of a user more
than any brick and mortar store that supports paying now and getting the
product delivered to your door.

~~~
icebraining
You need to authenticate the user to grant them access to the order info, no?

~~~
falcor84
Not necessarily (as you wouldn't in a store); they'd just never to prove
sufficient knowledge of the transaction (e.g. invoice number).

Note for example how you can track any package in the world when you know it's
code. That seems to be working well without relying on user authentication,
no?

------
cm2187
A good exemple of that is SMTP. This protocol is fundamentally broken and
needs to be fixed. There is really no good reason to allow any server to send
emails on behalf of any random domain. The vast majority of users are still
unaware of this behavior. The fixes that have been developped so far (spf,
dkim, etc) are merely lipstick on the pig, they are so optional (and rarely
used and when used often broken), that you can’t safely block traffic based on
that. IP reputation has its own shortfalls and will become impractical with
IPv6. If we don’t come up with a successor now, how will it ever be fixed
ever? Emails aren’t going away.

~~~
starkanop
> There is really no good reason to allow any server to send emails on behalf
> of any random domain.

Except for mailing lists. And email forwarding. And a lot of other stuff you
take for granted. Users might not explicitly know about the technical details
of how a lot of things work, but that doesn't mean they don't expect the
resulting behavior.

It's fashionable, these days, to put authentication and authorization in the
transport layer. It's not a natural law, though. As an example, consider
s/mime or pgp message signing. MDAs could validate signatures and discard
messages that are not correct. This is an example way to solve the auth
problems you describe without breaking existing mailing lists, since you'd be
validating the content instead of the envelope.

Just food for thought. SMTP isn't as broken as you think, and replacing it
isn't necessary to solve today's problems.

~~~
cm2187
I am not sure I agree with mailing lists. I don't think the email needs to
look like it is coming from a user. There is nothing wrong with the email
looking like it is coming from the mailing list itself (unless I misunderstood
what you mean by mailing list being a problem).

You can't ask regular users to run pgp themselves. This is a prime example of
the sort of technical details that a user shouldn't be asked to even
understand or be aware it exists.

------
featherverse
The right future is one where 100% of users use password managers or keyrings
locked by some sort of simple but secure (and most importantly stable)
biometric system.

Tho ignorance of technology concepts is not something to be tolerated, it's
something to be cured with vigilant education efforts.

------
_nalply
To view this in even broader context: Children and people with a cognitive
impairment have a human right to autonomously peruse the services of the
Internet. Nobody talks about trying to fix these specific users.

------
snarfy
But I have to fix the user.

I could let the user enter any password regardless of password rules, the only
rule being it meets the minimum entropy requirements (long enough). Instead, I
must make them enter a password that is a minimum of 8 characters with mix of
case and symbols.

Why? Because it's the industry's best practice. To not follow would open the
company to liability, so I do what the other monkeys are doing [1].

[1] -
[https://security.stackexchange.com/q/33470](https://security.stackexchange.com/q/33470)

