A Novel Protocol Using Captive Portals for FIDO2

Network Authentication
Martiño Rivera-Dourado12 * , Marcos Gestal123 , Alejandro Pazos1234 , Jose Vázquez-Naya12
1 Grupo RNASA-IMEDIR, Facultade de Informática, Universidade da Coruña, Campus de Elviña, A Coruña, 15071, Spain
2 Centro de Investigación CITIC, Universidade da Coruña, Campus de Elviña, A Coruña, 15071, Spain
3 IKERDATA S.L., ZITEK, University of Basque Country UPVEHU, Rectorate Building, Leioa, 48940, Spain
4 Biomedical Research Institute of A Coruña (INIBIC), University Hospical Complex (CHUAC), A Coruña, 15006, Spain

* Corresponding author: martino.rivera.dourado@udc.es

Abstract—FIDO2 authentication is starting to be applied these systems and, therefore, to steal the information and data
in numerous web authentication services, aiming to replace they hold.
arXiv:2402.12864v1 [cs.CR] 20 Feb 2024

passwords and their known vulnerabilities. However, this new

authentication method has not been integrated yet with network
authentication systems. In this paper, we introduce FIDO2CAP: B. FIDO2: A new standard for web authentication
FIDO2 Captive-portal Authentication Protocol. Our proposal
describes a novel protocol for captive-portal network authentica- Considering that information systems protected by pass-
tion using FIDO2 authenticators, as security keys and passkeys. words are heavily threatened, some relevant technology com-
For validating our proposal, we have developed a prototype panies such as Google, Microsoft, Meta, or Yubico have
of FIDO2CAP authentication in a mock scenario. Using this started to develop a new authentication method. Back in 2014,
prototype, we performed an usability experiment with 15 real
users. This work makes the first systematic approach for adapt-
these companies created the FIDO Alliance [1], which has
ing network authentication to the new authentication paradigm published two versions of the FIDO Client To Authenticator
relying on FIDO2 authentication. Protocol (CTAP) standard during the last few years: CTAP1,
previously known as Universal Second Factor (U2F), and
Index Terms—WebAuthn, Network Authentication, Captive CTAP2. Since then, some security keys compliant with these
Portal, Protocol, FIDO2, Security key, Authenticators, Passkey
standards were developed, such as the Yubikey, the Solokey,
I. I NTRODUCTION or the Google Titan Security Keys.
In this context, in 2019, the W3C Consortium developed
The society often associates the concept of cybersecurity
WebAuthn, a new standard compatible with these hardware
with passwords. They are omnipresent in information systems
security keys [2] and other software-based authenticators.
all around the world for quite a long time. For a user, they are
WebAuthn is a new W3C standard that aims to complement
easy to use and understand and, without a doubt, passwords
or even replace passwords as a web authentication method.
have become a well-accepted paradigm as an authentication
Relying on the FIDO standards, WebAuthn defines a browser
standard.
API that has already been implemented in famous browsers
A. Passwords and their vulnerabilities such as Firefox and Chrome [3] (see figure 1). In addition, it
Passwords as an authentication method have become vul- describes a protocol that allows its usage as an authentication
nerable to numerous attacks. The most famous is phishing, method in web application servers. Consequently, some rele-
where an attacker misleads the victim to reveal their cre- vant web applications have already added WebAuthn security
dentials. However, phishing is not the only existing threat keys as an authentication method, to be used together with
that the passwords are subject to. Keyloggers are hardware passwords or even to replace them [4].
or software tools that attackers use to log the user input into The adoption of WebAuthn has evolved during these few
a system. Some hardware keyloggers can be physically placed years. “Passkeys” are the new commercial name of WebAuthn
between the keyboard and the computer to log keystrokes credentials for passwordless authentication. During the last
that are directly sent to the attacker. Moreover, it is a reality year, we have seen a great impulse of passkeys, which
that information leaks often appear in the news. These leaks increased in 50% from 2019 to 2022 according to a Duo report
can threaten passwords if they contain password hashes used [5]. For instance, Google [6], Microsoft [7] and Apple [8]
by authentication servers. Although an attacker is not able accounts, some cloud provider portals like Amazon AWS but
to directly use password hashes in the authentication portal, also in social networks like Facebook and Twitter.
the password can be obtained from them with different tech- FIDO CTAP standards and the W3C WebAuthn standard
niques. Password-cracking techniques are based on automated form together a new authentication paradigm under the name
trial and error methods for finding the original password. of FIDO2 authentication, also known as the “password-
In conclusion, all phishing, password stealing, and cracking less” paradigm. It opens new possibilities for authentication
attacks entail a security risk for password-based authentication mechanisms in multiple systems. Although the efforts were
methods that leave the user unprotected and without control directed to web application user authentication, there are other
over their credentials. This makes the attacker able to access computer systems where it could be integrated. One of them
 user. In our work, we will modify this captive portal web
page and integrate WebAuthn authentication in this system.
pfSense is one of the most popular open-source firmware
available in the market, mainly developed by Netgate. Similar
to other proprietary solutions, pfSense offers authentication
based on local-configured accounts or an external RADIUS
server [12]. Their firmware is compatible with several routers,
including Netgate, but also others like some TP-Link and
Protectli models.
On the other hand, OpenWRT is a Linux-based operating
system that targets embedded systems [13]. This firmware can
Fig. 1. User personal computer compatible with FIDO2: W3C WebAuthn be installed in some routers from Lynksis, Asus, TP-Link
and FIDO CTAP standards. The web application interacts with the OS via and Netgear, among others. OpenWRT has many available
the WebAuthn API of the web browser. The personal computer can have a
compatible credential storage for WebAuthn credentials, or interact with a
add-on packages that add features to the core light firmware.
security key via FIDO CTAP1/2. One of the available packages, built as a separate open-source
project, is OpenNDS. OpenNDS, based on NoDogSplash, is
a captive portal software developed in C compatible with
is authentication in computer networks, where access to the this firmware. Among their options, it is worth mentioning it
network or its resources are controlled. adds the possibility to externalise the web server used in the
captive portal. This configuration is known as the Forwarding
C. Network authentication Authentication Service (FAS) [14].
There are distinct ways to provide access control to a E. Authenticators: security keys and platforms
network. Some solutions like EAP with 802.1X can control FIDO security keys can be used in web authentication
the connectivity at the link level, but others like captive portal thanks to the WebAuthn API, developed by the W3C. These
systems perform packet filtering to restrict access to network hardware devices are the original idea of having a dedicated
resources after a client attachment. After authentication, both hardware known as authenticator to generate and store We-
systems aim to authorise the end device to send and receive bAuthn credentials. There are some commercial hardware
traffic on the network. security keys in the market, like the Yubikey and the Solokey,
Wireless home personal networks can use different network which can generate WebAuthn credentials.
authentication protocols for controlling connectivity. Although Apart from hardware authenticators, there are operating
there has been an evolution in the protocols, from WEP to the systems that already support creating WebAuthn credentials,
last WPA3-Personal, they still rely on long-term passwords to which are generated by a software known as a platform
authenticate users. authenticator. These credentials can be stored in a secure
Meanwhile, many corporate networks use the Extensible storage at the operating system, or stored in some cloud
Authentication Protocol (EAP) together with the 802.1X stan- secure storage. These are known as “passkeys”. Passkeys
dard for authenticating users in wired or wireless networks. are WebAuthn credentials credentials created in compatible
These standards are used for controlling the connectivity to the smartphones or laptops [6], and stored in a cloud provider to
networks at the link level. The most common EAP methods be synchronised among different devices of the user.
still use passwords as an authentication mechanism, such as
EAP-MD5 and LEAAP or some tunnelled methods based on F. The WebAuthn protocol and types of credentials
PEAP or EAP-TTLS, like MSCHAPv2 or PAP. Both software-based passkeys and credentials generated in
a security key 1 are involved in the two main ceremonies of
D. Captive portals the protocol: registration (or attestation) and authentication (or
Apart from EAP, there exist other alternatives for access assertion).
control to networks. As mentioned, captive portal systems During registration, a credential is created and linked with
filter the traffic at the network or link layer to control the an user account. This involves storing the created public
access to network resources [11]. Captive portals are websites key and the credential identifier in the authentication server.
displayed in end devices after network attachment to an During authentication, the user can verify their identity using
Access Point (AP) before granting access to network resources the previously registered credential. Specifically, they use the
or the Internet. private key to sign a challenge, which is verified by the
There are several ways to implement a captive portal. Most authentication server.
of the solutions nowadays are proprietary implementations As said, a FIDO authenticator can generate credentials
delivered in business routers, but other open-source or custom during the registration ceremony. If the credential is stored
router firmware offer this solution. For this work, we are into the hardware device memory, then the credential is known
interested in open-source alternatives for integrating WebAu- as resident (or discoverable) credential. If the credential does
thn authentication within the captive portal system. The most not use the security key memory, then it is known as non-
well-known solutions are pfSense and OpenWRT. They both resident (or non-discoverable) credential. For a user, the
implement a captive portal system, filtering access to network 1 For simplicity, in this work we are also using the term security key when
resources and displaying an captive portal web page to the we refer to a WebAuthn credential generated and managed by a security key.
type of credential is almost transparent. However, from the H. Contributions
development point of view, each type of credential involves In this work, we designed FIDO2CAP: FIDO2 Captive-
a different registration and authentication flow. Also, not all portal Authentication Protocol. Our proposal is to adapt
security keys and operating systems support resident creden- FIDO2 authentication to the network authentication performed
tials. In this paper, we developed support for both types of via a captive portal. Then, we present a prototype of the
credentials, to increase the compatibility of the system. OpenNDS captive portal using FIDO2CAP. Our system makes
the authentication in captive portals resistant to common
attacks for which password-based systems are vulnerable.
G. Related works For validation, we have installed our prototype in network-
ing hardware. We validated the compatibility with different
There exist several previous works that have addressed operating systems and web browsers, and we conducted an
network authentication security improvement before, but there usability experiment with 15 users.
are few of them that have applied FIDO authenticators to Therefore, our contributions can be summarised as follows:
network authentication.
• A novel protocol that integrates FIDO2 with cap-
In 2018, Chifor [16] presented a solution that makes use of tive portal authentication: FIDO2CAP. We provide a
the FIDO UAF protocol, a previous version of the current design of the FIDO2 Captive-portal Authentication Pro-
FIDO CTAP protocol, to network authentication. In this tocol (FIDO2CAP). We base our architecture design in
work, the protocol is used for authenticating guest users in the captive portal specification RFC 8952 [11], and then
an enterprise network by employing their personal Android we specify the authentication and registration protocols.
smartphones. For this purpose, they have created a scheme • Prototype of our protocol with OpenNDS. We have
where guests can register themselves to be authenticated in a developed, tested and validated with 15 real users a
different Wi-Fi network. prototype implementation of our protocol. For this, we
FIDO protocols were also applied to IoT network authen- have used an existing captive portal software known as
tication. Also in 2018, Chifor has proposed a security autho- OpenNDS.
risation scheme for IoT devices, which interact with the user
Android smartphone to perform FIDO CTAP1 authentication I. Paper organisation
[20]. Then, in 2021, Luo et al. [21] have used FIDO CTAP1 The remaining sections of the paper are organised as fol-
security keys to provide user authentication in an IoT Smart lows. Section II describes the required software and hardware
Home environment. In their work, a gateway node managing for this work, together with the methodology for all the re-
IoT devices authenticates a user when performing manage- search, implementation and validation tasks. Then, section III
ment operations. This authentication is performed with FIDO shows the proposed FIDO2CAP protocol: both the architec-
CTAP1 security keys physically connected to the gateway ture and the message flows. Then, we present a developed
node. prototype of FIDO2CAP in section IV. We have validated the
Furthermore, it is worth mentioning the work of prototype as explained in the subsection IV-D2. All the results
Huseynov [22], who proposed in 2022 a solution for connect- are presented in section V, which are discussed in section VI.
ing to a VPN service by authenticating the user with FIDO Finally, we draw some future research lines in section VII.
security keys. Their approach is to create an intermediary II. M ATERIALS AND M ETHODS
web portal that provides a temporal username and password
The main objective of this work was to design, develop and
pair, after authenticating with security keys. Their approach
validate the integration of FIDO2 authentication with a captive
is a wrapper solution to the problem, as the authentication
portal, providing a usable system for network authentication.
of the VPN service is still based on the existing compatible
After the FIDO2CAP protocol design, we have developed
authentication method of the VPN software.
a prototype. Firstly, we developed an authentication web
On the other hand, it is interesting how captive portals have server and, secondly, we integrated it with the OpenNDS
been adapted to additional network authentication scenarios. captive portal software. Also, for improving usability, our
Marquest et al. [23] designed a custom EAP method named work involved an study of the exceptions issued by different
EAP for Secure Hotspots (EAP-SH) that adapts the web-based operating systems, together with a user interface design.
authentication of Captive Portals to be used in IEEE 802.1X Finally, the result is validated with a compatibility test and
access controls. The work of Marquest et al. can be adapted a usability experiment with real users. This section describes
to use the work of this paper with EAP technology. the materials and methods used during all these phases of this
Despite the numerous security problems of captive por- work.
tals [24], there have been improvements in this field. The
RFC 8910 [25] published in 2020 adds a DHCP code to A. Required materials
improve the captive portal detection. In wireless networks, the Considering all the involved parties in this development
appearance of WPA3, a new Wi-Fi Alliance standard, adds authentication and authorisation system, the environment used
encryption to open Wi-Fi networks with the Opportunistic during this development tasks is based in Virtual Machines
Wireless Encryption (OWE) protocol [26]. This feature mit- (VMs). Also, we describe the networking hardware used
igates eavesdropping attacks on open wireless networks and, during validation. Additionally, for working with WebAuthn
therefore, makes them more secure to use a captive portal on authentication, we also need security keys and a compatible
them. technology stack. Namely:
 • Virtualisation software. We used VirtualBox 6.1 for set- reactions. After the task, they were asked some questions
ting up the virtual environment for development. to measure their satisfaction. Finally, users were asked to
• Three security keys. For the development of the tool and repeat the task and to complete a final questionnaire. We
the validation phase, we have used the Yubico Yubikey have considered usability measures defined by ISO 9241:
Security Key, which is compatible with discoverable completeness, efficiency and satisfaction.
credentials.
III. FIDO2CAP: FIDO2 C APTIVE - PORTAL
• Compatible technology stack. That is, compatible operat-
AUTHENTICATION P ROTOCOL
ing systems and browsers. We have used Linux (Manjaro
and Ubuntu), macOS Monterey, Windows (10 and 11), In this paper, we propose the FIDO2 Captive-portal Au-
Android (v8, v12 and v13) and iOS 16. thentication Protocol (FIDO2CAP), a captive portal network
• Hardware wireless router compatible with OpenWRT. authentication protocol using FIDO2. This section includes
We used ASUS RT-AC1200. the theoretical design of the protocol. First, the architecture
design based on the captive portal architecture defined by
B. Work methodology and planning RFC 8952 [11]. Then, the message flow of the FIDO2CAP
This research, development and validation work was protocol.
planned in six main phases. Namely, (PH1) initial research, for
A. Architecture design
analysing captive portal implementations, WebAuthn technol-
ogy and configuring the environment; (PH2) protocol design, RFC 8952 [11] describes the general architecture of a
for grouping the main requirements; (PH3) authentication captive portal in a network. In this work, we adapt and extend
server development, to develop the web application with this architecture for enabling network authentication using
WebAuthn authentication, (PH4) system integration, where FIDO2 authenticators. This solution can be implemented to
the developed web application was integrated with the captive provide access control for users in an access-level network,
portal authorisation; (PH5) usability improvement, where the such a Wi-Fi network or a cabled network of end devices.
error handling is designed and user interface is improved; Figure 2 shows the final architecture diagram, highlighting
and (PH6) validation, where the result is validated through our proposed changes. In our architecture, we include several
compatibility tests and usability experiment with real users. elements:
1) Initial research: The initial research includes two main • FIDO2 Authenticator. The user FIDO2 authenticator
technology stacks: (1) FIDO2: WebAuthn and FIDO authen- can be a hardware security key, a platform authentica-
tication; and (2) network authentication with captive portals. tor or a FIDO2 multi-device credential (passkey). The
Apart from the scientific literature review, this research also user interacts with the FIDO2 Authenticator to prove
included informal tutorials published in technology blogs, their identity when accessing a network. A platform
open-source projects and market related technology solutions. authenticator may be included in the user equipment.
All these information sources together enrich the research in For describing the general architecture, we consider it
these technologies, which is continually evolving. a separate device communicating via the FIDO CTAP
2) Development and integration: When designing the pro- protocol.
posed solution, the authors considered two main phases for • Web browser with WebAuthn API. The user equipment
the development: first, a web authentication server which must have a compatible client for performing authenti-
implements WebAuthn registration and authentication of se- cation through the W3C WebAuthn API.
curity keys and passkeys; and second, the integration the • WebAuthn Authentication Web Application (WAWA).
WebAuthn authentication with the captive portal authorisation A WebAuthn Relying Party implemented as a web-based
mechanism. These steps correspond to the phases PH3 and application, which works as the user portal displayed by
PH4 respectively. the captive portal system. This includes a web interface
3) Usability improvement: For improving usability, the displayed at the compatible web browser, and the authen-
user interface was redesigned after a first test with few tication server.
users. Also, we noticed that messages displayed originated • User database. A database that stores the FIDO2 cre-
from different use errors were not user-friendly. Therefore, dentials linked to a user identity.
we identified many possible errors during authentication and • Session database (optional). A database of opened
described the exceptions issued by web browsers in each sessions, which can allow the user or the administrator
operating system, to improve error messages accordingly. to list all open sessions linked with a user identity.
4) Validation: Finally, we have measured system usability • Registration portal. The registration system allows a
by (1) studying the compatibility across the most common registrar to register the FIDO2 Authenticator of the user.
operating systems and browsers and; (2) an usability experi- This portal may also show the active sessions linked with
ment with real users. The compatibility test was tested using a user and an authenticator. Alternatively, the registration
the hardware deployment and two already registered security portal may provide a self-registration flow for a user
keys, one with discoverable and other with non-discoverable to register themselves. For instance, this self-registration
credentials. In relation with the usability experiment, we can be controlled by a temporal access token, shared as
designed a experiment where the subjects were given the a QR code.
task to connect and authenticate in a Wi-Fi protected with • Registration equipment. The registration equipment and
the developed captive portal. Users were observed to identify the user equipment may be different, depending on the
all use and technology errors, while measuring the time and registration flow. For example, if the registration process
 Fig. 2. Architecture of the FIDO2 Captive-Portal Authentication (FIDO2CAP) Protocol.

is done by an administrator, or there is a setup equipment the registration of user FIDO2 Platform Authenticators.
for self-registration. For example, a user may scan a QR code provided by an
The proposed system architecture works similarly to the administrator, and use their Android smartphone to register a
RFC 8952 [11] for network authentication. After joining the passkey in the system.
network, the captive portal intercepts the traffic and provisions 2) FIDO2 Credentials: discoverable and non-discoverable:
the WAWA URI. Then, the Operating System of the User As mentioned in section I-F, FIDO2 credentials can be
Equipment displays the WAWA User Interface to the user. discoverable (resident) or non-discoverable (non-resident).
The WebAuthn Authentication Web Application now starts This changes how the authentication protocol works. With
the FIDO2 authentication process, involving the user and non-discoverable credentials, the user must be identified in
the FIDO2 Authenticator via the WebAuthn API and the the first place, while discoverable credentials do not need
FIDO CTAP protocol. If the authentication is successful, the this step. When the user is identified (for instance, using a
Enforcement Device is instructed to allow the access to the username), the list of allowed credentials is sent to the FIDO2
External Network for the User Equipment. This authorises the authenticator. As non-discoverable credentials are not resident
user to access the protected network. (stored) at the authenticator, they need to be provided in the
allowed credentials list during the authentication protocol.
B. Protocol overview Our definition of FIDO2CAP protocol is compatible with
The FIDO2CAP (FIDO2 Captive-portal Authentication discoverable and non-discoverable credentials, as it includes
Protocol) describes two main ceremonies, following the the identification of the user. If discoverable credentials are
FIDO2 standards. Firstly, we describe the user authentication used, then this step during authentication can be omitted.
protocol, based on the proposed architecture. Then, we pro-
pose a FIDO2 registration flow via the Registration Portal. C. Authentication protocol
1) Registration scenarios: administrator or self- Figure 3 shows the FIDO2CAP authentication protocol
registration: We consider two main actors in the protocol: an message flow. The parts highlighted in blue are modified or
user and a registrar. Also, we consider a different equipment added to the RFC [11]. FIDO2CAP protocol starts with the
for authentication (User Equipment) and for registration captivity signaling from the router. When the user equipment
(Registration Equipment). This provides a flexible range of requests the captivity status, the captive portal API Server
environements. For instance, the system may be enabled replies with the WAWA URI. This opens a web browser in the
for user self-registration. The user and the registrar may be user equipment, visiting the WAWA user interface. Here, the
the same person. In this case, the Registration Portal by a user sends the username for identification (this is the optional
temporal access token for user self-registration, which may step with discoverable credentials, see section III-B2).
be shared as a QR code to the user. This would allow the user The username allows the WAWA application to search
to use the User Equipment for registration, which enables for registered FIDO2 authenticators linked with the user in
Fig. 3. Authentication message flow in FIDO2CAP. The User Equipment is connected to the Captive Portal, getting redirected to the WAWA server URI.
The user performs FIDO2 authentication at the WAWA User Portal UI. After verifying the authentication, the Enforcement Device allows the access to User
Equipment, ending captivity.

the User Database. With this information, the WAWA server registration challenge generated by the WAWA server. This
generates the Allowed Credentials list, and the WebAuthn triggers the WebAuthn API that interacts with the user FIDO2
challenge, which is sent to the Web Browser. In the user end, Authenticator via the CTAP MakeCredential command. Once
the browser initiates the WebAuthn API, which inteacts with requested, the Registrar authorises the registration in the
the authenticator via the OS CTAP GetCredentials call. After authenticator, which generates the response. This response is
the user interacts with the authenticator via User Presence forwarded to the Registration Portal, who verifies it. Then, if
(UP) and/or User Verification (UV), the FIDO2 Authenticator the user is already registered, the credential is added to the
signs the challenge and sends its response, which is forwarded allowed FIDO2 Authenticators. If the user is not present in
to the WAWA server. Finally, the response is verified, and the the database, it is registered with the new credential.
WAWA server notifies the Enforcement Device, allowing the
User Equipment to access the external resources, ending the IV. P ROTOTYPE DEVELOPMENT AND VALIDATION
captivity.
As a Proof of Concept (PoC), we have developed and
validated a prototype of the proposed FIDO2CAP protocol.
D. Registration protocol
In this section, we present the developed prototype: a captive
FIDO2CAP registration protocol can be instantiated with portal authentication system using FIDO2CAP. First, we ex-
different setups. Figure 4 shows the general registration plain the WAWA server implementation (section IV-A), and
process, which involves the WAWA Registration Portal, a then the integration with the OpenNDS captive portal software
different user interface of the WAWA server. The Registrar, (section IV-B).
which may be the user, sends a request to the Registration Our prototype follows the FIDO2CAP architecture (see
Portal. After verifying the Registrar has the required registra- figure 2). We implemented the WAWA server, using a single
tion rights (see section III-B1), the Registrar sends the user database as the User Database and Session Database. This
username. Then, the username is used to search for registered web application includes both a User Portal and a Regis-
FIDO2 Authenticators in the User Database. These are be tration Portal, which implement the WebAuthn functionality.
included in the Excluded Credentials list, together with the Finally, we have integrated the our WAWA implementation
Fig. 4. Registration message flow in FIDO2CAP. The Registrar has the required permissions to access the Registration Portal UI. After specifying the
username, FIDO2 registration starts. Finally, the FIDO2 credentials (referred as Authenticator) are registered linked with the user account.

with OpenNDS. OpenNDS implements a captive portal: the credentials implies that the user is identified after the authen-
Enforcement Device, the Provisioning Service and the API tication of the credential.
Server. 3) Authentication with non-discoverable credentials: On
the contrary, with non-discoverable credentials, the authen-
A. WebAuthn Authentication Web Application (WAWA) tication response from the authenticator will not contain
In this section it is described the WebAuthn Authentication a userHandle that identifies the user. Therefore, the
Web Application (WAWA) that allows (1) registration of We- username should be specified at the authentication form.
bAuthn credentials by the administrator and (2) the authenti- When the server generates the WebAuthn authentication op-
cation with a WebAuthn credential by the user. The following tions, a list of the registered credentials for the corresponding
sections include relevant details on the development, which user is provided. This list contains credential identifiers that
was based in NodeJS and the SimpleWebAuthn library [10]. are actually encrypted private keys that only the registered
1) WebAuthn standard and credentials: As explained in authenticator can decrypt to correctly authenticate the user.
section I-F, the WebAuthn standard considers registration 4) Administration interface: The registration of credentials
and authentication of credentials. There are two types of in the web application is restricted to administration. Using
WebAuthn credentials related to authenticators (like security a RBAC, whether the users are authorised to register new
keys): discoverable and non-discoverable. Discoverable cre- devices or see restricted information depends on their role.
dentials are stored physically within the authenticator. On the For this purpose, we created a separate administrator interface.
contrary, non-discoverable credentials are stored encrypted The interface is restricted to users with the admin (or registrar)
in the server. In this prototype, both discoverable and non- role, which authorises a user to: (1) check registered users,
discoverable credentials have been considered. For this pur- their active sessions and registered credentials; (2) register a
pose, we have to consider two different authentication flows. WebAuthn credential; and (3) assign administration roles to
2) Authentication with discoverable credentials: With dis- users.
coverable credentials, the user does not need to identify 5) Session management: Web sessions represent an authen-
themselves with a username during the process. The ticated user and links their HTTP requests with that identity,
userHandle included in the authenticator response is used so they can be authorised. In this web server, ExpressJS uses
as the userId to find the registered device for verifying the cookies to maintain that session and expires them within a
authenticator response. Hence, using discoverable WebAuthn configured time, specified in an environment variable.
 For administrators to enumerate active sessions for the 2) OpenNDS Authmon: API Server and Enforcement De-
users, the sessions have also been stored in the web server vice: OpenNDS has a module named Authmon that im-
database. That way, from the administrator interface, the plements an API Server and an Enforcement Device. As
administrator can list the active user sessions per registered implemented in OpenNDS, the Authmon module sends pe-
user. That is also useful when integrating with the captive riodic requests to the FAS server. In this prototype, the FAS
portal to authorise authenticated users. Each time the user server is our WAWA server, which we have made compatible
is authenticated in the server, a new session is stored linked by extending the WAWA API, accepting the requests from
with the user identifier. With this approach, a user can have Authmon.
multiple concurrent sessions, which are represented in the ad- The Authmon module of OpenNDS sends periodic requests
ministration interface. When integrating the server with other to the FAS server to poll for new authenticated clients.
systems like the captive portal, users are able to authenticate Figure 5 shows a flow diagram that represents the final
more than once without requiring them to logout first from integration of the Authmon operation to authorise clients with
other sessions. the developed FAS server. It is worth mentioning that this
integration was possible after the reverse engineering process
B. Captive portal integration with OpenNDS
due to the lack of detailed documentation.
Once we developed a first working version of the WAWA, it Following figure 5: (1-3) the captive portal run by Open-
was integrated with a captive portal software: OpenNDS. This NDS redirects unauthorised clients to the WAWA server URL,
software implements the Provisioning Service, the API Server together with a hashed id (hid), encoded and encrypted as
and the Enforcement Device. First, we explain why we have explained in section IV-B4; (4-5) when handling User Equip-
chosen OpenNDS for the prototype development. Secondly, ment requests, the WAWA server must decrypt these details
we explain the integration of the WAWA with the API Server and calculate the authorisation token rhid, as explained
and the Enforcement Device of OpenNDS. in section IV-B4; (6-9) when the FIDO2 authentication is
During this section, the captive portal is commonly ref- successful, the WAWA server marks the client as authenti-
erenced with the chosen solution name: OpenNDS. On the cated; (11) all authorisation codes (the rhid) are requested
other hand, our WAWA server is commonly referenced as FAS periodically to the WAWA (FAS) server, who returns a list of
server (Forwarding Authentication Service), nomenclature authorisation tokens is sent to the OpenNDS router; (12-14)
used in the OpenNDS configuration for the User Portal server. using this token, OpenNDS can authorise the corresponding
1) Selection of a captive portal solution: OpenNDS: client for their access to network resources, notifying WAWA
Section I-D shows the existing captive portal technology about this.
nowadays. The integration work was successfully achieved 3) New API endpoints for Authmon: Thanks to the reverse
with OpenNDS installed on a Open-WRT firmware. However, engineering, the WAWA REST interface was adapted to han-
the first tests were performed with pfSense. dle the Authmon periodic requests and the new User Equip-
Both pfSense [12] and OpenNDS [14] are captive portal ment (client) requests. According to the reverse engineering
solutions that are suitable for this integration for being open- process, OpenNDS Authmon module can issue three HTTP
source. Therefore, they could be modified to integrate the POST requests to the authentication WAWA (FAS) server.
WebAuthn authentication server to achieve a final WebAuthn These are distinguished by the auth_get parameter of the
captive portal. However, the design of both solutions is HTTP request body.
different. While pfSense is a complete router firmware that
• ”clear”: All authenticated clients should be clear from
implements a captive portal, OpenWRT [13] router firmware
the list. That is, the list is reset. This is used by OpenNDS
relies on the OpenNDS independent package to implement
when booting.
the captive portal functionality. This makes OpenNDS a
• ”list”: The list should be sent and cleared. This type
more self-contained solution whose project code is easier to
of request is not frequent and is kept for backwards
approach.
compatibility.
A captive portal includes several key elements: an Enforce-
• ”view”: The most often request depends on its payload:
ment Device, an API Server, the User Portal and an the
Provisioning Service. One specific advantage of OpenNDS – * or none: The complete list of authenticated clients
that determines the final selection of the solution, is that it is required by Authmon. The corresponding autho-
allows externalising User Portal of the captive portal. This risation tokens (or rhid) should be sent in a list,
way, our WAWA server can be modified to be integrated with according to the compatible format: * <rhid>.
OpenNDS. – * < rhid >: Authmon is confirming the authorisa-
OpenNDS feature for externalising the User Portal is tion of a client.
called Forwarding Authentication Service (FAS) [14], which To implement the list of authenticated clients, the session
forwards the redirected requests to a captive portal to the management feature developed in the WAWA server can be
selected external web server. Finally, OpenNDS enforcement used. As explained in section IV-A5, the server incorporates
device should be integrated with the external web server to a separate database collection for storing authenticated user
identify the authenticated client and authorise its access to sessions. Then, once OpenNDS confirms the client authorisa-
the network. Therefore, during this section, the developed tion, it is marked as authorised. Finally, the session expiration
WebAuthn Authentication Web Application (WAWA) server time is synchronised with OpenNDS expiration time.
was modified to implement an external FAS server compatible 4) Cryptographic notes on FAS in OpenNDS: For the
with OpenNDS. implementation of the integration there are two cryptographic
Fig. 5. Communication between OpenNDS Authmon module and the developed WAWA server (FAS server). The User Equipment, gets redirected to the
WAWA UI hosted at the FAS server and, once authenticated, it is authorised by OpenNDS. In blue, the particular operation of OpenNDS we considered for
the integration of the developed WAWA server.

particular notes that should be considered: (1) the initial to perform development and validation of the prototype.
encrypted details and (2) the authorisation token of OpenNDS Our setup provisions a Wi-Fi connection via a WPA3 open
captive portal. network. This network is protected with our prototype captive
Steps 3 to 6 of figure 5 show how the client traffic is portal solution. It only provides Internet connectivity after
redirected to the captive portal at the FAS Server. OpenNDS successful FIDO2 user authentication.
adds some parameters necessary for the later client authorisa- 1) Environment configuration of a mock use case: Wi-
tion, encoded in base64 and encrypted with AES-256-CBC. Fi connectivity in a hotel: Our environment setup can be
Therefore, the WebAuthn authentication server installed at summarised in four equipments, mocking an use case of a
the FAS Server should decode and decrypt these parameters. hotel providing connectivity to the hotel network for their
Specifically, the AES block cipher in Cipher-Block-Chaining hosts. The FIDO2 security keys are registered beforehand,
(CBC) mode used by OpenNDS has a 256-bit block length. In and they are provided to the clients. As shown in figure 6
the WebAuthn authentication server in NodeJS, the required and 7, the setup consists in:
key length is of 32 bytes, which is shared with OpenNDS.
On the other hand, step 5 of figure 5 show the calculation
of the authenticated hash performed by OpenNDS. This
authenticated hash has to be used by the FAS server to send
an authorisation token that allows a client to be authorised by
OpenNDS. The hash used by OpenNDS is SHA256. However,
in order to authenticate the hash, OpenNDS developers have
chosen to include the symmetric key at the end of the payload
to hash. In this case, the FAS server should return a re-hashed
version of the hid parameter when the client is authenticated.
Letting k be the 32 byte shared key, the operation is shown
in eq.1.

rhid = sha256 ( hid || k ) (1)

Fig. 6. Example environment diagram: Wi-Fi connectivity in a hotel using
C. Test deployment and improvements the developed prototype. The network is divided in three zones: (1) a clients
wireless network; (2) a management network; (3) Internet through NAT.
This section depicts the environment setup of the developed The WAWA Server is placed in a public server for simplicity. Clients have
prototype: the WAWA server integrated with OpenNDS. The restricted access to Internet until successful FIDO2CAP authentication.
environment presented here is the one used in this work
 1) The User Equipment and the FIDO2 security keys. and the router, so the router can serve as a gateway of the
They are the personal devices of the hotel clients, used authentication server. Although we include a more detailed
to connect to the Wi-Fi for Internet connectivity. version in Github [28], here are the main configuration steps:
2) The Registration Equipment for the administrator. 1) Install OpenWRT in the ASUS compatible router [13].
Using this device, the hotel personnel register security 2) Install OpenNDS in OpenWRT
keys for their clients. a) Configure the clients network.
3) The developed WAWA server. Running in a physical
server, the WAWA application is configured properly to a) Download OpenNDS and edit the configuration
work with the OpenNDS instance. file (see step 4).
4) The OpenWRT router running OpenNDS. For vali- 3) Install WAWA in a server.
dating our solution with real hardware, we have used a) Download the WAWA server code from
the ASUS RT-AC1200 router, which is compatible with Github [28].
OpenWRT. OpenNDS should be properly configured to b) Configure the WAWA server integration with
work with the WAWA. OpenNDS (see step 4).
The environment was configured by installing the Open- 4) Verify the configuration compatibility: OpenNDS and
WRT firmware in the ASUS router, using the firmware WAWA:
restoration tool. We have configured a WAN interface as a a) The FAS remote IP:port = WAWA IP:port.
DHCP client for provide Internet connection to the router b) The FAS FQDN as the domain name of WAWA.
through another network. Also, the client network was con- c) The same FAS key random secret of 32 bytes.
figured using Wi-Fi with WPA3 open network. d) The same session timeout.
2) Improvements in usability and compatibility of the pro-
totype: During the deployment and initial testing of the proto-
type, we found some usability and compatibility issues. Here
we explain some of them, and in the following section we
include the final system validation and usability experiment.
During FIDO2 authentication, there are several errors that
can occur, so the user should be notified. However, we found
that not all errors are properly notified to the user through their
web browser. This decreases the usability of the authentication
flow UI. In fact, the browsers rise different browser exceptions
upon the same error. For instance, Firefox and Chrome in
Android differ when the user disconnects a FIDO2 security
key during authentication. At the time of writing, Linux rises
”Unknown Error” exception, while the Chrome browser rises
”Not Readable Error”.
Fig. 7. Physical deployment of the example environment. From left to
For this reason, we are conducting a study of all these dif-
right: the Registration Equipment (Windows 10), the FIDO2 Authenticator ferences, and finding some guidance, which will be published
(Yubikey Security Key), the User Equipment (Android 13) and the ASUS in the near future. In the prototype proposed in this paper,
Router (OpenWRT). The WAWA server is publicly hosted at our servers
(running the prototype [28]).
we have addressed some of these issues. Some of the errors
display a non-intrusive message, like a ”Try again” button,
Moreover, as shown in figure 6, the example topology without identifying the error and allowing the user to repeat
divides the corporate networking into three networks attached the action. Other errors that occur when the operation was
to the OpenWRT router, namely: (1) Internet, (2) management cancelled, include this information to the user, allowing them
and (3) clients network. For simplicity, our WAWA server is to do another try.
placed in Internet, although it could be in a DMZ within
the corporate network. Following our mock example of a D. Prototype validation and usability
hotel network, the clients are restricted to access Internet A captive portal using FIDO2 authentication is a novel
and some hotel services until successful connection to the approach. For this reason, we have measured both software
Wi-Fi network. This provides the proper segmentation of compatibility with real devices and system usability with real
the network, and access control to clients via FIDO2CAP users of the developed prototype. This section describes both
authentication. studies.
Finally, as mentioned before, configuring the captive portal 1) Captive portal with WebAuthn compatibility test: Our
in the router relies in OpenNDS configuration with the WAWA captive portal prototype has been tested in several desktop and
server. As said, in our example environment the WAWA server mobile operating systems. Taking into account the most used
is deployed in a public domain with a specific unique IP operating systems nowadays [17] [18], we have conducted
address. An unique IP address is necessary so OpenNDS some specific compatibility tests for validating the solution.
can configure the Enforcement Device (or firewall) properly, We have tested Windows, macOS and Linux desktop OSs; and
to allow the User Equipment initial request for the WAWA Android, iOS and Samsung One UI mobile OSs. Namely, the
UI. Also, we apply compatible configuration of the server following tests were designed:
 • NET-1 (CPD): The captive portal is detected by the OS 3) Usability experiment subjects and devices: In this ex-
and a browser is launched. periment, 15 users whose age varies from 18 to 64 have
• NET-2 (INTERNET): There is internet connection after participated in the experiment, including men an women. All
successful captive portal authentication. of them have a daily use of technology, and half of them
• WA-1 (WEBAUTHN): The browser launched by the OS have high or expert knowledge about computer science. Also,
is compatible with WebAuthn, the API exists. although the 93% use second-factor authentication, only the
• WA-2 (NDC): The browser was able to successfully use 20% have tried security keys before. For this reason, one of
non-discoverable credentials (non resident). the hypothesis of the experiment is that the first contact with
• WA-3 (DC): The browser was able to successfully use the proposed system will delay the completion of the task.
discoverable credentials (resident). The users have used their own smartphone devices, 13
• WB-1 (REDIRECT): In case of not compatibility of the of them Android and 2 iOS. We should highlight that iOS
default browser for captive portal detection, the user is devices are not compatible with the system, as the captive
correctly redirected to other browser. portal is opened in a non-compatible web browser. Most of
• WB-2 (EXCEPTION): Exception issued when the de- Android devices had the Android 12 or 13 version, which
fault browser has no practical WebAuthn compatibility. allow the user to open an alternative compatible browser
for authenticating in the network. As all users have daily
Table I shows the test results. The tests were performed with
technology use, they should be able to manipulate their own
the ASUS router running the captive portal. We registered
devices correctly, which helps them to perform tasks reliably.
two FIDO2 security keys, one with discoverable credentials
and other with non-discoverable credentials. As shown in the V. R ESULTS
table, there are different operating systems that detect the This work resulted in a novel network authentication proto-
captive portal and launch a specific mini-browser, that usually col based on FIDO2 authentication: FIDO2CAP. The protocol
is not compatible with WebAuthn. As analysed in [27], these includes a new architecture based on RFC 8952 [11], and
captive portal mini browsers have limited capabilities, and a message flow design for authentication and registration.
even security issues. These browsers are used in smartphone Our proposed architecture adds a WebAuthn Authentication
OSs and Linux-based desktop OSs, which affect to our system Web Application (WAWA), a FIDO2 authenticator and other
compatibility. elements to a captive portal. Also, we present a prototype
2) Usability of the captive portal with security keys in implementation of FIDO2CAP in an environment mocking a
mobile devices: As part of the validation of the solution, hotel Wi-Fi network. Finally, we conducted compatibility tests
we designed and conducted an usability experiment with and a usability experiment with 15 real users.
15 subjects. For this experiment, subjects used their own In this section, we summarise the specific results, namely:
smartphone devices, which they are used to, as clients of the (1) the FIDO2CAP protocol; (2) a prototype of the
Wi-Fi network running our captive portal. This follows the FIDO2CAP in a mock scenario; (3) results of the compat-
mock environment described in section IV-C. ibility tests and the usability experiment.
Users were asked to connect to the Wi-Fi network and
A. FIDO2CAP: a novel protocol for captive-portal FIDO2
authenticate with the security key and an username, after
authentication
a brief explanation. The security key and username were
already registered in the system by an administrator. After In section III we define FIDO2CAP: FIDO2 Captive-portal
the first try, the subjects were asked about their satisfaction Authentication Protocol. This is the main result of this paper.
and completeness of the process. Then, they were asked to The proposed novel protocol is based on captive portals
perform the task two more times and finally complete a small defined by RFC 8952 [11], and adapted to support FIDO2
questionnaire. user authentication. The main advantage of this approach is
For measuring the usability of the solution, we have con- that any captive portal compatible with the RFC could be
sidered three different measures based on ISO 9241 [19]: modified with the architecture of FIDO2CAP to support this
effectiveness, completeness and efficiency: new authentication protocol.
FIDO2CAP architecture is shown in figure 2, where we
• Effectiveness “is the accuracy and completeness with have included some elements, like the User Database and
which users achieve specified goals”, that is, that com- the WAWA. On the other hand, we have considered the
plete the connection to the Wi-Fi network with the two FIDO2 ceremonies: authentication and registration. The
security keys. Also, we measure the error rate while message flows are presented in figure 3 for authentication, and
performing the task, by observing the difficulties or figure 4 for registration. In both flows we take into account
technical issues that the user encounters. discoverable and non-discoverable credentials, which ensures
• Efficiency “is the resources used in relation to the results compatibility with different FIDO2 authenticators.
achieved”, that we measure as time-based efficiency and
overall relative efficiency. B. Functional prototype of FIDO2CAP
• Satisfaction “is the extent to which the user’s physical, We have developed a prototype of FIDO2CAP in the
cognitive and emotional responses that result from use scenario described in section IV-C. This scenario describes a
of a system, product or service meet user’s needs and hotel Wi-Fi network protected by a FIDO2CAP captive portal
expectations”. We have measured satisfaction with a system, which controls access to Internet and other network
custom questionnaire after performing the task. resources to the hotel clients.
 The developed prototype prototype has been published as
open-source in Github [28], available to download and deploy
in a compatible OpenWRT router. It provides documentation
of the configuration options and some instructions for its
deployment. In this section, we describe the specific results.
1) WebAuthn Authentication Web Application (WAWA):
WAWA is a web application that allows a user to authenticate
using FIDO2 authenticators compatible with the WebAuthn
standard, using a web browser. Registration of users, and their
corresponding security keys, are done by a registrar, which is
a privileged user implemented using RBAC roles.
The developed server is compatible with the last W3C Rec-
ommendation of the WebAuthn standard L3 [9], implementing
both discoverable and non-discoverable WebAuthn creden-
tials. This feature makes all types of FIDO2 security keys
or software “passkeys” compatible with the server registra-
tion and authentication procedures. In the developed system,
modern “passkeys” or discoverable credentials are supported,
so the user does not need to introduce an username in the Fig. 9. The administration interface of the developed authentication server.
It allows registration of security keys. The table of registered users lists the
authentication form. If the user has software or hardware not registered device of each user and the active sessions in real time. Admin
compatible with discoverable credentials, they can use the column is used to configure admin privileges to users.
system with non-discoverable credentials by introducing their
username (see figure 8).

WAWA server with the OpenNDS captive portal network

authentication system. This integration adapted the WAWA
server to communicate with the OpenNDS Enforcement de-
vice and API Server, as defined by the FIDO2CAP protocol.
The integration allows the authorisation of the User Equip-
ment traffic after the FIDO2 authentication with the WAWA
server. The following are some specific results achieved during
the development of the FIDO2CAP prototype.
Firstly, with this integration, our prototype benefits from
the compatibility of OpenNDS. For instance, the integrated
solution triggers the Captive Portal Detection (CPD) technol-
ogy embedded in the most used operating systems, showing
the captive portal page once connected to the network.
Other relevant results is that the same WAWA server can be
configured to work with different OpenWRT routers (or access
Fig. 8. Developed Captive Portal UI. The WebAuthn login form uses points) to control access in different networks. This way, the
discoverable credentials when the ‘I don’t need a username” option is resulting prototype provides a central point of authentication
selected.
compatible with a multi-gateway scenario. The same user
Additionally, an administrator user in the server can list can be authenticated in different networks, creating different
authenticated users in real time (see figure 9). The session sessions that can be viewed from the administration panel,
database allows users to open more than one authenticated while all gateway requests are managed independently.
web session, which are listed in the administration panel. Finally, thanks to the integration with OpenNDS, the solu-
Although the user can logout at any time during the session, tion is compatible with a real deployment scenario, that we
the expiration time will force the end of the web session used to validate the system (see section V-C). OpenNDS can
automatically. be installed on OpenWRT router firmware, which can form
Finally, an administrator can register security keys. These part of a final production environment easy to deliver with
can be associated with an existing user by specifying the multiple hardware routers. These devices can run the Open-
username, or can be registered and associated to a new user. NDS captive portal software, configured to be used with the
Therefore, a user can have multiple registered security keys. integrated developed WAWA server. This way when a client
This feature allows users to have a backup security key, which connects to the network via OpenWRT, it gets redirected to
can be used in case of device loss to securely gain access to the WebAuthn authentication server, who manages the request
the network. accordingly. After the client authentication, the authentication
2) Integration of WAWA in the OpenNDS captive portal: server waits for the periodic requests and confirms the client
The FIDO2CAP prototype includes the integration of the authorisation, redirecting them to the original HTTP request.
C. FIDO2CAP compatibility and usability the execution of the task. Namely, we found (1) use errors,
With the described FIDO2CAP prototype deployment, we produced by users; (2) OS errors, caused by the software of
have tested different operating systems and browsers. Fi- the user device; (3) connectivity issues, while connecting the
nally, we have conducted an usability experiment with real security key via USB or NFC; (4) compatibility errors, as
users. These results provide evidence of the feasibility of incompatibility with captive portal on iPhone devices.
the protocol and its usability. In this section we include the Table III shows the error rate of 1.93. Most of the detected
compatibility results, and then the usability experiment results. errors were operating system-related errors. Specifically, the
1) Compatibility with operating systems and web browsers: most common error was the Android credential manager menu
Applying FIDO2 authentication to a captive portal is a novel that delayed to appear, which confused some users. Even
approach. For this reason, there are some captive portal further, in some cases we detected that the Android credential
specific browsers that operating systems launch that do not manager menu blocks the completion of the operation by
support the WebAuthn API. We have tested our prototype getting frozen, causing the user to abandon the task. On
solution in the most common operating systems and browsers. the other hand, there were errors caused by the use. We
Table I shows the compatibility validation results. As it observed that some users tried to connect the key directly
can be seen, the system is fully compatible with operating to the unlocked smartphone, expecting the Wi-Fi network
systems using the user-defined web browser, which usually was automatically connected and authenticated without any
supports WebAuthn. There are other operating systems that additional step. Finally, some of the errors were caused by
use a custom web browser with limited functionality to open connectivity of the USB using an adaptor.
captive portal web pages, known as mini-browsers [27], which Most of the observed errors did not cause the task to
mostly are not compatible with WebAuthn. When there is no fail, although they delayed its completion. For measuring the
compatibility in a captive portal mini-browser, the developed efficiency, we have calculated Time-Based Efficiency (TBE)
web interface shows a redirection button to the user, which and Overall Relative Efficiency (ORE), shown in figures 11
opens a compatible web browser in Android and iOS (see and 12. In the first try, users completed 6.18×10−4 objectives
figure 10). per second, while in the second try, where the users have learnt
from the errors, users completed 1.571 × 10−3 objectives per
second, more than the double. Also, we measured the Overall
Relative Efficiency as the ratio of time taken by the users
who successfully completed the task in relation to the total
time taken by all users. The ORE of the first try is 54.38%,
and 35,95% in the second try. In the second try, the users
who failed the first time, spent more time than the ones that
completed the task in the first time.

Fig. 11. Time-Based Efficiency (TBE). Average objectives per second in

each try. Users have learnt from errors in the second try.
Fig. 10. Prototype UI warning the user that the OS or the browser are not
compatible. The button opens a new browser. The target browser depends on
the specific OS running the request. This screenshot was done in an Android
13 phone running the default mini-browser for captive portals, and the button
should open the Google Chrome app with the same URL.

2) Usability experiment with users: As explained in sec-

tion IV-D2 we designed and conducted an usability exper-
iment with 15 subjects with their own smartphone devices. Fig. 12. Overall Relative Efficiency (ORE). Ratio of time taken by the users
Users were asked to connect to the Wi-Fi network running who successfully completed the task in relation to the total time taken by all
the developed captive portal authentication service, and au- users.
thenticate with a registered security key.
From the 13 users with compatible smartphones, 69.23% Finally, we have measured satisfaction through different
completed the task of connecting to the Wi-Fi network and questions during the experiment. According to figure 13,
successfully authenticate in the captive portal with security 53.33% of users have found easy the process of connecting
keys. Table II shows the completeness of every step of the to the Wi-Fi with security keys, and 57.14% have found easy
task. As we can see, 84.62% reached a compatible web to try again when some error occurred. At the end of the
browser to start authentication. From those who had a com- experiment, as shown in figure 14, 66.67% of users have
patible web browser, 81.82% completed authentication. declared that they would have no problem in use security
On the other hand, we detected several errors of different keys for connecting to a Wi-Fi network, but none of them
categories, that constituted different types of obstacles during would prefer using keys.
 Windows macOS Manjaro Ubuntu Android iOS
Test / OS
10 11 Monterey 12.6.7 KDE 23.0.1 GNOME 23.0.1 22.04.3 LTS 8 12 13 16

NET-1 YES YES YES YES YES YES YES YES YES YES
NET-2 YES YES YES YES YES YES YES YES

WA-1 YES YES NO YES NO NO NO NO NO NO

WA-2 YES YES YES
WA-2 YES YES YES

WB-1 NO 4 NO 3 NO 3 NO 1 YES 2 YES 2 YES

WB-2 NotAllowedError NotAllowedError
1 Android web browser menu has the option to “open in the web browser”, which allows the user to choose the alternative.
2 Before opening the link in an external app, it asks for confirmation to the user with a warning message.
3 The user should manually copy the URL or open another browser manually.
4 There is no option for the user to open the URL in another browser manually.
TABLE I
C OMPATIBILITY OF THE CAPTIVE PORTAL SOLUTION ACROSS DIFFERENT OPERATING SYSTEMS .

Step Total completeness Step completeness

Connect to Wi-Fi network 100.00% 100.00%
Follow OS instructions 92.31% 92.31%
Browser redirection 84.62% 91.67%
Authentication 69.23% 81.82%

TABLE II
C OMPLETENESS OF EVERY STEP OF THE PROPOSED TASK . S AMPLE OF 13
USERS WITH COMPATIBLE SMARTPHONES .

Type of error Error rate

Use error 0.67
OS error 0.73
Connectivity error 0.40 Fig. 14. User answers to “Would you use security keys for connecting to a
Compatibility error 0.13 Wi-Fi network?” after finishing the experiment.
Total error rate 1.93
TABLE III
E RROR RATE OF THE DIFFERENT TYPES OF ERRORS . Moreover, we have developed a functional prototype on the
OpenNDS captive portal. The prototype can be installed on
a network to authenticate users with FIDO2 security keys. In
addition, we have validated the prototype usability, finding
use errors that can drive future research on FIDO2 usability
with a more extensive experiment.
Our FIDO2CAP protocol and the implemented prototype
are a proof of how FIDO2 authentication can be integrated
with other systems, and serve as a replacement of passwords
and their vulnerabilities. Therefore, security keys and passkeys
can now be used with captive portals that authenticate users
in real network authentication environments. However, there
is some work left in relation to the usability and producing
mature software with full compatibility across devices and
web browsers. Our implemented prototype depends on custom
web browsers that operating systems open when detecting a
Fig. 13. Difficulty as a measure of satisfaction: overall satisfaction (outer) captive portal, impacting the user experience.
and satisfaction from recovering from errors (inner). Answers from users after In conclusion, FIDO2 authentication represent an opportu-
performing the task.
nity to improve security by migrating the existing authentica-
tion services to a new authentication paradigm. Considering
that central authentication involves different systems, the
VI. D ISCUSSION AND CONCLUSIONS
migration to FIDO2 should be done in all authentication
We propose a novel authentication protocol based on scenarios of a business. They include web authentication, but
FIDO2 authentication integrated it with a captive portal. also other systems like network access control.
 WebAuthn and FIDO CTAP are recent standards that is [5] Cisco Systems, 2022. The 2022 Duo Trusted Access
still under development. Although it has already been imple- Report. Available online: https://duo.com/assets/ebooks/
the-2022-duo-trusted-access-report.pdf (accessed on 14 October
mented in web authentication in different operating systems, 2023).
browsers and devices, their applicability to further scenarios [6] ‘Passkey - the simplest way to sign into your Google Account’.
has not yet been studied. This paper proves that there are Available online: https://safety.google/authentication/passkey/ (accessed
on 14 October 2023).
other applications, like network authentication. Although the [7] ‘Support for passkeys in Windows - Windows Security’, Sep. 27, 2023.
underlining technology is web-based, the integration with Available online: https://learn.microsoft.com/en-us/windows/security/
a real captive portal enforcement device demonstrates the identity-protection/passkeys/ (accessed on 14 October 2023).
[8] A. Inc, ‘Passkeys’, Apple Developer. Available online: https://developer.
potential of security keys in network authentication. apple.com/passkeys/ (accessed on 14 October 2023).
[9] Web Authentication: An API for accessing Public Key Credentials Level
VII. F UTURE WORK 3. Available online: https://www.w3.org/TR/webauthn-3/ (accessed on
In this paper we proposed FIDO2CAP, and validated it with 14 October 2023).
[10] Miller, M., 2022. SimpleWebAuthn Project. Github. Available online:
a real prototype and users. Here we include some of our https://github.com/MasterKale/SimpleWebAuthn (accessed on 14 Octo-
current research lines that continue the work we presented ber 2023).
in this paper: [11] Larose, K., Dolson, D., Liu, H., 2020. RFC 8952: Captive Portal
Architecture. RFC Editor. Available online: https://doi.org/10.17487/
1) Validate the usability of the solution with more users RFC8952 (accessed on 14 October 2023).
and compare different samples. Design new envi- [12] Captive Portal — pfSense Documentation, n.d. Available online: https:
ronments and validate user acceptance across different //docs.netgate.com/pfsense/en/latest/captiveportal/index.html (accessed
on 14 October 2023).
types of users. [13] Brown, R., 2016. Welcome to the OpenWrt Project . OpenWrt Wiki.
2) Extend the prototype for auto-registration and vali- Available online: https://openwrt.org/start (accessed on 14 October
date its usability. Test the usability of users registering 2023).
[14] Forwarding Authentication Service (FAS) — openNDS v9.7.0 , n.d.
their own credentials in the captive portal for later Available online: https://opennds.readthedocs.io/en/stable/fas.html (ac-
authentication. cessed on 14 October 2023).
3) Compare the usability of the developed captive [15] Authentication Ceremony Privacy, Web Authentication: An API for
accessing Public Key Credentials Level 2. Available online: https:
portal and a captive portal based on passwords. //www.w3.org/TR/webauthn-2/#sctn-assertion-privacy (accessed on 14
Evaluate how passwordless authentication with security October 2023).
keys is more usable than passwords. [16] Chifor, B.-C., Teican, S., Togan, M., Gugulea, G., 2018. A Flexi-
ble Authorization Mechanism for Enterprise Networks Using Smart-
4) Study the usability issues caused by the error Phone Devices, in: 2018 International Conference on Communications
management of web browsers with WebAuthn. We (COMM). Presented at the 2018 International Conference on Commu-
detected some differences when managing exceptions nications (COMM), pp. 437–440. Available online: https://doi.org/10.
1109/ICComm.2018.8484268 (accessed on 14 October 2023).
during a failure in WebAuthn authentication. We are [17] Market share held by the leading computer (desk-
working on a study of the current browser implemen- top/tablet/console) operating systems worldwide from January
tations and proposing a solution, which can help to 2012 to June 2023 [Graph], StatCounter, July 21, 2023.
Available online: https://www.statista.com/statistics/268237/
improve usability and adoption of this authentication global-market-share-held-by-operating-systems-since-2009/ (accessed
method. on 14 October 2023).
[18] Global market share held by mobile operating systems from 1st
ACKNOWLEDGEMENTS quarter 2009 to 2nd quarter 2023 [Graph], StatCounter, July 1,
This work was supported by the grant ED431C 2022/46 2023. Available online: https://www.statista.com/statistics/272698/
global-market-share-held-by-mobile-operating-systems-since-2009/
– Competitive Reference Groups GRC – funded by: EU and (accessed on 09 March 2023).
“Xunta de Galicia” (Spain). This work was also supported [19] ISO 9241-11:2018. Ergonomics of human-system interaction — Part
by CITIC, funded by “Xunta de Galicia” through the col- 11: Usability: Definitions and concepts. Available online: https://www.
iso.org/standard/63500.html (accessed on 14 October 2023).
laboration agreement between the “Consellerı́a de Cultura, [20] Chifor,B.-C., Bica, I., Patriciu, V.-V., and Pop, F. A security au-
Educación, Formación Profesional e Universidades” and the thorization scheme for smart home Internet of Things devices. in:
Galician universities to strengthen the research centres of the Future Generation Computer Systems, vol. 86, pp. 740–749, Sep. 2018.
Available online: https://doi.org/10.1016/j.future.2017.05.048 (accessed
“Sistema Universitario de Galicia” (CIGUS). Also, the work on 14 October 2023).
is founded by the “Formación de Profesorado Universitario” [21] Luo, H., Wang, C., Luo, H., Zhang, F., Lin, F. and Xu, G. G2F: A
(FPU) grant from the Spanish Ministry of Universities to Secure User Authentication for Rapid Smart Home IoT Management.
in: IEEE Internet of Things Journal, vol. 8, no. 13, pp. 10884–10895,
Martiño Rivera Dourado (Grant FPU21/04519). Jul. 2021. Available online: https://doi.org/10.1109/JIOT.2021.3050710
(accessed on 14 October 2023).
R EFERENCES [22] Huseynov,E. Passwordless VPN using FIDO2 Security Keys: Modern
[1] Fido Alliance - Open Authentication Standards more secure than authentication security for legacy VPN systems, in: 2022 4th Inter-
passwords. Available online: https://fidoalliance.org/ (accessed on 14 national Conference on Data Intelligence and Security (ICDIS), Aug.
October 2023). 2022. pp. 01–03. Available online: https://doi.org/10.1109/ICDIS55630.
[2] Web Authentication: An API for accessing Public Key Credentials Level 2022.00075 (accessed on 14 October 2023).
1. Available online: https://www.w3.org/TR/webauthn-1/ (accessed on [23] Marques, N., Zúquete, A., Barraca, J.P., 2020. EAP-SH: An EAP Au-
14 October 2023). thentication Protocol to Integrate Captive Portals in the 802.1X Security
[3] Web Authentication API - Web APIs — MDN , n.d. Avail- Architecture. Wireless Pers Commun 113, 1891–1915. Available online:
able online: https://developer.mozilla.org/en-US/docs/Web/API/Web https://doi.org/10.1007/s11277-020-07298-y (accessed on 14 October
Authentication API (accessed on 14 October 2023). 2023).
[4] Rivera-Dourado, M., Gestal, M., Pazos, A., Vázquez-Naya, J.M., 2021. [24] Anderberg, P., Thorselius, E., n.d. How to Circumvent a Captive Portal
An Analysis of the Current Implementations Based on the WebAuthn 5. Available online: https://www.ida.liu.se/∼TDDD17/oldprojects/2010/
and FIDO Authentication Standards. Engineering Proceedings 7, 56. projects/003-2.pdf (accessed on 14 October 2023).
Available online: https://doi.org/10.3390/engproc2021007056 (accessed [25] Kumari, W. “Ace”, Kline, E., 2020. RFC 8910: Captive-Portal Iden-
on 14 October 2023). tification in DHCP and Router Advertisements (RAs). Internet Engi-
 neering Task Force. Available online: https://doi.org/10.17487/RFC8910
(accessed on 14 October 2023).
[26] Security — Wi-Fi Alliance , n.d. Available online: https://www.wi-fi.
org/discover-wi-fi/security#Wi-FiEnhancedOpen (accessed on 14 Octo-
ber 2023).
[27] Wang, PL., Chou, KH., Hsiao, SC., Low, A.T., Kim, T.HJ., Hsiao, HC.
Capturing Antique Browsers in Modern Devices: A Security Analysis
of Captive Portal Mini-Browsers. In: Tibouchi, M., Wang, X. (eds)
Applied Cryptography and Network Security. ACNS 2023. Lecture
Notes in Computer Science, vol 13905. Springer, Cham. Available
online: https://doi.org/10.1007/978-3-031-33488-7 10 (accessed on 14
October 2023).
[28] martinord/fido2cap-server: WebAuthn Authentication Web Application
compatible with OpenNDS Captive Portal, n.d. . GitHub. Available
online: https://github.com/martinord/fido2cap-server (accessed on 14
October 2023).