design for security

Tags: Design

August 12, 2008 by steven

Almost every project I have worked on, for most of my career in interactive design has had at least some security component. Users have some sort of account, or submit payment information, or do something else which requires authentication, authorization and protection.

Security has to be baked into product design, and done so with a security mindset. Security conscious designers will assume the worst, and be able to dream up ways of attacking their systems.

Ideally, these are the principles of any good designer; you should always be looking for flaws in your design, and be willing to take a big brush out and paint over parts that don’t work. It’s always best to get these things fixed early, before users become upset, data stores get overloaded and security is compromised. It’s always easier to fix things in design. And however painful it is to ask for a change now, it’ll be worse when the client comes back to ask why the product is broken six months after launch.

So, that said, here’s a set of security principles, guidelines and concepts I work towards with my designs, in no particularly well thought out order:

Evaluate the risks

Consider what is being secured. An online game needs much less security than a banking application. The key to deciphering this is to understand the risk involved. How much damage could inappropriate access cause? Be realistic. Not all financial liability is the same. Unauthorized bills for 99¢ games is not the same as a banking app offering access to real world accounts.

Users rely on you

Remember that there’s a counter-risk to excessive security. If it’s too hard to use, or too hard to recover passwords, your service may not get the use you wanted. The risk is not just to your sales and churn numbers. If users come to rely on a mobile banking application, then cannot pay their bills for a week while out of town due to an authentication failure they cannot fix from the road, that’s well-nigh as bad as people stealing from their bank accounts.

No lock is impervious

A key to security theory is that no lock is unbreakable. The safecracker has to not just get the lock open, but do it before the cops come and stop him. Your front door lock works on this principle. No matter how great a lock you have, it’s pretty easy to pry the whole door off, or bust out a window. But you or the neighbors will probably notice that. The same principle applies to security of interactive systems. Make appropriate security measures, and have ways to detect and fix them when they are violated.

Detect – The reason you get all those emails saying you changed your eBay password, or purchased something with Amazon 1-click is not just for your records, but so you have a chance to say “no, I didn’t” and fix it. Sometimes, end-of-month bills are enough. Often, immediate notification is better. Out-of-channel (e.g. send an email) is often a good system, as many security violations are only going to have access to one system. The evil doers often have no way to intercept such messages, so the window of opportunity is smaller.
Limit – The user should be able to lock their account, or otherwise stop any suspected security violations, immediately. If your system has serious liability potential, have some phone support 24/7, just for fraud issues. Automatic detection can also work. Severe changes in user activity can be detected by your system and acted upon – usually, first you notify the customer; try not to shut them off without callig first. Credit card companies are good at all of this. Look at how they detect and limit fraud, while not excessively bothering their customers.
Fix – How can a security violation be repaired? Often, it’s easy. If you sell games, you probably have a refund system already in place. Just extend it to fraud situations. Sometimes it’s hard. Social networking sites that allowed inappropriately authorized user posts could destroy their reputation. Consider ways to block old comments, or over-write them with a notice that these may have been hijacked, and should be disregarded. It’s not perfect, but if the service can say something that’s got a lot more weight than the user trying to defend himself.
If you sell banking services, or something else hard to fix, then work on detect and limit, a lot.

If someone finds a hole, believe them

Anyone can build a system they cannot break. Ideally, your system is multi-dimensionally robust enough that a breach is not going to become catastrophic, anyway. Regardless, if someone else on the team, or your mom, or your nephew, finds a way to break the security, believe it. Don’t blow it off and assume it’s an edge case. Security violations are all about edge cases. Fix it, and if possible see if there’s a bigger root cause to the gap.

Know your user

Too many systems (and designers, and developers) assume you can be signed on, or not. Wrong. There are at least three levels:

Anonymous – Users who are totally new, or have no cookie, or similar are anonymous. Depending on the way the system identifies users, you might be able to assume they are new, and offer them different information.
Identified – A lot of folks call this “cookied” but that’s just a technology to accomplish it. Device possession (mobile devices being fairly personal) is a good way to do it. One way or the other, the system has a good idea who the user is, and can offer them the full personalized experience.
Authenticated – This is the signed on one. The user can get full access to whatever they need. But often, it works well as a subset of “identified.” When the user hits an area that invokes financial liability, or they want to change their password, or something else, you can hit them up for a password to become authenticated.

Add factors

I am not a big fan of multi-factor authentication, because it’s generally too much for the user to deal with. In certain cases, smart cards and similar devices are useful, but they generally fail for consumer applications.

However, there is one case where it’s useful, and that is using device-possession. It’s not quite the same level, but once the device has been validated as being owned by the registered user, it can serve as an authenticator (as well as the identifier, above). This can be used any number of ways, depending on your application. A suddenly different device could require additional authentication, re-validation and fire a notification, so the user is aware of the change in case it is not valid access. This is much harder to do reliably with desktop computers.

Authentication is not (necessarily) authorization

Authorization and authentication are often confused. Authentication just means you entered credentials, and now the system is sure it knows who you are. Authorization is what you are allowed to see and do. That can vary by user, by device (mobiles, or home computers might not be able to have access to some systems that work on the internal network) or by authentication level. Identified users will also have an authorization table, revealing what they can access and accomplish.

Design for profiles

This is a topic worthy of a series of posts. I have several different powerpoint decks on it. What I am talking about is different security profiles for different access methods. You might need, or want, different credentials, different recovery systems and different authorization depending on the method of access. If carefully handled, this doesn’t have to be a problem; my online banking authentication has no relationship to ATM authentication, for example.

Even if you don’t need this today, you might be expanding later. All the security systems need to be expandable, so you are not stuck when your product is a huge success and grows by orders of magnitude. Create, in summary, a target security architecture and build whatever is needed of that. But make sure all the developers have a copy of the target, and are building in that framework.

Don’t give away the store

Any discussion of adding identification usually talks about cookies, and url strings. And those rapidly degrade into talking about how much information to place in those keys. The only right answer is “none.” Treat these as keys, only. They should have arbitrary values, not related in any way to the user’s name, account number, phone number, etc. The server then looks it up and decide to who it’s attached, and to what they have access.

I also want to emphasize how much key values should not be hackable. Do not use obscure data, do not use known user data to encode a key, and do not even use the timestamp of a session as the seed for a key generator. All of these can be easily found, decoded with varying degrees of difficulty, then used to easily decode all the other keys used on your site or application. This happens all the time. You are not immune.

Recovery schemes

Users will forget their usernames and password. They will need to change devices. Recovery schemes need to be provided to let them get access back, rapidly. Sometimes it’s desirable to delay them, or take them out of channel. But unless there are specific security reasons or a suspicion of fraud, you generally want to be as helpful as possible and let them back in right away.

Having actual people answering phones can be nice, but if that’s the only way to regain access, it has to be friendly and fast. Minimize time on IVRs, and make sure there’s no transferring to do this. It’s considered a simple task, and the user is already annoyed. The best is to provide a self-care system and let the user reset themselves.

I use reset and recover somewhat interchangeably in these discussions, but I am wrong to do so; don’t follow my lead. They are different and which one you use depends on the manner of reset or recovery. Most often I will allow recovery of usernames (you don’t generally want to change those), but allow users to see their old password, then require them to change it. A sort of reset/recovery. This has the advantage of reminding them what /sort/ of password they use, which might help them pick one they will not forget in the future.

As far as which method to use to recover or reset, I like question & answer pairs. The whole “what color was your first car?” sorts of questions. This method of secondary credentials have gotten a bad rap from poor implementations (mostly, bad questions) but are often a pretty good solution. If keeping users in-channel is good (and it may not be from a security standpoint for your application) they should be considered. For mobiles, users often cannot get to a computer so you might have to allow recovery from the device if you want that user to continue paying for your service.

Use questions that are not time-dependent. E.g. What was the color of the /first/ house you lived in?
Use questions that are not possible to derive from generally-available records. Mother’s maiden name, parts of SSN, and other keys are easy to hack if someone has access to customer data, can be used to build a record of customer data themselves, and are now actually disallowed in the U.S. by the FCC (if you are a carrier/operator). More rules are coming so get ahead of them.
Try to ask for information that encourages simple answers. As a bad example, if asking for city of birth, tell them to leave out the state.
Think about data storage and processing methods. Usually, disregarding spaces and special characters is best. Then running stuff together and commas are of no significance to the entry. For the city example above, you can probably just look for all possible state names and abbreviations (and mis-spellings) and disregard them. Case should also be converted to one of them, only.

Personal space

Mobiles make entry of information difficult, and are often used in situations where the user is distracted. Entering passwords the normal way is harrowing, and invites keying errors so bad I’ve seen plenty of people never get past the sign on screen. By “normal” I mean masked, or dots-instead-of-actual-characters. Instead, accept that mobiles are very personal. The small screen means there is almost no way to look over someone’s shoulder casually enough to read passwords, so they can be simply left unmasked.

Let your users take some responsibility

I don’t mean make them sign a waiver. I mean, don’t be too annoying about password requirements. Let the user choose their own. If you give them onerous requirements they’ll just keep forgetting it, or have that much more dislike for your service from day one.

As a general rule, mobiles have numeric keypads. Therefore, pretty much all mobile passwords should be numeric only (I guess, making them “PINs” instead of “passwords”).

Device-level security

Often, the best security is to remind users how to best secure things. Many devices, especially mobiles, have device-level security. If a user is truly worried about someone getting into your website or application, they are first worried about someone gaining access to the device (especially if you use device-possession as part of the credentials).

Therefore, I never turn on the full security of any application by default. Security settings pages allow users to require PIN, and add other restrictions, but also tell them to consider locking the device instead.

Barbara thinks this should be added to the wiki but I am not sure. It’s mostly general guidelines, instead of mobile-specific. Some of the mobile guidelines, and others not discussed here are already covered in the Text Entry topic.

Search the site

What we do

Downloads

Recent blog entries

Blog topics

Blog archives