Who are you? What are you allowed to do?

In tech circles, those two questions are formally known as authentication (“who are you?”) and authorization (“what are you allowed to do?”) and are collectively referred to as “auth”.

Clearly, service providers have a vested interest in making sure that they know the correct answers to both of those questions; they don’t want to allow the wrong user to log into an account and they also don’t want to allow users to interact with data that they are not permitted to access.

Authentication and authorization are shared responsibilities between service providers and end-users.

This shared model is necessary to achieve the ultimate goal: avoiding unauthorized account access and keeping data secure. Neither service providers nor end-users can achieve that goal single handedly.

Service providers are responsible for implementing strong, easy to use security features for end-users. They are responsible for documenting how those features work, maintaining them over time, and promoting their use. In turn, users are responsible for taking advantage of those security features and actually enabling them. A user facing feature doesn’t provide any effective security if it goes unused.

Service providers are also responsible for implementing transparent security mechanisms on behalf of end-users. However, regardless of how much effort is taken to make a service secure, there will always be some action that careless users can take to put their account at risk. Users are responsible for educating themselves about the best practices for staying safe online so that they can avoid common pitfalls that are outside the control of service providers.

Let’s explore some specific examples to clarify why service providers and end-users both have a role to play in achieving effective security when it comes to authentication and authorization.

Imagine that you are a service provider

You have a team of the most talented engineers, designers, writers, researchers, marketers, and do-ers of all kinds. You have overwhelming internal support and the necessary budget to do everything within your power to build an inherently secure service.

It sounds like you’re setup for success! Surely, you’ll reach the ultimate goal of achieving effective security, right?! Frustratingly, even after taking all of these necessary steps to secure your service, end-users play a huge role in determining whether their interaction with your service is actually secure.

Here is a (very) non-exhaustive list of security related projects that your team might have tackled:

You implement password best practices

• You enforce minimum password requirements and explain to users how to create a strong passphrase.
• You prevent users from using commonly known passwords like “password”, “123456” and “qwerty”.
• You follow best practices for securely storing passwords in your database.
• You even have a recommendation on your signup page for users to download and use a password manager.

And then a user ends up reusing their favorite password that they use for every other service. One of those other services isn’t as diligent as you are, stores the password insecurely, has a breach, and now the user’s password is in the hands of a hacker. That hacker happily tries the user’s password on your service and is pleasantly surprised when the login succeeds.

This scenario is a scary reality. LastPass found that “91% [of people] know there is a risk when reusing passwords, but 61% continue to do so.” Google analyzed 1.9 billion usernames and passwords exposed via data breaches and estimates that “7-25% of exposed passwords match a victim's Google account.” For a real world example, read about how a Dropbox employee’s password reuse led to the theft of over 60 million user credentials.

You configure HTTPS so that user connections are secure

• You make sure that all connections to your service are served over HTTPS so that the green lock appears in the browser address bar to inform users that connection is secure.
• You use an EV certificate so that your company name appears next to the green lock in the browser address bar for additional user trust.
• You make sure that you support only the recommended versions of TLS, configure the strongest cipher suites and important features, and get high ratings from respected TLS analysis tools.

And then a user gets an email that looks like it came from you, clicks the link asking them to login, and doesn’t verify the URL in the address bar before entering their username and password. They’ve just fallen victim to a phishing attack and handed their credentials over to a hacker.

The Anti Phishing Working Group (APWG) stated in their 2016 Q4 report that phishing attack campaigns in 2016 shattered all previous years’ records with over 1.2 million phishing attacks, a 65% increase over 2015. To give an example closer to home for all of those Gmail users out there, Google recently found that “victims of phishing are 400x more likely to be successfully hijacked compared to a random Google user.”

You support multi factor authentication (MFA)

• You support the best implementations of two factor authentication (2FA).
• You support the best biometric authentication options available in the industry.
• You implement adaptive authentication and dynamically change security and authentication policies based on user and device context.
• You allow administrators to force all users within the organization to enable multi factor authentication (MFA) on their accounts.

And then an administrator chooses not to check the box next to “require MFA on all accounts” and users in the organization choose not to enable MFA. That password leaked in the phishing attack now grants full access to the user’s account.

Duo, a leading provider of two factor authentication (2FA) solutions, found that only ~28% of people in the US use 2FA and only ~56% even knew what 2FA was before their survey. Pew Research Center conducted a cybersecurity quiz in which only 18% of users could correctly identify multi factor authentication (MFA). The adoption rates of MFA are disappointingly low and general education is clearly lacking. However, even tech folks have experienced account hijacks that could have been prevented by MFA. ArsTechnica reported that Fox-IT, a Dutch IT firm, “fell victim to a well-executed attack that allowed hackers to take control of its servers and intercept clients' login credentials and confidential data. The biggest lapse on Fox-IT's part was the failure to secure its domain register account with two-factor authentication.”

You specifically address organizations with multiple users

• You allow organizations to provision accounts for each individual user.
• You implement robust audit capabilities so that administrators can verify which employees accessed certain data and how they used it.

And then users decide to share a single account and password instead of creating one for each employee in the company. Perhaps, one of those employees uses the shared account for something nefarious; good luck figuring out who is responsible!

Laughably, a similar scenario played out recently when UK politician Damian Green got into hot water for allegedly accessing pornography on his government computer. A colleague, Nadine Dorries, jumped to Green’s defense implying it could have been someone else on his PC using his identity.

My staff log onto my computer on my desk with my login everyday. Including interns on exchange programmes. For the officer on @BBCNews just now to claim that the computer on Greens desk was accessed and therefore it was Green is utterly preposterous !!

— Nadine Dorries (@NadineDorries) December 2, 2017

Troy Hunt, a well known security expert, explained why sharing a single account in this way is problematic and also highlighted many common tools which allow users to maintain individual accounts while still sharing data to get their jobs done.

You provide robust permission framework to help restrict access to data

• You implement a robust permission framework which allows administrators to limit sensitive data to smaller groups of users based on their roles.
• You have a team of tech writers who develop useful tutorials, documentation, and examples of how to get the most value out of the permission framework.

And then a user decides to assign everyone in the organization the administrator role. Now, all users have access to all data within the organization and the intern decides to access sensitive customer data just for fun.

Imagine that you are a highly motivated user

You have taken the initiative to research and understand all of the cybersecurity best practices recommended by industry experts. Where appropriate, you have spent a small amount of money so that you have the best tools available to help you stay secure.

It sounds like you’re setup for success! Surely, you’ll reach the ultimate goal of achieving effective security, right?! Frustratingly, even after taking all of these necessary steps to secure your account, the service provider still plays a massive role in determining what level of security you can actually achieve.

Here is a (very) non-exhaustive list of steps you might have taken to remain secure:

You are prepared to enable multi factor authentication (MFA)

• You purchase a few U2F security key that works with your computer and your phone so that you can leverage the strongest two factor authentication (2FA) available on all of your devices.
• You look forward to enabling Push Notification 2FA, such as Google Prompt, where available.
• You are ready to swipe your thumb, scan your iris, or take a photo of your face while enabling biometric authentication options.

And then the service provider claims that the knowledge questions they require you to fill out qualify as 2FA when combined with your username/password and that your account is secure. Of course, you know that knowledge questions count as a duplicate knowledge factor rather than real 2FA and are so weak that they border on useless anyways. Your account remains highly vulnerable since you cannot enable a possession or inherence factor of authentication to achieve actual 2FA.

How about losing millions of dollars for a real world example? Hackers stole millions of dollars worth of bitcoin from a victim’s account that had SMS based 2FA enabled. Wait, what?! They got hacked even with 2FA enabled? Unfortunately, not all 2FA implementations provide the same level of security and SMS is notoriously one of the weakest. The victim’s account likely would have been safe with a strong type of 2FA, but imagine how trivial it would have been for hackers if no 2FA was enabled at all!

You use a password manager

• You use a password manager to ensure that each service has a unique strong password.

And then the service provider stores your password insecurely in the database, has a breach, and your password is now in the hands of a hacker. Since the service provider doesn’t implement actual 2FA, your password and some easily answered knowledge questions allow hackers to easily hijack your account.

It is shocking and frightening that even with all of the readily available resources that cover, in great detail, the best practices for storing passwords in a database, some service providers throw security out the window entirely and store passwords in plain text. In late 2015, Troy Hunt reported that 000webhost.com, a low priced web host, was hacked and lost 13 million user emails and plain text passwords. Similarly, The Hacker News reported in mid 2016 that VK.com, Russia's biggest social networking site, lost 100 million email addresses and plain text passwords in a breach.

You install browser extensions to secure your web traffic

• You install HTTPS Everywhere in your browser so that your connections to websites default to secure HTTPS as much as possible.

And then the service provider only supports deprecated TLS versions, such as SSLv3, or maybe doesn’t even support HTTPS at all. Now, anyone on the same network as you can easily record the data you send to the service, such as your username and password; the hacker sitting next to you in the coffee shop now has your login credentials.

Let’s Encrypt, a project that offers free TLS certificates, reports that the Web went from 46% encrypted page loads to 67% in 2017 - a gain of 21 percentage points in a single year! This is truly encouraging news, but it also highlights that a third of the Web is still using HTTP and is entirely unencrypted! Hardenize reports that only 38% of the top 500 websites are using well configured HTTPS; 19% of the top 500 are using configurations with severe deficiencies. As recently as late 2017, a UK bank called NatWest was serving their homepage over insecure HTTP.

You try to follow the principle of least privilege

• You work with the security and compliance teams at your company to document which information employees need access to in order to efficiently do their jobs. You sit down to configure the service to enforce those permission policies.

And then the service doesn’t support the concept of an organization with individual user accounts and you’re forced to have multiple employees share credentials to a single account. You don’t have any ability to limit access to data based on an employee’s department or role. Everyone has access to everything! Also, you cannot enable 2FA for the account since it is shared between many people and they cannot all share the same trusted device, thumb print, or iris.

We’re all in it together

With a steady cadence of massive data breaches making front page news, cybersecurity is more present in the public conversation now than ever before.

In addition to the less known examples discussed in previous sections, there are many high profile cases where fault lies clearly with the service provider. Equifax exposed the data of 147 million people after it failed to patch server software for two months. Hackers stole the data of 57 million customers and drivers when Uber engineers shared a secret credential in a code repository on GitHub. Sadly, there are too many examples to list here; it is quite clear that service providers have a massive amount of work to do in order to fulfill their responsibilities of implementing secure systems.

Unsurprisingly, users are having trouble trusting service providers to keep their data safe. However, as we’ve discussed, users also have an important responsibility to educate themselves to avoid contributing to the problem. According to a 2017 Pew Research Center survey, “many Americans do not trust modern institutions to protect their personal data – even as they frequently neglect cybersecurity best practices in their own personal lives.”

Tenable conducted a survey in late 2017 which draws similar conclusions on the sad state of cybersecurity literacy among users. They wrap up their report by highlighting the same tenent of the Shared Responsibility Model discussed in this essay: “[Organizations] need to lead the way in basic security practices that keep their customer and critical business data safe. But individuals must do their part, too – both as consumers and, in many cases, as employees of those same enterprises – and that starts with cyber literacy.”

Authentication and authorization are shared responsibilities between service providers and end-users.

All Things Auth is dedicated to helping service providers and end-users alike navigate those shared responsibilities and make progress towards the ultimate goal: avoiding unauthorized account access and keeping data secure. Neither group can do it alone. We’re all in it together.

Thanks to Jordan Fischer, Greg Busanus, Geoff Kimble, Mackenzie Walker, Dayne Seiden, and Reuven Gonzales for reading drafts of this.