▲ 69 points
back
33 comments
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.
> 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.
Actually it seems exactly the opposite. Considering the users "fixable" is authoritarian, adapting to their behaviour is not.
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.
There is exactly no reason whatsoever for executing code from an usb stick the user has just inserted.
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!
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.
Not all exploits are based on treating "data" as code. For instance, in USB autorun attacks, it is the intended behavior of the victim system to run the payload as code.
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?
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.
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.
>Yeah, I mean, what is he suggesting as an alternative for passwords for something like a small/medium ecommerce site?
https://thisdata.com/blog/an-introduction-to-passwordless-lo...
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.
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.
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.
You need to authenticate the user to grant them access to the order info, no?
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?
> but some people want them.
I believe if statistics would be produced: the users mostly don't want them. The owners of the site and the programmers mostly do.
I have statistics. 2640 user accounts from 6320 orders.
Some customers are repeat customers, but even if we are generous and assume that the majority are not repeat orders (I'd estimate 25% are repeat orders), that's over 1/3rd that created an account even though I offer guest checkout without an account and don't really push them to create an account.
Interesting, thanks. But it is still complex: it surely also depends on what you sell and the average customer you have, and also if the users expect to have some advantages by registering.
For example, I personally like to be able to follow the order etc. but often online stores insist that I have to register for anything like this. If the order number and my name were enough, which technically should be, I wouldn't. But having no alternative, I do. So I count myself in "I would prefer not" but you see me registered and count "one of 3 who like registering."
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.
> 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.
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.
https://en.wikipedia.org/wiki/Internet_Mail_2000 would have been a reasonable first step.
> The fixes that have been developped so far (spf, dkim, etc) are merely lipstick on the pig, they are so optional
Lipstick on a pig yes, optional, no. If you want to have your e-mail delivered to Gmail you'll need them. And since Gmail is 50%+ of all e-mail that means it's pretty much mandatory.
Last time I looked at my incoming email traffic, a significant number of mail wasn't signed or/and didn't have spf entries. Even if it is 20% of the traffic, it's still too large to safely block.
> Even if it is 20% of the traffic, it's still too large to safely block.
Maybe for you. But considering I use gmail I block it all and never notice any problems
Gmail has the scale and the means to run all sort of sophisticated heuristic to determine whether a message is a spam or not. It's good for gmail users that they make up for the shortfall of the protocol that way. But for everyone else, the protocol needs to be fixed, you can't expect every company in the world, large or small, to build and maintain the spam/phishing/malware filters that gmail runs.
I’ve noticed that recently I check my email less and less often. I use gmail as an auth service more than anything else.
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.
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.
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].