It is possible to eliminate the use of passwords for account credentials and instead use a side channel such as email to send a token. See History of Email-Only Auth — A new-ish idea since 2012.

What is the impact on security?

Using email for the side channel, a typical passwordless flow looks like:

In the sign-in screen, the user provides their email address. The system emails a link containing a secret token. On opening the link the session is authenticated.

This approach can also use SMS:

In the sign-in screen, the user provides their phone number. The system sends an SMS with a secret token. On redeeming the token the provider is authenticated.

This new approach is related to the older practice of password resets via email. In the password reset case, a token is sent that grants the recipient the power to reset the password.

Baseline Flaws

If passwordless sign-in has vulnerabilities that it inherited from password resets via email, there is no loss of security. These flaws are regrettable but are not caused by the new system.

Spam

Spam can be disguised as a passwordless sign-in. In this form it might trick anti-spam software into letting it pass through to the end user. It might also fool recipients into opening the message.

The spam would use the appearance of legitimate business as camoflage.

Defense: maybe it’s possible to hide user-visible text and only show less easily manipulated facets of the message, such as the certificate of any link target. Extension Protocol for Passwordless Login could be used to facilitate this.

Unsafe Browsing

The message sent to the side channel usually contains a link to open. There is an expectation that these messages will only be sent for bona fide reasons, on request.

There is no guarantee that the link was sent by request. A malicious party can send a harmful link.

The link destination might contain a direct exploit such as a Java applet which implants malware. It might contain an XSS attack.

The link destination might work by social engineering, such as a 419 scam or a phishing form.

Defense: user agents should show the domain and certificate for any link to be visited. User agents could scan link targets for aggressive and risky behaviors, for example using the Google Safe Browsing tool.

External Password

The security of a passwordless system backed by a third party SMS or email account relies on the security of that backing account. That backing account is probably protected by a password.

Most users use weak passwords, even for important accounts. So the backing account is probably vulnerable to brute force.

Most users reuse passwords across sites, so the backing account can probably be compromised if the same password has been used on any other site which has had its password database compromised.

Defense: the more sites use the passwordless approach, the less of a danger this is.

Improvements

How does passwordless sign-in make an overall improvement in security? How is it more secure than password-based systems?

The new method eliminates passwords as an attack vector. There is no chance users will choose a weak password or reuse one from other sites.

Crackers can’t gain access by accessing the password database, so there is one less direction from which to attack.

There is no password database that might reveal passwords used on other sites, so there is less reason for crackers to attack.

New Vulnerabilities

New Bugs

New code and new security schemes are likely to contain vulnerabilities. It takes time for weaknesses to be found and fixed.

Defense: developers of new systems must do security audits. Developers should research security issues in papers like this one.

This family of issues affects all new code and is not specific to passwordless system. Over time it will disappear.

False Side-Channel

1. In the sign-in screen, attacker provides an email or phone number that they do not own.
2. The system sends a message containing a secret token.
3. Recipient mistakenly (or by deception) redeems the token, for example by clicking a link without understanding what it does.
4. System authenticates attacker’s session.

Defense: sites granting access must be skeptical of the party in the sign-in screen. On receiving the token from the side channel, the session that initiated the handshake must not be assumed to have any special relationship with the side channel.

If the party in the sign in screen is to be signed in, there should be a burden of proof to show that they are the same party that accepted the sign-in request to the side channel.

Example A:
1. Bona fide account holder initiates sign-in process in a web browser by entering a mobile phone number in a form.
2. On submission, the form asks for a PIN code.
2. A PIN code is sent via SMS.
3. Account holder manually enters PIN in web form.

Example B:

1. Bogus account holder initiates sign-in process by entering email address in a form.
2. Link containing token is sent via email.
3. Bona fide account holder opens link.
4. Session opened by bona fide holder is authenticated. Session of attacker is not authenticated.

Example C:

1. Bona find account holder initiates sign-in process by entering their own email address in a form.
2. Link containing token is emailed.
3. Bona fide account holder opens link in a new window, but in the same browser session as in step 1.
4. Shared session cookie between new window and original window allows original submission window to be authenticated.

Notice that in A and C, the original form window is safely authenticated only because of special precautions.

Summary

Passwordless systems using side channels for authentication have security properties that need to be addressed head-on.

Some security flaws associated with passwordless systems are shared with systems that have passwords but allow password reset using email or SMS, and so do not imply lessened security.

One important flaw is both new and specific to passwordless systems: false side-channel.