User Security: Overview

In a previous post, I laid out the basis for defining user information in most applications.

One of the many aspects that involves users is security including authentication, authorization, and other secure processes and protocols.

User security is a serious matter because we often see poor judgement used when implementing it.

Since more and more of our lives is now digital (bank accounts, memories with photos and videos), it's alarming to see such a poor state in user security.

Authentication

The goal is to provide means to confirm identity of user to allow access to certain features or content. It could be member-only type of benefits, or personal, even sensitive, information.

The oldest yet-still-very-much-in-use form is the Username & Password (U&P).

The new, now old, kid on the block is Secure Delegated Access (SDA). This is what Facebook, Google and such provide to their users: allowing other sites to authenticate them without having to worry about providing another (or the same) username and password.

The last commonly used form is Multi-Factor Authentication (MFA), which comes in different flavors. It always involved something you know (password, pin, etc.) and something you have (hardware/software token). In extreme cases it also involves something you are (biometric data, fingerprint, iris scan, etc.).

Problem: Security Questions

One big problem is that more and more sites nowadays are adopting those higher forms of security, where users are required to provide more personal information, like security questions.
It's a good thing when a system prompts a user to choose and answer 3 or more security questions, but if that same user does it on a dozen or so web sites, wouldn't the security as a whole be lessen by the weakest site in this pool?
Ask yourself: how many times have you answered the question about your first pet's name? your mother's maiden name? the color of your first car?

I sign up for CitiBank, pick and answer three security questions. I feel access to my bank accounts is safe.
I sign up now for FictionalMomAndPop.com web site selling woodworking materials and tools that I need want, but they require me to pick and answer three security questions as well. How do I feel now?
Imagine those security questions are exactly the same CitiBank provided me with. Any developer would just mindlessly copy the questions...if it's good for CitiBank, it must be good for my site too, right?
That amateurish web site surely has a lot less security infrastructure and processes in place than a multinational banking and financial services corporation like CitiGroup.

Imagine now those questions are different than those from CitiBank, and a dozen small-to-medium sites that I use from time to time do the same. I'm basically giving away easy-to-hack personal information that could be used to gain access to more serious stuff.

How secure does it all feel now?

Gone Phishing[1]

Another very widespread infection is Self-service Password Reset.
It's the simple process that allows a user who has either forgotten the password or been locked out for any reason to reset his or her access to the system.

Most implementations are based on providing a simple user name or email and have the system send an email to initiate a password reset (upon confirmation of the request).
Seems like a fine process but it's a broken process, vs. a continuous one. The user waits for an email to continue the reset process and it's been in use for so long that by now everybody expect such process. Yet the details of it are never clear: what does the "reset password" page I'll land on look like? What will I be asked to do exactly?
In this situation it's easy for anyone to send out an email, faking a password reset has been requested and providing a link to a fake page for the user to land on. That page will look like the legitimate site (logo, look and feel, etc.) but its goal will be to get more information or even collect the new password the user will enter (users tend to use the same set of 3-5 passwords[2]).


Other implementations keep the process very much continuous, where the user doesn't need to leave the site, thus no longer prone to phishing (at least at that level). But those often use security questions, providing another mean for authentication. Upon successful answer, user can then reset his or her password.
And now we're back to the security question problem mentioned above...

Solution (sort of)

It should be obvious by now that the real solution is not just technical: it's about providing the right amount and the right security. It's about being realistic, and not implementing bank-level security for a jam-making community site for example.

Defense in depth is the humble realization that, of all the security measures you implement, a few will fail because of your own carelessness. It's good to have a few backups, just in case. 

- Ben Adida (highly respected security expert)

If your site is not storing credit card information, personal health information (PHI), or money information (tax ids and such), then don't sweat it: go for SDA first, and if that doesn't work for you, go for simple U&P form.

If you're storing very sensitive information, it's very likely you have to follow some pre-established rules and/or laws (e.g. PCI compliance for credit card info and HIPAA laws for healthcare).
But for anything in between (e.g. it's not PHI, but healthcare client information, including some care data), there are way to mitigate the risks, and going with a simple U&P with password policy is a very sound approach. You can build tighter security on top of U&P as you grow and risks get more likely.

On a side note, Google provides a good list of security features and how to implement them. They put in place multi-factor authentication a while back, called 2-step verification [3]. At the moment, only a 2-factor authentication is available, with a hardware form as well I believe (any device FIDO compliant).
The idea here is to use another form to prove identity and the best known right now is a phone (or say a USB key).
When authenticating from a new not-yet-registered device, the system will send a code in the form of SMS or automated call, to enter on the site to prove identity.
This kind of extra feature adds to security without compromising personal information.

User Accounts

I'll explain more in details the foundation of user security in upcoming posts. But most (if not all) will affect the state of a user's account.
For example, after failing three or more password attempts, a user might see his account locked for a certain period of time.

Here is a list of some of the attributes commonly found in applications related to security:

• expired: Indicates whether the user account has expired
• locked:  Indicates whether the user account has been locked.
• lockExpiry: Indicates the time when the lock will expire (if it ever will)
• credentialsExpired: Indicates whether the credentials (e.g. password) have expired
• credentialsExpiry: Indicates the time when the credentials (e.g. password) will expire
• enabled: Indicates whether the user account has been enabled or not.

To be continued...

There's a misconception that passwords are utterly flawed and there's also a false sense of security as soon as passwords are implemented. As U&P is a widely used form of authentication, I'll write a post dedicated to passwords.

Security goes beyond passwords obviously so I'll also post about security images, inactivity, trusted devices and more

Stay tuned!

Resources

[1] Phishing, Wikipedia

[3] 2-Step Verification, Google

[2] Password Security: What users know and what they actually do, Shannon Riley