# Passwordless Authentication There are some things that need to be considered before adopting a passwordless authentication process for your system. Passwordless comes with some good points and with some potential downsides. First though ... # What is passwordless authentication Passwordless authentication is a mechanism that enables users to log in without a set password by proving that they have access to something. Passwordless is often associated with a one use code or link sent to the user via email or SMS. There are other options that can include making use of the [WebAuthn](https://www.w3.org/TR/webauthn/) standard. This post focuses on the implementations using SMS and eamil. # Why is it good Simply put, because passwords are terrible. # What's wrong with passwords We as the greater collection of web users have done a bad job with managing our passwords. We forget them, we make them easy to guess by keeping them short and basing them off personal information. If that wasn't bad enough we go and reuse them over and over and over again. These days we're living in a post breach world where username password pairs have been covertly traded and published both on secret/protected networks and in public pastes for years. There is a decent chance that any password that your users are using to secure their data within your system has been exposed. This means that it has the potential to be used as part of credential based attacks against your system. ## Credential based attacks Credential based attacks are attacks where a malicious actor takes a collection of username and password pairs and attempts to use them against your system. Two common types of these attacks are credential spraying where commonly used passwords are paired up with known email addresses and credential stuffing where username/password pairs from a beach in one system are used against an unrelated system. Both of these attacks rely on the fact that users are using bad or reused passwords in multiple systems. Passwordless authentication helps to protect against credential based attacks by ensuring that a malicious actor needs to have access to the users email account or mobile phone number before they are able to log in. This adds an additional step that is difficult to automate en masse. ## Users don't need to remember a password Passwordless authentication provides some potential user experience for your system. The cognitive load on a user is reduced by not being required to remember a password. By relying on the user having access to a communication mechanism rather than relying on remembering a password a user has one less point of friction when logging into a account. This is particularly useful for low touch systems where users are not logging in regularly. ## Users can skip sign up Because your users don't need to set a password they are able to skip a sign up process before entering your system. It may seem obvious but the same is true for password recovery mechanisms. Without passwords, password recovery mechanisms are not required. Meaning that there is one less piece of software that needs to be maintained and one less way that you system may be misused. # What's the downside to passwordless authentication Like any software development tool or technology passwordless authentication has some bad points to balance out the good. ## Passwords are well known Terrible or not the paradigm of passwords is well entrenched with users. Users have come to expect that their data will be protected by their knowledge of a username and password pair. Some users will be uncomfortable with the change. ## Email is slow Sending a one time link or code via email can be unreliable. There has been a lot of work put into hardening the email system so that it is more resistant to spam. Unfortunately when sending an email with a one time code or link to users it's easy to run afoul of spam filters, after all you're sending out automated emails. Because email is slow it is easy for users to blame the system when they don't receive an email, even if the reason that they're not receiving an email is that they have misspelled their email address. If email is unreliable the solution may be to just use SMS... ## SMS has security issues SMS has previously been shown to be exploited by sim jacking attacks. These attacks involve a malicious actor using social engineering techniques to have a mobile phone provider port the targets phone number to a sim card that is owned by the malicious actor. They are then able to bypass security checks, like passwordless authentication or SMS MFA, and gain unauthorised access to a user's account. This is a risk because... ## Passworless is single factor authentication It is important to understand that while passwordless authentication can help to protect against credential based attacks. It is still a single factor method of authentication. Any system will be more secure with the addition of more authentication factors. This is still true for systems that are using passwordless authentication. Adding additional factors to passwordlesss authentication can be a difficult sell because... ## MFA and passwordless is an odd user experience Passwordless authentication presents potential UX issues when adding multi-factor authentication. Users may find the experience of being asked to enter a code from second authentication factor odd after having already gone through a login process that involves entering a code or clicking on a link sent to them. # So should I use passwordless There is no good answer to that. For any security question you need to understand what the risk factors your protecting against are. Passwordless authentication seems to do a good job of protecting against automated credential based attacks. However it will present an odd user experience if you want to provided an authentication experience that is hardened against account take overs by using multi factor authentication.
Testing functions that use local storage with Jest
Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Comments
Post a Comment