Making security a default:
UX features to protect your users
Whenever we talk about security, we will probably discuss about how secure are the apps or websites we dig in. Usually, we stick to wonder if these platforms are encrypting their data, covering authorization and authentication procedures correctly, managing several layers of security, etc. Some other times, specially when we encounter cases of phishing or any Social Engineering technique, we just go ahead and blame the users. Yeah, specially we, as "tech" people. It even looks like we have some sort of list of predetermined comments regarding these cases:
– "Mom, why is your firewall turned off?"
– "Bro, why did you leave the 'Remember Me' checkbox checked on my computer?"
– "Ahmm boss, why is our user/password for the router configuration the default?"
(My friend Miguel has a funny post regarding this one), and the list goes on and on.
1.1 Apparently, the configuration of the Firewall for new users on Mac. I noticed this when I created a new account in my computer.
1.2 The initial home router configuration sometimes has a default password you can easily find on internet.
Some months ago, we had a debate about this particular topic in my InfoSec class (here you can read some cool security posts from my classmates btw). In my case (as usual), I was defending users (most of them, at least). From my perspective, most of the times, common users are not the only ones to blame. Yeah, of course they do not have the best security practices, but that's because they do not know what the best practices are at all. If we think about it, it actually makes a lot of sense; when you acquire any product, you would believe that it is all-set for its proper usage. For example, when you buy a new car, you know it is ready for a ride. You should not worry if the tires' pressure is fine, or if the engine is connected to gearbox; you just assume that the experts who designed and built it did their job. And that's precisely the issue with security defaults in most software: they are configured to be useful, not to be secure. In a nutshell, software is delivered in an easy-mode all-allowed state. Of course I get that the intention is to give the best impression of our product/service to the user, but what are the security trade-offs of this? Is it worth it? No, not in my opinion. In this post, I will discuss what are the causes of this, some examples and possible solutions (good and bad ones).
The Problem
– Friend: "Oh man! Chrome allows me to store all my passwords! I do not have to remember any of them at all!"
– Me: "Yeah, it's cool but insecure. Do you know all the trade-offs of doing that?"
– Friend: "Meh, who's secure anyway? Google already knows everything about me."
If you want to know why this is a bad idea, you should read this post. Security often blocks the cool features in a platform. If you think about it, security is normally the bad guy in the story. I have encountered myself several times in the situation above. I'm sure that I'm not the only one who has had this conversation. In this case, it seems like this awesome UX practical feature of web browsers is being blocked by security measures. From my perspective, this is a design problem. Although security breaches in software are sometimes caused by amazing hacks from incredibly talented people, most of the times, they are due to design issues. For the sake of the scope of this post, I will focus mostly on UX design issues, rather than software design problems, but I'm looking forward to post something about this topic in the future. Now, going further with UX issues, what is exactly the problem? Gwendolyn Betts describes it in her post as "it’s not enough to make them [the users] feel safe when using our product; we have to ensure they are safe". This is true in every sense of it: we, as designers and engineers, should take care of our users.
Understanding on what does this design problem rely, we must go deeper on the design process, particularly at the beginning of it. Whenever we are about to design a new product, we should include security as part of the design features and user cases to be considered from scratch; basically, we need to put as a top priority the protection of our users. Two of the most essential parts of this design process are research and testing. The research we need to do about our users is not only related to their needs that map directly to our product, but it's trying to think ahead on every possible pain that they could have. In concrete, we need to learn more about (1) their security practices, (2) the possible security breaches they could encounter among different user stories and (3) how these breaches could impact their lives. For instance, if our users work at a bank, and they tend to use the same password for all their accounts, we need to figure out how could we, as a service, keep an eye on them. In this case, the possible risk and impact that they could go through is huge, because of everything that working on a bank implies. These considerations should be fundamental in both the ideation process and the sketching. It's not easy, I'm sure of that, specially because we try to focus on the core of our product when sketching the possible solution; what we might not see here is that, in fact, security is part of the core of any software-related product. We should integrate security patterns and architecture as part of our UX design. But the work is not done yet, because now, we need to test. Finding out how is our user is performing in terms of security is essential; basically, we want to find out if both our user experience and interface are guiding them through good security practices without them even noticing.
Case of study: Amazon one-click purchase
"There's a bank in Australia that, at one point it was spending 75 million dollars a year for password resets, because people couldn't successfully use this form".– Spool, 2017
Jared Spool, founder of the User Interface Engineering Institute (one of the largest research centers of its kind), defines this interaction of apparently "distant" areas, security and user experience, as SUX (or SUCKS). In his conference "Insecure & Unintuitive: How We Need to Fix the UX of Security", he addresses this term to describe the problem by focusing on one of the most unsafe and expensive, nevertheless common forms of interaction inside a website or app: the log in interface. The example above is just a hint of how expensive this could be for companies when it's poorly design and that's without even thinking about all the security issues that happen at the login. Users can be lazy, and we need to understand that. If you want to know what could happen when you are a lazy user and avoid security measures such as two-step authentication (which btw could be a mess, as The Verge explains in this article), you should read what happened to Mat Honan, the guy who got his digital life completely dissolved.
1.3 The one-click longitudinal journey (Spool, 2017).
Going back to Spool, he analyzes the case of Amazon's one-click purchase system and how the company has methodically taken care of all the possible user cases, threads and risks that is could imply. Even though I'm not a huge fan of the one-click purchase feature, their work is quite remarkable; they enabled an useful UX shortcut for users to buy products right away (which, of course, benefits Amazon) but they also designed it carefully enough to protect their users and themselves. It's not bullet proof, but it can handle all sorts of problems that users could encounter. Are you wondering how they've done it? In a nutshell, they integrated a security architecture within their UX design. Amazon implemented several layers of security inside the purchase process, but they only trigger the additional layers when they need to. In order to do this, they identified all the possible states of the user across their process; this is quite a common mistake that we do (I have done it myself), we just consider two states: logged in or logged out. Unfortunately, this is not the case for modern websites, specially when they handle all sorts of mechanisms to avoid asking the user for the data over and over again. Such mechanisms, like cookies or sessions, are normally not considered during the design of the UX. As Jared explains, users can be identified, authenticated or authorized, and we need to consider this at all time. I will go deeper on methodologies and considerations that could help us achieve this kinds of SUX in the next section; also, I will go through possible solutions for this. Of course, there is good and bad solutions, so we will discuss both of them.
Bad Solutions: Educating our users
"User education puts the burden on the wrong shoulders."– Nielsen, 2004
First, Jakob Nielsen, from Norman Nielsen Group, suggest in his article that we should rather rearchitect security than try to teach security to our users. Education for our users is not the proper solution for security problems. Although is noble from developers to encourage learning about security, it will only lead to experts conclude that users are stupid; as mentioned earlier, they are not stupid, they just don't know, and that's not their fault. Essentially, the three main reasons Nielsen states for this are (1) it just does not work, (2) it puts burden on the wrong shoulders and (3) we'll keep limiting internet's full potential because our users have fear to use technology. And I definitely agree in all of them, because educating users on this is just not realistic. A counter argument for his position is that users should take responsibility for their actions, as well as they do in the physical world; however, as Nielsen suggests, this does not hold because security breaches on the physical and digital worlds are not fundamentally the same. The exposure that any user has in the digital world is way more extensive than on the physical one. He gives a great example of this in his article, with the "Lock your car" analogy, which I would recommend you to read.
Furthermore, other solutions that I've seen in my experience that were not the best for users include adding more steps for the authentication process. It's insane how some apps and sites have so many steps and questions just to login, rather than having a nice architecture to avoid this. I mean, have you ever encountered yourself asking “what was my favorite vegetable when I created this account?” (from Spool's conference). So yeah, let's try to avoid this.
Good Solutions: Rearchitect Security
"It's not content first or mobile first, it's security first"– Spool, 2017.
Both Nielsen and Spool agree that most of security issues regard on design problems that could have been prevented. When security is considered from scratch, we start thinking deeper and ahead of all the possible problems that the user can encounter in the future. Considering what's the most secure and least annoying path for our users to login, what defaults can keep them protected, how could we avoid stupid warnings that normal people don't understand, etc. I could assure you that most of this issues could come out in early stages of the development if people gave the necessary time to think about them.
The basic recommendations for this problem regard on both going deeper with our analysis of the experience we are designing, as well as verifying and follow the basic security measures for any software. How can you do a deeper analysis? What are these basic features? Let me guide you through them.
As Spool suggests, and as any security expert would, you need to define a threat model. In a broad sense, a threat model will help you go through all the possible risks that your experience might involve. Going back to the Amazon's one-click purchase, threat modeling got them to think possible ways to somehow 'hack' the process; a basic example: gift cards. Although it might sound trivial, gift cards represent a back door to steal money. Once they identified this risk, they decided that gift cards cannot be purchased with one-click feature. A couple of days ago, we discussed this with security experts from Intel, and they remarked the importance of using threat models. Moreover, if you want a tip for defining this threat model, remember security's golden rule: trust no one. Another big step to achieve security is about defining all the possible security-related configurations that the product will have, and turn them on all by default. At the beginning of the post I mentioned the importance of making the default as safe as possible, because it can represent major risk to the user if they do not know about the consequences of this. In particular, take in mind that this also involves automating updates, mainly because updates do not only involve new features, but important security patches. The fact that the product needs security patches, is not because (not always at least) the product was always insecure, but because security is always evolving. Furthermore, relating back to defaults, if in any case the user decides to turn off something, explained them what they're about to do, but make it available for humans; what I mean by this, is that you need to avoid text that no one can understand, sometimes not even "tech" people can. This leads to another important factor, which is make security as usable and simple as possible. Security is complex (very, I would say) so we need to polish as much as we can our security features in terms of usability. Other basics are encryption and digital signing; the first one to avoid that plain text travels through the internet; and the second, to know who's actually sending/posting stuff (and avoid fake Google login pages).
Hopefully, all these suggestions might be useful for you, my dear reader. However, not everything can be done by having a nice and secure user experience. We, as society, need to start taking some matter in this business. Although user education is not a proper solution for secure user experience, it is a must in the future of education itself. Digital era has been around for sometime now, and knowing about security should be part of our education process. Awareness regarding this topic is something that matters to all of us.
Did you like this? Did you hate it? Please leave a comment, and help me improve my writing and blogging skills :)



Comentarios
Publicar un comentario