Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices

Paul Wagner

, Kris Heid

and Jens Heider

Fraunhofer Institute for Secure Information Technology, Rheinstraße 75, 64295 Darmstadt, Germany

Keywords:

FIDO2, Security, Authentication, Remote, Webauthn.

Abstract:

Nowadays, passwords are the prevalent authentication mechanism, even though it is proven to offer insufﬁ-

cient protection against cyber crime. Thus, FIDO2 was released with a more secure authentication mechanism.

FIDO2 enables authentiﬁcation with cryptographic hardware, such as USB sticks, NFC cards or in the smart-

phone integrated chips. A device with FIDO2 support is required to implement the whole FIDO2 stack and

offer the required interfaces for the security hardware. However, many systems like for example Smart TVs

can not make use of FIDO2 due to the lack of HW interfaces or the usage of outdated software. To overcome

this, we present Remote WebAuthn, which enables secure authentiﬁcation on such restricted devices through

a remote authentication from a secondary, FIDO2 compatible device, such as a smartphone. We evaluate our

approach to have better usability compared to FIDO2 while maintaining most security advantages.

1 INTRODUCTION

Passwords are already the dominating authentication

method for over the last decades, even though they

are known to provide insufﬁcient protection(Bonneau

et al., 2012; Bonneau and Preibusch, 2010). Con-

stantly changing passwords, long and random enough

passwords or individual passwords for each service

are accepted by users, but mostly hated concepts

due to their inconvenience. Also, security enhance-

ments such as two-factor-authentiﬁcation are not well

adopted by users (Voigt, 2019). This leads to the con-

clusion that many users sacriﬁce security for usabil-

ity. As a way out of the password dilemma, FIDO2

authentication has been published. FIDO2 allows au-

thentication via a hardware security key, such as a

USB stick, NFC card/tag or a Bluetooth device. Such

a key can be used as full authentication mechanism

or as a second factor authentication together with for

example a ﬁnger print or a pin to unlock the security

key

. The user connects the security key and legit-

imates the request for every authentication. In gen-

eral, FIDO2’s security is commonly well perceived

and handled as the successor of passwords(Lyastani

et al., 2020), the only stumbling block might be the

usability among all devices. A device that should

https://orcid.org/0000-0002-6125-574X

https://orcid.org/0000-0001-7739-224X

https://orcid.org/0000-0001-8343-6608

https://www.w3.org/TR/webauthn/

leverage FIDO2 must on the one hand support the

full WebAuthn protocol stack and on the other hand

also the interfaces for the security key (NFC, USB or

Bluetooth). Many IoT devices or Smart TVs also re-

quire authentication for online services, but have very

restricted hardware and software interfaces hindering

the usage and the spread of FIDO2. For such de-

vices, passwords would still be required, leaving an

open area for attackers. To overcome these ﬂaws, we

present Remote WebAuthn, utilizing the central ele-

ments of the WebAuthn standard. As a beneﬁt, we

are allowing a remote authentication through a sec-

ondary device, instead of connecting the security key

to the device requiring authentication. Thus, the user

can freely choose interface requirements and use inte-

grated hardware keys on restricted devices. This work

provides a proof of concept architecture and imple-

mentation for Remote WebAuthn in Section 3. We

evaluate our concept based on sophisticated usabil-

ity(Bonneau et al., 2012) and security(Schneier, 1999;

Microsoft, 1999; Kohnfelder and Garg, 1999) crite-

ria in Section 4. The evaluation is also done with

password-based authentication and FIDO2, where we

compare our approach against. Finally, we are con-

cluding the pros and cons of our approach and give an

outlook on future work.

368

Wagner, P., Heid, K. and Heider, J.

Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices.

DOI: 10.5220/0010192703680375

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 368-375

ISBN: 978-989-758-491-6

2 AUTHORIZATION METHODS

Authentication can be reached by different means:

knowledge, possession or biometric properties. Each

of which can be used as a single factor authentication

mechanism, or they can be combined to increase the

security level.

Biometric properties like face recognition or ﬁn-

ger prints are in practice only used for non-critical au-

thentication or as a second factor. These mechanisms

have been proven to be easily spoofed and also spe-

cial hardware is required to capture these biometric

properties.

Password based methods represent a simple sub-

type of knowledge based authentication. Because of

their simplicity in implementation, they still consti-

tute the predominant form of authentication on the

web (Reese et al., 2019). There are several practices

to add an extra layer of security, such as time-based

tokens (OTP) and hardware keys (Reese et al., 2019).

Since all of these approaches come in addition to reg-

ular password inputs and hence directly badly affect

the usability (Florêncio and Herley, 2010; Bonneau

et al., 2012), they are not further considered in this

work.

Possession based authentication methods like

FIDO2 can either be represented by integrated hard-

ware or external security keys, which connect via

USB, NFC or Bluetooth (FIDO-specs, 2020). In any

case, each identity is stored as an individual key pair,

that can be veriﬁed using a challenge response algo-

rithm. While the public key should be returned to the

relying party upon creation, the private key must not

ever leave the hardware token. On the technical side,

FIDO2 is based on two pillars: CTAP speciﬁes the

communication between hardware token and client.

On the other hand, WebAuthn describes the interface

between client and application. Since this is mostly

a browser-website relationship, WebAuthn endpoints

are typically accessible via JavaScript. The bridge be-

tween CTAP and WebAuthn can either be divided be-

tween browser and operating system or implemented

in browser context completely. Since no ofﬁcial op-

erating system interface is designed, browsers relying

on the ﬁrst approach must offer explicit FIDO2 sup-

port for the concrete system they are running on.

In both cases, FIDO2 needs explicit software sup-

port and at least one compatible interface (USB, NFC

or Bluetooth) or an integrated authenticator on the

host system. Krypton (Krypton, 2020) is close to

Remote WebAuthn in some regards. It allows users

to authenticate against almost every FIDO2-capable

website with their smartphone. To do so, Krypton

requires the installation of a desktop browser plu-

gin. It can then be paired with a smartphone, run-

ning Krypton’s authenticator app. In contrast, Re-

mote WebAuthn does not require explicit device pair-

ing and is therefore also usable on temporary devices

like kiosk terminals. Despite all components being

open source, Krypton is limited to their own infras-

tructure, hence it is not possible to use third-party au-

thenticator apps. In addition, only integrated authen-

ticators can be used, making it mutual exclusive to the

use of external FIDO2 security keys. This paper in-

stead proposes an open approach, that can be used on

both public and private infrastructure.

3 REMOTE WEBAUTHN

The idea behind remote WebAuthn is to bring the se-

curity of FIDO2 to devices with limited IO interfaces

or software support, such as Smart TVs or public in-

ternet terminals. From the user perspective, a remote

WebAuthn log in ﬂow would look like follows: The

user wants to sign in to a service on the Smart TV,

such as a video streaming service. Instead of provid-

ing username and password, the TV presents a QR-

code on its screen. The user scans the QR-code with

his smartphone, which then opens an authentication

app. This allows picking a key ﬁle previously asso-

ciated with the service. Finally, by clicking the pre-

sented allow button on the smartphone, the user grants

the Smart TV to access the video streaming service.

The described abstract behavior is highlighted from

the technical perspective in the following.

3.1 Concept

The key principle behind Remote WebAuthn is to

separate the FIDO2 client across multiple systems:

While the ﬁrst part remains on the restricted device

on which the user wants to log into a service, the sec-

ond part handles any authenticator communication on

a dedicated system. For demonstration, in this paper

the combination of a Smart TV as service client and a

mobile phone as authentication device is used. Both

parts communicate over an internet tunnel in back-

ground, but hide that complexity from the applica-

tions context. The parts in Figure 1 are deﬁned as

follows:

Relying Party Client (RP Client). The RP Client is

running on the system that should authenticate

against a service, for instance a Smart TV. There-

fore, it is responsible for any Relying Party (RP)-

related communication. WebAuthn commands are

always structured into two parts: The request is sent

from RP to the authenticator and contains either a

Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices

369

Relying Party

FRONTEND

Relying-Party

Client

Authenticator

Client

Authenticator

PUBLIC KEY

PRIVATE KEY

3. Proxy-Server URL

Session ID

Symmetric Session Key

Initial Payload Hash

Proxy-Server

1. WebAuthn-req.

9. WebAuthn-resp.

5. CTAP-req.

6. CTAP-resp.

Network-connection

API-connection

Connection to Security-Key

Optical transmission (QR)

Figure 1: Concept of Remote WebAuthn.

credential creation request or a signable challenge.

In reverse, the response carries the resulting crypto-

graphic signature. Therefore, the RP Client always

starts by submitting a request to the Auth Client.

When receiving the response, the authentication is

ﬁnished by passing the WebAuthn payload to the

calling RP.

Authenticator Client (Auth Client). Supplementary

to the RP Client, the Auth Clients handles the com-

munication with the actual FIDO2 authenticator,

which may be integrated or attached over USB,

NFC or Bluetooth. After receiving the request

submitted by the RP Client, the speciﬁed operation

is executed and its response returned to the RP

Client. Because of their direct camera and security

hardware integration, smartphones are used as visual

example in the course of this work.

Proxy Server (Proxy). Since the communication be-

tween RP Client and Auth Client equals a one-shot

ping-pong game, the Proxy simply has to forward re-

quests and responses to the opposite party. Thus, the

main task is to coordinate and close the session as

soon as the authentication completed.

The communication between client and the Proxy is

implemented using Web Socket Secure (WSS), which

provides TLS transport encryption by default. To

also hide exchanged data from the Proxy, any trafﬁc

is additionally end-to-end encrypted with AES. Both

Proxy session and symmetric encryption keys are ini-

tialized by the RP Client in the ﬁrst place. After ob-

taining a session id, it is transmitted to the Auth Client

as QR code alongside with other relevant initialization

features. Following the previously introduced device

setup, the code is scanned from TV screen using a

mobile phone with integrated authenticator.

In summary, the QR code contains the following data:

Base URL. When using an integrated scanner, the

Base URL is only meant as fallback that shows up in

case the user scans the code with a wrong scanner ap-

plication. If Remote WebAuthn by contrast relies on

an external scanner, the URL should instead contain

a deep link, that is registered on the operating system

and tells the scanner application to open the correct

Auth Client. The consideration, whether to use in-

tegrated or external scanners, is further described in

Section 3.1.1.

Proxy URL. Deﬁnes the Proxy to connect to via

WSS.

Session ID. Identiﬁes sessions uniquely and must

therefore be issued by the Proxy.

Symmetric Session Key. Similar to the Session ID,

the RP Client generates a Symmetric Session Key

upon initialization. This key is used for end-to-end

encryption during the whole dialogue, so that neither

the Proxy nor underlying infrastructure gets access to

exchanged data.

Initial Payload Hash. To ensure integrity, the en-

crypted WebAuthn payload is hashed after submis-

sion. In consequence, each QR code is also directly

linked to a speciﬁc WebAuthn transaction. The fol-

lowing security analysis points out, that this makes

phishing signiﬁcantly harder for attackers.

Encrypting trafﬁc between both clients ensures higher

security, but also makes it impossible for Proxys to re-

view package contents. Therefore, especially publicly

driven Proxys are susceptible to abuse for other appli-

cations like ﬁle sharing. However, WebAuthn trans-

actions contain only a single request-response pair,

hence the Proxy also limits the maximum message

count to a single initial message from RP Client to

Auth Client and a response in reverse direction after-

wards. In combination with a heuristic message size

limit being just sufﬁcient for WebAuthn payloads,

abusive data-exchange scenarios become much more

impractical.

3.1.1 Relying Party Client

As mentioned before, the RP Client builds a bridge

between RPs and Proxys. There are two different ap-

proaches for a RP Client implementation:

Implementation as Browser Plugin. The key prin-

ciple of an implementation as browser plugin is to

override existing interfaces, which were formerly

used for native WebAuthn authentication. After

invocation, the plugin handles full communication

with the smartphone, thus the whole process is

transparent for the site. This allows great com-

patibility alongside websites, which already sup-

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

370

port WebAuthn authentication. However, using this

method requires not only full-stack FIDO2 support,

but the RP Clients also needs to explicitly support

Remote WebAuthn in form of a browser plugin. This

contradicts with the goal of being independent of the

RP Client system environment.

Integration inside Website Context. To circumvent

the problem of missing host support, it is also

possible to fully implement Remote WebAuthn in-

side website context. Instead of calling default

WebAuthn browser APIs, the RP Client embeds an

own JavaScript library with a similar interface. After

invocation, the website itself sets up communication

with the Proxy and displays a QR code for initializa-

tion.

Since one premise of this paper is to bring the security

enhancements of FIDO2 also to outdated devices like

Smart TVs, only the latter approach is further consid-

ered in the course of this work.

3.1.2 Authenticator Client

As RP Client counterpart, the Auth Client joins an ex-

isting Proxy session and forwards incoming requests

to an attached authenticator. Any required initializa-

tion data is transmitted via QR code, hence the Auth

Client must provide an option for reading them. The

scanner module can be implemented both externally

and internally. When using the ﬁrst approach, authen-

tication QR codes are preceded by a deep link preﬁx,

that allows external scanners invoking the target au-

thenticator application. Since deep links can be used

from any foreign application context, this opens a new

attack vector on the other hand. Alternatively, the lat-

ter approach describes a scanner baked into the bi-

nary, so that QR code data never leaves the applica-

tion sandbox.

3.1.3 Authentication Flow

Figure 1 shows a simpliﬁed communication ﬂow for

Remote WebAuthn transactions. For starting a ba-

sic authentication, the RP backend initially generates

a cryptographic challenge. In parallel, the frontend-

embedded RP Client module opens a connection with

a Proxy. After receiving the Session ID, the RP Client

then builds a WebAuthn request object using the cryp-

tographic backend challenge. Combining the static

conﬁguration data, Session ID and the WebAuthn re-

quest hash, a QR showing a derived URL can be pre-

sented to the user. Even before scanning, the gener-

ated WebAuthn object can be sent out to the Proxy.

When the user picks up his smartphone to scan the

shown QR code, the Auth Client opens a Proxy con-

nection using the stored information. The Proxy then

Figure 2: Scan QR code from

restricted device on which to

authenticate user on.

Figure 3: Remote authenti-

cation: Choose identity key

from authenticator app.

releases the submitted WebAuthn request, so that the

Auth Client can answer it subsequently. Depending on

the Auth Client implementation and the requirements

speciﬁed inside the WebAuthn request, the user may

have to provide an additional biometric or knowledge-

based feature. The generated response is sent back to

the Proxy and then forwarded to the RP Client. Fi-

nally, the RP backend can verify the WebAuthn re-

sponse and its encapsulated cryptographic signature

using the users stored public key credential.

3.2 Example Implementation

The following brieﬂy describes our implementation.

The source code (RemoteWebAuthn, 2020) can be re-

viewed by the interested reader to get a deeper insight.

3.2.1 Proxy Server

A Proxy initializes and manages Remote WebAuthn

communication between the RP Client and Auth

Client. Besides the unique identiﬁer and connection

handles to both clients, each session contains a state

machine and a deferred payload cache as assets. The

state indicates, whether a WebAuthn request and re-

sponse have been already transmitted. In addition, the

payload cache temporarily stores the request in case

the Auth Client has not yet been connected.

The Proxy is designed to operate in a completely pas-

sive way. Therefore, outgoing Event Messages are

always a reaction of either incoming Request Mes-

sages or status changes such as a Auth Client join.

The following description provides an overview over

all Event Messages. For each message, the concrete

trigger action is speciﬁed:

session_assignment. As soon as the connec-

tion between RP Client and Proxy is established, a

Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices

371

Request

State

Start

Response

State

Final

State

forward_request

forwards_response

session_assignment

authenticator_join

request_submission

authenticator_join

response_submission

Request Message (Client → Proxy)

Event Message (Proxy → Client)

Figure 4: Proxy state machine.

session_assignment event containing the session

identiﬁer is emitted.

authenticator_join. This event has no func-

tional purpose, but notiﬁes about Auth Clients joining

the session and can therefore used for visual progress

updates.

request_submission. The

request_submission carries the WebAuthn re-

quest to the Auth Client, whenever the RP Client

submits a forward_request.

response_submission. In reverse to

request_submission, response_submission

redirects incoming WebAuthn responses via

forward_response back to the RP Client.

RP Clients initialize new sessions using the /session

endpoint, which then emits a session_assignment

event containing the session identiﬁer needed for QR

code creation. The Auth Client can instead use the

/session/{session_id} endpoint to join with its

particular session id.

3.2.2 Relying Party Client

As mentioned before, the RP Client is designed as

JavaScript library for the purpose of this paper. There-

fore, the only requirement is a JavaScript-capable

browser environment, which allows the RP Client

running even on elderly devices like Smart TVs. The

full functionality is encapsulated inside a Tunnel

class, which takes the basic conﬁguration via con-

structor and forwards authentication requests on func-

tion calls.

3.2.3 Authenticator Client

The related source code project(RemoteWebAuthn,

2020) implements a simple version of an Auth Client

as Android app, which relies on an external scanner

and hence registers a system-wide rwa: deep link

preﬁx. In this implementation, the request is then

passed to a software authenticator library for demon-

Table 1: Usability comparison chart.

PW FIDO2 RWA

U1 Memorywise-Effortless ✗ ✓ ✓

U2 Scalable-for-Users (✓) (✓) ✓

U3 Nothing-to-Carry ✓ ✗ (✓)

U4 Physically-Effortless ✗ ✗ ✗

U5 Easy-to-Learn ✓ ✓ ✓

U6 Efﬁcient-to-Use ✓ ✓ ✓

U7 Infrequent-Errors ✗ ✓ ✓

U8 Easy-Recovery-from-Loss ✓ ✓ ✓

✓ applies (✓) mostly applies ✗ doesn’t apply

stration purposes. For real-world implementations,

more secure options using integrated security hard-

ware or attached security keys should be chosen.

4 EVALUATION

This chapter compares Remote WebAuthn with

FIDO2 and the password based authentication. The

following analysis subdivides into two main sections:

First, the usability is compared using criteria from ex-

isting literature. In contrast, the second part focuses

on threat analysis by deducing appropriate scenarios

and applying them to all introduced approaches.

4.1 Usability

For usability comparison, the criteria of (Bonneau

et al., 2012) are applied. The following enumeration

ﬁrst summarizes the deﬁnitions and extends U2 by the

aspect of scalability using multiple devices. Then, Ta-

ble 1 applies the introduced criteria to all three ap-

proaches.

U1 Memorywise-Effortless. The authentication

does not require a password input. The password

based authentication of course does not match

this criterion, as the password itself represents the

primary asset. For FIDO2 and Remote WebAuthn

however, depending on the used authenticator

memory-effortless features like biometry can be

chosen.

U2 Scalable-for-Users. Using multiple accounts or

devices does not lead to an increased workload for

users. When targeting the highest possible secu-

rity for password based authentication, each rely-

ing party has to have its own passphrase. FIDO2

on the other hand may need multiple authentica-

tors when using various clients with different inter-

face requirements. Therefore, both approaches only

match one of two criteria. By contrast, Remote We-

bAuthn matches the criterion completely by extend-

ing FIDO2 with the possibility to use any client with

any authenticator.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

372

Table 2: Threat comparison chart.

PW FIDO2 RWA

T1 Auth. with stolen identity ✗ ✓ (✓)

T2 Auth. with compromised identity ✓ ✓ ✓

T3 Denial of performed auth. ✗ ✓ (✓)

T4 Auth. information exposure ✓ ✓ ✓

✓ applies (✓) mostly applies ✗ doesn’t apply

U3 Nothing-to-Carry. Users are not required to

carry a physical thing for authentication. This is only

fully true for the password based authentication, that

does only require remembering a passphrase. In-

stead, Remote WebAuthn requires carrying a smart-

phone as everyday object, whereas FIDO2 needs a

dedicated piece of hardware.

U4 Physically-Effortless. No physical interaction,

like pressing a hardware button, is required in order

to authenticate. All introduced approaches require

some form of physical interaction, either for typing

a password or for providing biometric features.

U5 Easy-to-Learn. Users need no domain speciﬁc

knowledge for performing authentication. This cri-

terion is fulﬁlled for all three approaches for different

reasons: The password based authentication is estab-

lished on the internet for decades and hence already

well-known for most users. FIDO2 by contrast just

requires plugging in an authenticator and performing

a simple action like a button press. Allowing ﬁne-

grained progress tracking, Remote WebAuthn on the

other hand enables relying parties to guide the user

step by step through the app installation and authen-

tication process.

U6 Efﬁcient-to-Use. The duration of a single au-

thentication process is appropriately short. While it

is hard to objectively measure the average duration

of each approach, all approaches can be conducted

in less than ten seconds as rule of thumb.

U7 Infrequent-Errors. Authentication tries do not

fail too often, if conducted properly. Since techni-

cal failures are hard to predict, this analysis is lim-

ited to human mistakes only. Therefore, FIDO2 and

Remote WebAuthn have an advantage over the pass-

word based authentication, as both approaches allow

alternatives to error-prone password typing.

U8 Easy-Recovery-from-Loss. Users can easily re-

cover their lost keys. In all cases, not the authentica-

tion providers, but the RPs itself are responsible for

managing lost credentials.

4.2 Threats

This section compares the security across all intro-

duced authentication methods. For this purpose, vari-

ous attack scenarios are described ﬁrst. For each case,

the different authentication variants are compared and

ﬁnally, the chosen scenarios are justiﬁed using the

STRIDE model (Microsoft, 1999).

T1 Authentication with Stolen Identity. In this

scenario, an attacker tries to impersonate the victim

by stealing his identity. This can either be achieved

by hijacking an existing authentication attempt, or

by passing a malicious authentication request to the

victim. The latter case additionally allows to choose

any RP instead of just the user-intended target

service. For every approach, an attacker could either

try to phish a foreign authentication by spooﬁng

the RP identity (T1a) or by intercepting the trafﬁc

between RP and client directly (T1b).

Password based: An attacker can simply entice the

victim to enter his password on a malformed in-

put form, for instance by sending a malicious email

or recreating the RP webpage under a similar do-

main. In most scenarios, stolen passwords even al-

low permanent access until their explicit invalida-

tion. Since this method is only founded on knowl-

edge, there is no effective countermeasure for sce-

nario T1a. T1b on the other hand can be closed by

implementing proper transport encryption.

FIDO2: Since FIDO2 is based on public key cryp-

tography, permanent takeovers require physical ac-

cess to the linked security key. Therefore, the only

possibility left, is to gain a temporary authentica-

tion by stealing or manipulation WebAuthn trans-

action data. In theory, an attacker could rebuild the

RP webpage and forward the original authentication

data to the user. Referring to T1b, another possibil-

ity is to replace the authentication request in transit.

Both scenarios are covered by the FIDO2 security

reference SG-2 and SG-3 (Lindemann, 2018).

Remote WebAuthn: On the RP Client side, Re-

mote WebAuthn extends FIDO2 by communication

with a central Proxy. While the FIDO2 subset is

already covered by its own analysis above, the ad-

ditional transfer can be divided into two assets:

• The whole trafﬁc between RP Client, Proxy and

Auth Client cannot be accessed due to Symmetric

Session Key encryption. Therefore, no WebAuthn

data can be spoofed or modiﬁed during transport.

• The initialization data on the other contains all

relevant data concerning the Proxy session. For

stealing a foreign identity, the attacker can create

an own RP session and forward the initialization

QR code to the victim using a trusted medium.

This is especially problematic when using deep

links for authenticator invocation, which can be

invoked from any application or website. How-

Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices

373

Scenario

T1a

Initialize

compromised

session

Forward

valid

QR code

Convince

victim to

authenticate

within

timeout

Create

malicious

QR code

Run

compromised

proxy

Compromise

existing

proxy

Set up

compromised

proxy

Modify

Initial

Payload

Hash in

QR code

subsequently

Figure 5: Attack tree for Remote WebAuthn scenario T1a.

ever, users still have to conﬁrm each authentica-

tion explicitly. In order to decrease fraud, ini-

tialization QR codes also contain the WebAuthn

requests cryptographic hash, which limits code

validity to the FIDO2 transaction timeout. This

measure prevents popular mail phishing and re-

quires the attacker to create and forward the QR

code or deep link in realtime instead.

T2 Authentication with Compromised Identity.

Instead of impersonating someone’s identity, an

attacker tries answering to a foreign authentication

request with his own credentials. Afterwards, users

may expose personal data to the attackers account,

since they are not aware of using a malicious

account.

Password based: The attacker could modify the

password in transit and hence authenticate against

the RP instead of the user itself. This attack can be

foiled by securing the trafﬁc with transport encryp-

tion.

FIDO2: If the attacker gets access to the commu-

nication between RP and client, he might be able to

answer the authentication request with an own secu-

rity key. This scenario is covered by security goal

SG-11 (Lindemann, 2018).

Remote WebAuthn: In addition to the described

FIDO2 risks, there are the same conceivable scenar-

ios for injecting a foreign authentication as in T1.

Under the assumption, that the attacker cannot ac-

cess the QR code containing the Symmetric Session

Key, WebAuthn transaction data cannot be stolen or

modiﬁed in transit. Therefore, for performing such

an attack the attacker must get inside the victims

physical range in order to scan the code.

T3 Denial of Performed Authentications. In this

attack, the victim itself represents the attacker

by denying an actually performed authentication

approach. To succeed, there must be possibilities for

Scenario T2

Authenticate

with

compromised

identity

Scenario T4

Steal

authentication

related data

Scenario

T1b

Inject

malicious au-

thentication

request

Gain access

to WebAuthn

commu-

nication

Steal

Symmetric

Session Key

Scan foreign

QR code

within ﬁeld

of view

Gain access

to encrypted

WebAuthn

commu-

nication

Run

compromised

proxy

Compromise

existing

proxy

Set up

compromised

proxy

Gain access

to plaintext

interface

Client↔Proxy

Figure 6: Attack tree for Remote WebAuthn scenarios T1b,

T2, T4.

attackers to steal foreign identities. Therefore, this

attack vector is only possible if and only if there’s

a derivation for attack tree T1 in the respective

scenario. For FIDO2 especially, this risk is covered

by security goal SG-14 (Lindemann, 2018).

T4 Authentication Related Information Exposure.

The goal of an Information Exposure attack is not

hijacking foreign identities. Instead, the authenti-

cation process may expose user related information

such as usernames or mail addresses, that help

disclosing the victims identity.

Password based. Especially weakly chosen pass-

words may contain personal information such as the

date of birth or the children’s names. This makes it

easy to draw conclusions about the victim’s identity.

However, this threat can be defeated by conducting

proper transport encryption.

FIDO2. If the attacker gets access to the transmit-

ted WebAuthn request, he might be able to extract

personal data like the mail address or the username.

This scenario is covered by security goal SG-8 (Lin-

demann, 2018).

Remote WebAuthn. The Remote WebAuthn ini-

tialization data do not contain any privacy related

information. Therefore, only WebAuthn transaction

trafﬁc may include sensitive data. Besides snifﬁng

the encrypted network trafﬁc, this attack necessar-

ily requires access to the Symmetric Session Key

for decryption. Consequently, this access cannot be

performed without stealing the victims QR code.

4.3 Threat Justiﬁcation with STRIDE

Spooﬁng. A spooﬁng attack targets the authentica-

tion integrity by stealing and reproducing the user’s

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

374

identity. In the context of authentication, this can

be achieved following several attacks: The attacker

can either try to impersonate the RP in order to send

false authentication requests to the user (T1). Alter-

natively, he can try to imitate the users identity to

authenticate against the RP (T2).

Tampering. Whereas any involved system is consid-

ered to be secure, the Tampering attack is limited to

the modiﬁcation of data in transit. As Figure 1 out-

lines, this can be achieved by either modifying the

transmitted authentication data or its request.

Similar to the second Spooﬁng attack vector, an at-

tacker can modify the authentication request in tran-

sit to obtain an authentication from the victim. Alter-

natively, it is also possible to pretend a false identity

by faking a compromised authentication. Therefore,

scenarios T1 and T2 are appropriate representations

for this threat as well.

Repudiation. In this scenario, the victim, which is

also the attacker at the same time, denies being re-

sponsible for an actually executed authentication.

Therefore, this attack vector is equivalent to scenario

T3.

Information Disclosure. Information Disclosure at-

tacks target the protection goal of conﬁdentiality. In

this context, possible weak points are the authentica-

tion and its request in transit. Generally spoken it can

be divided, whether the stolen data can be directly

used for a following attack or for identity inference

only. While the ﬁrst case is identical to a Spooﬁng at-

tack and hence covered by scenarios T1 and T2, the

latter one is described by T4.

Denial of Service. The goal of a Denial of Service

attack is to cause security vulnerabilities by disturb-

ing the services availability. Since authentication

providers only build the base for other applications,

the concrete risk of an outage does not represent a

relevant attack vector for this work.

Elevation of Privilege. None of the introduced ap-

proaches offer an inherent right management, hence

this vector does not match the purpose of authentica-

tion. However, attackers may gain higher permission

by stealing foreign identities (T1).

5 CONCLUSION

In this paper, we’ve described Remote WebAuthn, a

novel authentication method related to FIDO2. Re-

mote WebAuthn focuses on providing security close

to FIDO2, on devices with restricted capabilities or

interfaces and limited software support, such as Smart

TVs. This publication covers the theoretical working

mechanisms as well as an example implementation

which is also publicly available online for everyone to

use. The example implementation (RemoteWebAu-

thn, 2020) was designed, such that device manufac-

turers could implement our method with ease. We

have thoroughly evaluated usability based on Bon-

neau’s sophisticated aspects (Bonneau et al., 2012)

as well as the security based on Microsoft’s STRIDE

model (Microsoft, 1999). We concluded, that the se-

curity level of our approach is higher than password

based authentication and slightly weaker compared to

FIDO2. However, our method provides a higher us-

ability compared to both alternatives. As future work,

we see the development of an example implementa-

tion of an iOS client among the already existing An-

droid client. With the publication of this paper as well

as the example implementation, we’re looking for-

ward establishing a new open standard for restricted

devices such as Smart TVs and increase the overall

security of such products.

REFERENCES

Bonneau, J., Herley, C., Van Oorschot, P. C., and Stajano,

F. (2012). The quest to replace passwords: A frame-

work for comparative evaluation of web authentica-

tion schemes. In IEEE S&P.

Bonneau, J. and Preibusch, S. (2010). The password thicket:

Technical and market failures in human authentication

on the web. In WEIS.

FIDO-specs (2020). Fido speciﬁcations overview. https:

//ﬁdoalliance.org/speciﬁcations.

Florêncio, D. and Herley, C. (2010). Where do security

policies come from? In SOUPS.

Kohnfelder, L. and Garg, P. (1999). The threats to our prod-

ucts. Microsoft Interface, Microsoft Corporation.

Krypton (2020). Krypton website. https://krypt.co.

Lindemann, R. (2018). Fido security reference.

https://ﬁdoalliance.org/specs/ﬁdo-v2.0-rd-20180702/

ﬁdo-security-ref-v2.0-rd-20180702.pdf.

Lyastani, S. G., Schilling, M., Neumayr, M., Backes, M.,

and Bugiel, S. (2020). Is FIDO2 the kingslayer of

user authentication? A comparative usability study of

FIDO2 passwordless authentication. In IEEE S&P.

Microsoft (1999). The stride threat model.

https://docs.microsoft.com/en-us/previous-versions/

commerce-server/ee823878(v=cs.20).

Reese, K., Smith, T., Dutson, J., Armknecht, J., Cameron,

J., and Seamons, K. (2019). A usability study of ﬁve

two-factor authentication methods. In SOUPS.

RemoteWebAuthn (2020). Remote WebAuthn source code.

https://github.com/pkwagner/remote-webauthn.

Schneier, B. (1999). Attack trees. Dr. Dobb’s journal.

Voigt, J. (2019). 5 sicherheitstipps zum safer inter-

net day. https://germany.googleblog.com/2019/02/

5-sicherheitstipps-zum-safer-internet-day.html.

Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices

375