See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/392312310
A Pluggable Authentication Module for E-Mail as a Secure Additional
Authentication Factor
Conference Paper · June 2025
DOI: 10.1007/978-3-031-94263-1_2
CITATIONS READS
0 8
1 author:
Günter Fahrnberger
University of Hagen
59 PUBLICATIONS 178 CITATIONS
SEE PROFILE
All content following this page was uploaded by Günter Fahrnberger on 08 June 2025.
The user has requested enhancement of the downloaded file.
A Pluggable Authentication Module for E-Mail
as a Secure Additional Authentication Factor
Günter Fahrnberger[0000-0002-2606-3988]
University of Hagen, Hagen, North Rhine-Westphalia, Germany
[email protected] Abstract. Anti-hammering mechanisms frequently struggle to manage
both Brute Force Attacks (BFAs) and Denial of Service (DoS) attacks
effectively, highlighting the need for robust safeguards to counter creden-
tial guessing and account lockouts. A pluggable authentication module
for e-mail as an additional authentication factor may offer a practical
solution but fails to provide an advantage when the same e-mail address
resets the primary authentication factor. A thorough literature review
reveals no existing module supporting a secondary e-mail address. This
technical documentation presents a Lightweight Directory Access Proto-
col (LDAP)-dependent prototype implemented on a standard Linux Op-
erating System (OS). Each Multi-Factor Authentication (MFA) solution
faces inherent vulnerabilities. Therefore, comprehensive threat model-
ing identifies nine categories of potential weaknesses in the new module,
necessitating careful evaluation during deployment.
Keywords: Access Control · Authentication · Authenticity · Informa-
tion Security · Multi-Factor Authentication (MFA) · One-Time Password
(OTP) · Pluggable Authentication Modules (PAM) · Random One-Time
Password (ROTP) · Two-Factor Authentication (2FA)
1 Introduction
Application logs and network traces reveal that open ports on public-facing in-
terfaces draw attackers’ attention as soon as they emerge. Network scanners
locate and probe them, vulnerability scanners determine feasible threat vectors,
and BFAs or manual penetration tests attempt to gain initial access to services
listening on these open ports [4–6]. Anti-hammering mechanisms, as countermea-
sures, offer both benefits and drawbacks. They lock out targeted accounts or ban
source Internet Protocol (IP) addresses. Beyond permanent lockouts, perpetu-
ated DoS attacks can even exploit temporary lockouts to continuously prevent
innocent users from accessing their accounts or to block legitimate requests from
shared resources, such as gateways or proxies. For this reason, anti-hammering
mechanisms do not always provide a perfect solution. A supplementary approach
must effectively counter both credential guessing and account lockouts.
Such a remedy already exists by imposing more than one kind of authentica-
tion factor, also known as MFA. The often-utilized Two-Factor Authentication
2 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
(2FA) denotes the imposition of two independent factors. The scientific literature
commonly classifies authentication factors into inherence-based (e.g., biometric
features), knowledge-based (e.g., passwords), and possession-based (e.g., keys)
ones. Fahrnberger proposes Three-Factor Authentication (3FA) for the military
domain, consisting of a biometric ElectroCardioGram (ECG), a known password,
and a possessed ECG sensor [3]. Such a complex solution might be justified for
highly secure use cases, but unreasonable for everyday users.
To avoid cutting a security corner in the name of usability, a doable idea
involves applying 2FA by combining the factors of memorizable knowledge and
mutable ownership. In simple terms, a user must provide a valid password and
an One-Time Password (OTP). Appropriate generators in the user’s posses-
sion supply such an OTP, also known as a Time-based One-Time Password
(TOTP). Compared with a TOTP, the predictability of an instantly conveyed
e-mail with a cryptographically secure Random One-Time Password (ROTP)
decreases further, reaching virtually zero. This advantage makes ROTP prefer-
able over TOTP. Nowadays, many applications rely on TOTP or ROTP for
protection.
The Pluggable Authentication Modules (PAM), the default authentication
framework for UNIX derivatives, also support 2FA through TOTP via authenti-
cator apps [1]. The Security Verify Gateway for Linux PAM and Advanced Inter-
active eXecutive (AIX) PAM from IBM even facilitate 2FA through e-mail [10].
For the sake of secure authentication, e-mail accounts often require 2FA them-
selves for web access or long Application Programming Interface (API) keys for
protocols like IMAP (Internet Message Access Protocol) [12] or POP3 (Post
Office Protocol 3) [13].
IBM’s Security Verify Gateway relies on a user’s e-mail address from an ar-
bitrary identity provider, where a reset portal might send a password reset link
for the primary authentication factor. This approach reduces the effectiveness
of 2FA via e-mail. No existing deployment includes a pluggable authentication
module leveraging a secondary e-mail address as a secure additional authenti-
cation factor. An ROTP sent to a secondary e-mail address offers a convenient
option that should integrate with PAM.
This treatise details the development and application of such a module to
maintain the security of the popular ROTP via e-mail and avoid the need to fall
back on a 2FA technique with lower security or convenience. Section 2 reviews
relevant literature on PAM and module development. Section 3 delves into the
programmatic details of creating a pluggable authentication module based on
a secondary e-mail address. Section 4 presents a security analysis of this new
module. Finally, Sect. 5 concludes the paper and outlines potential future work.
2 Related Work
No scholarly work examines the use of a pluggable authentication module for an
ROTP sent to a secondary e-mail address as a secure additional authentication
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 3
factor. This section describes PAM and provides guidance on developing new
modules.
Samar and Lai developed PAM in 1995 during their employment at SunSoft
Inc. It became the standard authentication framework for the Common Desktop
Environment (CDE) [14]. PAM should fulfill the following design goals.
– Selectable default authentication mechanism by system administrator(s)
– Configurable user authentication mechanism on a per-application basis
– Support for the display requirements of applications
– Configurable multiple authentication protocols
– No password retyping for already authenticated users
– Easily changeable underlying mechanisms
– Pluggable model for system authentication as well as for password, account,
and session management
– Backward compatibility with legacy system-entry services
– API independent of the OS
These objectives have entailed PAM’s basic architecture as shown in Fig. 1,
which also displays insecure legacy protocols (such as Telnet), the utilization of
which nowadays poses a significant danger, making them highly deprecated.
Fig. 1. PAM basic architecture
To accomplish the requirement of a pluggable model for system authenti-
cation as well as for password, account, and session management, Samar and
Lai differentiate between the four PAM interfaces mentioned below. Geisshirt’s
guide to PAM does the same but refers to them as management groups [7].
– auth: The auth group offers two functions. Initially, it validates the user
by confirming authenticity, typically through a username and correspond-
ing password. Subsequently, the auth management group grants credentials,
which encompass group membership.
– account: Access to a service controlled by the account management group
includes limitations such as the frequency of use per week, specific time
periods, or account expiration status. PAM enable configuring precise access
control settings.
4 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
– session: The session management group constructs the environment for a
given service. Upon a user ceasing to use the service, the session group dis-
mantles the environment. When setting up the environment (or session), nec-
essary data for proper operation gets loaded, such as opening data sources
and mounting home directories.
– password: The last management group handles passwords and related ac-
tions, such as changes and policy enforcement. PAM maintain a separation
between the password-changing application and the backend storage.
Each pluggable authentication module may return either success or failure. Some
responses hold more importance than others. Thus, the control flags listed below
can alter the flow and influence decision-making.
– requisite: This control flag stands out as the strongest among all flags. If a
PAM configuration file tags a pluggable authentication module as requisite
and it fails, PAM will immediately return to the calling application and
report the failure.
– required: The return code for a required pluggable authentication module
gets stored. In the event of failure, execution proceeds to the next module.
Once a sequence (stack) of modules has been executed, and at least one
required module has failed, PAM will report failure to the calling application.
Furthermore, the failure links to the first failing module. The required control
flag helps keep unauthorized persons out of your computer, especially since
the other modules in the stack also apply. This prevents a cracker from
knowing which module caused the failure, leaving many more possibilities of
what went wrong.
– sufficient: This control flag holds considerable strength. Processing of the
stack halts if a pluggable authentication module tagged as sufficient returns
success, provided no previous required module has failed. Any required mod-
ules following the sufficient modules will not be called.
– optional: When a pluggable authentication module receives an optional tag,
a failure does not change the stack’s execution as it does with a requisite tag.
Additionally, the return code gets ignored, and neither failure nor success
gets considered.
The sequence of pluggable authentication modules and their control flags holds
significant importance. Specifically, the arrangement of modules marked as re-
quired and requisite needs attention, as does the order of sufficient and required
modules. A stack enforces sequential testing of modules. This process resembles
executing a series of steps akin to a procedure or processing firewall rules. Mod-
ules can produce side effects, such as printing information on their invocation
or failure reasons, or creating/mounting directories. These outcomes could pro-
vide attackers with insights to enhance their attacks. In other scenarios, order
becomes crucial because one module’s effect must precede the correct operation
of the subsequent module, such as mounting a home directory before accessing
a Secure Shell (SSH) [11, 16–19] key.
Speaking of SSH, Binnie elaborates on hardening an SSH server configura-
tion with TCP wrappers, allowing only trusted IP addresses or domain names
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 5
for login [1]. He also enables the Google Authenticator library to implement
2FA, supporting a range of devices including iPhone, iPod Touch, iPad, and
BlackBerry.
Chia et al. address the tightrope walk between password- and hardware
token-based authentication via PAM [2]. Easily implementable password-based
authentication relies on the strength of the chosen password and has long posed
the easiest attack vector. Conversely, small- and medium-sized enterprises strug-
gle to finance all their personnel with more secure hardware tokens for authenti-
cation. Hence, the author group raises the research question of finding a method
to realize an authentication module for PAM that offers security comparable
to state-of-the-art cryptographic methods while remaining low cost, simplistic,
and practical. They answer their question positively by proposing identity-based
identification schemes and their hierarchical variants in PAM. Their fifth section
on design and implementation offers a valuable role model for developing a plug-
gable authentication module that sends Random One-Time Passwords (ROTPs)
to a secondary e-mail address as a secure additional authentication factor.
3 Implementation
This section, the centerpiece of this disquisition, details the architectural nuances
of the developed pluggable authentication module responsible for generating and
sending ROTPs to a secondary e-mail address and explaining how to integrate
it with the SSH Daemon (SSHD) of two common Linux OS families. The au-
thentication process of SSHD depends on several binary and configuration files,
five of which require modification or creation. The itemization below represents
the chronological sequence in which the modified files get accessed during the
authentication process of Debian- and Red Hat-based Operating Systems (OSs).
– /etc/ssh/sshd config
– /etc/pam.d/sshd
– /etc/pam.d/common-auth (Debian-based), /etc/pam.d/password-auth (Red
Hat-based)
– /etc/sssd/sssd.conf
– /usr/lib/x86 64-linux-gnu/security/pam email.so (Debian-based),
/usr/lib64/security/pam email.so (Red Hat-based)
3.1 /etc/ssh/sshd config
As Sect. 2 suggests, PAM today form the standard authentication framework
for Linux Operating Systems (OSs). This includes core services like SSH. Conse-
quently, SSHD’s main configuration file /etc/ssh/sshd config typically includes a
line with the option UsePAM yes. If absent or commented out, SSHD defaults to
invoking PAM. For example, on Red Hat-based OSs, /etc/ssh/sshd config may
contain a warning against disabling PAM due to potential issues. As an action
item, it can be inferred to verify that SSHD employs PAM.
6 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
3.2 /etc/pam.d/sshd
Once invoked by SSHD, PAM read the corresponding settings in the configu-
ration file /etc/pam.d/sshd. Debian-based OSs delegate the authentication pro-
cess to the central configuration file /etc/pam.d/common-auth by including the
line @include common-auth. Similarly, Red Hat-based systems use the direc-
tive auth substack password-auth, which delegates the authentication process to
/etc/pam.d/password-auth. Either referenced configuration file returns control to
/etc/pam.d/sshd once it completes its tasks. At this point, PAM invoke the new
pluggable authentication module for e-mail, pam email.so, as explained in Sub-
sect. 3.5. By utilizing the sufficient control flag and the use first pass option, the
password obtained by the variable PAM AUTHTOK from a preceding module
in the stack will be reused, respecting the outcomes of all previously integrated
modules. This can be achieved by adding the line auth sufficient pam email.so
use first pass.
3.3 /etc/pam.d/common-auth (Debian-based),
/etc/pam.d/password-auth (Red Hat-based)
An item like auth sufficient pam unix.so nullok in both files /etc/pam.d/common-
auth and /etc/pam.d/password-auth prompts for a password to authenticate
local users specified in the file /etc/passwd, verified by their password hashes
in /etc/shadow. The option nullok allows users with empty passwords to au-
thenticate. Removing it would require non-empty passwords for authentica-
tion, thereby reducing the risk of unauthorized access. Neither /etc/passwd nor
/etc/shadow can store e-mail addresses of users.
A cumbersome approach would be to rewrite all user management utilities
of the OS to incorporate e-mail addresses in an exemplary extra file /etc/email.
A more viable solution utilizes a proven centralized user directory service that
inherently supports e-mail addresses in user accounts. For simplicity, the re-
mainder of this document assumes the LDAP as the basis [15]. Consequently, a
directly successive line auth sufficient pam sss.so use first pass activates authen-
tication via LDAP. As aforementioned in Subsect. 3.2, the option use first pass
reuses the password in the variable PAM AUTHTOK passed from pam unix.so
to verify its validity via LDAP.
3.4 /etc/sssd/sssd.conf
pam sss.so obtains its settings from the file /etc/sssd/sssd.conf, which could be
configured for the domain example.org as follows.
– [domain/default]
– auth provider = ldap
– autofs provider = ldap
– cache credentials = True
– chpass provider = ldap
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 7
– id provider = ldap
– ldap id use start tls = True
– ldap search base = ou=users,dc=example,dc=org
– ldap tls cacert = /usr/local/share/ca-certificates/example.org.crt
– ldap tls cacertdir = /usr/local/share/ca-certificates
– ldap tls reqcert = hard
– ldap uri = ldaps://ldap.example.org/
– [nss]
– homedir substring = /home
– [sssd]
– domains = default
3.5 pam email.so
The novel pluggable authentication module pam email.so resides in the directory
/usr/lib/x86 64-linux-gnu/security on Debian-based and /usr/lib64/security on
Red Hat-based OSs. Figure 2 visualizes the simplified flowchart of pam email.so.
Fig. 2. Flowchart of pam email.so
Firstly, as previously outlined, pam email.so retrieves the relevant secondary
e-mail address from the LDAP service, which has already completed password
verification. For this purpose, pam email.so reuses the settings of pam sss.so, i.e.,
it reads $ldap search base and $ldap uri from /etc/sssd/sssd.conf to connect to
the LDAP service and fetch the newly introduced secmail attribute as the vari-
able $smtp recipient. The LDAP bind works with the credentials $PAM USER
and $PAM AUTHTOK, collected by prior modules, usually by pam unix.so.
/etc/pam.d/sshd invokes pam email.so only if pam sss.so succeeds, i.e., termi-
nates with the status code PAM SUCCESS. Therefore, the LDAP bind should
also work well. Nonetheless, the retrieval of secmail from LDAP could fail, e.g., if
a working LDAP account lacks a valid secondary e-mail address. In such a case,
pam email.so ends by returning the status code PAM AUTHINFO UNAVAIL.
8 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
Upon successful retrieval of the secondary e-mail address, pam email.so em-
ploys the Linux on-board Pseudo Random Number Generator (PRNG) to pro-
duce a six-digit ROTP $code output. The module then searches for a local
Mail Transfer Agent (MTA), such as Extended Simple Mail Transfer Protocol
(ESMTP), Postfix, or Sendmail, to send $code output to $smtp recipient. After-
ward, the user receives a message (e.g., Verification code:) prompting them to
enter the recently dispatched $code output. pam email.so saves the user input in
the variable $code input and compares it with $code output. Only a match leads
to positive authentication with status code PAM SUCCESS. All other scenarios
(such as a mismatch or timeout) result in the termination of the authentication
process with status code PAM AUTH ERR, thereby invalidating $code output.
Section 4 scrutinizes whether an attacker can bypass this 2FA, for instance, by
tricking pam email.so into exiting with the status code PAM SUCCESS without
being aware of $code output.
4 Security Scrutiny
Once an inventor develops a novel security technique, they must assume an ad-
versarial role to thoroughly understand and patch vulnerabilities in their prod-
uct. Organizational blindness often impedes this task. Therefore, dedicated secu-
rity application testers focus on such jobs. In the present 2FA case of a pluggable
authentication module for e-mail as an additional authentication factor, Grimes
made a name for himself with his article on The Many Ways to Hack 2FA [8].
One year later, he imparted even more hacks and solutions against insecure
2FA with his book titled Hacking Multifactor Authentication [9]. This section
involves self-reflection by leveraging Grimes’ extensive best practices to identify
and mitigate possible attack vectors against the new pluggable authentication
module.
4.1 Man-In-The-Middle (MITM) Attacks
Such a situation occurs when an offender tricks a client into connecting to a ma-
licious node, for example, through phishing, Address Resolution Protocol (ARP)
poisoning, or Domain Name System (DNS) poisoning. Phishing rarely targets
SSH, as only a few clients understand its locator ssh://. Unbeknownst to a
server (with PAM) or a client, an attacker’s node functions as a proxy, sitting
between them and imitating the server’s authentication process. The proxy for-
wards all commands and content from the client and the server to each other. By
offloading and re-encrypting ciphered connections, the proxy can record and/or
manipulate any transferred payload. To the client, it seems as though it com-
municates directly with the server, and vice versa.
An SSH client normally stores fingerprints of trustworthy servers’ private keys
in its local repository. An unknown fingerprint can indicate an MITM attack and
should alert a user immediately.
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 9
4.2 Social Engineering Attacks
An individual or entity fraudulently and maliciously impersonates someone or
something else to obtain unauthorized information or provoke actions contrary to
a victim’s or their organization’s interests. Often, this occurs in person through
phone calls, messaging services, or phishing, similar to MITM attacks. In this
publication, an attacker likely attempts to extract a victim’s password and gain
access to the inbox of their primary and/or secondary e-mail address.
Security awareness training aims to instill a healthy level of skepticism in
potential victims, enabling them to recognize, stop, and report social engineering
attacks.
4.3 Programming Attacks against Server Infrastructure
Once an offender acquires control over a server (with PAM) through malware,
they can operate with the gained permissions. This does not necessarily entail
privilege escalation to superuser rights, administrative access to an LDAP ser-
vice, or manipulation of PAM options.
Nevertheless, the responsible administrators must ensure comprehensive End-
point Detection and Response (EDR), stay up-to-date with critical patching, and
guard against social engineering attacks.
4.4 Programming Attacks against Client Infrastructure
Acquiring control over clients (for instance, with malware) yields less benefit
compared to gaining control over servers. This task proves more achievable, e.g.,
due to less protection provided by EDR.
Generally, users should follow the same protective measures for their clients as
administrators follow for their servers. Additionally, both factors of 2FA should
not store on the same client. If necessary, only a local password manager may
retain the first factor (password). E-mails with ROTPs as second factors should
remain accessible solely by another device in the client’s possession to prevent
automatic usage of malware-triggered ROTPs.
4.5 Recovery Attacks
These actions focus on targeting alternative authentication methods provided by
vendors for recovering MFA-protected accounts. Risks emerge when a recovery
method relies on something less secure than the MFA solution it supports.
The proposal presented in this document assumes users lack the ability to
self-enroll in the required LDAP service or modify it, aside from password up-
dates. Administration personnel handle LDAP account management manually.
The distinctiveness of both registered e-mail addresses per user in LDAP must
undergo technical enforcement. Moreover, both addresses must comply with the
security standards of the PAM-secured service. For instance, both addresses
must allow access exclusively through MFA. To clarify, the primary e-mail ac-
count supports password resets, while the secondary receives ROTPs.
10 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
4.6 Brute Force Attacks (BFAs)
BFAs rank among the most basic forms of cyberattacks. Minimal intelligence
requires little effort to execute. Attackers repeatedly target a victim, making
small adjustments to a single value with each attempt or cycling through all
dictionary words until cancellation, exhaustion, or success. Without defensive
controls to block excessive attempts, this method guarantees eventual success,
though it could take a long time.
A strong password policy must undergo enforcement as a prerequisite. For
PAM with SSH, the default SSHD configuration allows only six authentication
attempts in a row before terminating the session. Furthermore, this document’s
author strongly recommends combining the introduced pluggable authentica-
tion module with a reliable anti-hammering approach that temporarily blacklists
rogue IP addresses. As mentioned in Sect. 1, this policy must maintain strictness
while remaining flexible enough to thwart BFAs and prevent excessive lockouts of
legitimate users due to DoS attacks. Realtime risk monitoring further enhances
security posture [4–6]. For extra security, consider prompting an ROTP via e-
mail before requiring the longer-lasting password. This approach would force a
brute force attacker to correctly guess the active ROTP again before attempting
another password.
4.7 Buffer Overflow Attacks
Such an activity occurs when a program, designed to accept a specific type or
range of data, receives input that exceeds the storage capacity allocated for it.
The pluggable authentication module expects a six-digit ROTP as input. In-
stead, a hacker might insert a large amount of binary executable code, which
not only overwrites the designated storage area but also affects the current ex-
ecutable code within the program. If this overflow happens smoothly, without
causing the module to lock up or terminate, the hacker’s executable code may
run instead of the original program in the module.
The author of this paper developed a prototype for the proposed pluggable
authentication module and conducted buffer overflow attacks against it. All at-
tempts failed because of the module’s automatic memory management and ex-
tensive bounds checking.
4.8 Side-Channel Attacks
MFA components can unintentionally emit waves, signals, or currents that vary
depending on the type of information or activity they handle. A side-channel
attack targets these unexpected signals by eavesdropping on them, as they di-
rectly relate to operations or stored secrets. These leaks may arise from power
consumption, electromagnetic waves, timing, light, temperature changes, and
sound. Many devices experience one or more of these unintended emissions.
Effective defenses against side-channel attacks involve thoughtful design, en-
cryption, shielding, jamming, filtering, distancing, and isolation. All relevant de-
vices must include anti-electromagnetic shielding to block wireless side-channel
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 11
attacks. Additionally, they should incorporate voltage regulators, electrical con-
tainment, random signal noise, and jamming measures to reduce the risk of
wireless eavesdropping. Encryption algorithms resistant to side-channel attacks
should also be employed. While important server infrastructure in data centers
benefits from easier shielding, clients exposed to the public face greater chal-
lenges.
4.9 Physical Attacks
A significant threat arises when an antagonist gains complete or partial phys-
ical control over the client and/or server infrastructure of an MFA solution.
At first glance, physical attacks might provide similar opportunities to those
offered by programming exploits. However, this assumption holds true only if
offenders have already bypassed authentication barriers. Unauthenticated actors
can physically damage or destroy hardware, reducing its availability. Extracting
data from running or powered-off, hard-to-access computing components, such
as Central Processing Units (CPUs), storage media, or Trusted Platform Mod-
ules (TPMs), requires sophisticated techniques like electron microscope attacks
or cold-boot attacks.
For this reason, any device involved in MFA must resist physical tampering.
Additionally, during startup, such devices should perform self-checks for unau-
thorized modifications.
It can be considered that MFA approaches, including the novel pluggable
authentication module for e-mail, face additional attack vectors. Nevertheless,
this section aims to cover all currently known threats as thoroughly as possible.
5 Conclusion
Section 1 motivates this scholarly piece, addressing the constraints of anti-
hammering mechanisms that often fail to adequately handle both BFAs and
DoS attacks. This highlights the need for an effective countermeasure to tackle
credential guessing and account lockouts.
Assuming a PAM framework, Sect. 2 reviews its fundamentals while doc-
umenting a comprehensive survey of scientific databases. The findings reveal
the absence of a pluggable authentication module for e-mail as an additional
authentication factor.
To address this gap, Sect. 3 presents a prototype of such a module, imple-
mented on a typical Linux OS. Since Linux omits e-mail addresses by default
in its user management, an extended LDAP scheme supporting a second e-mail
address per user object for ROTP transmission, along with a related pluggable
authentication module, became necessary.
Recognizing that every MFA solution remains vulnerable to attacks, Sect. 4
conducts threat modeling to identify potential vulnerabilities and weaknesses
12 Citable version at https://doi.org/10.1007/978-3-031-94263-1_2
in the novel module. Although not exhaustive, the analysis categorizes nine
probable attack vectors.
The ultimate objective involves adoption of the developed module by all ma-
jor Linux distributors. Future iterations of this work will focus on enhancements
to achieve market readiness, including extensive penetration testing based on
the established threat model.
Acknowledgments. Many thanks to Bettina Baumgartner from the University of
Vienna for proofreading this paper!
References
1. Binnie, C.: Securing SSH with PAM. In: Practical Linux Topics, pp. 51–59. Apress,
Berkeley, CA (jan 2016), https://doi.org/10.1007/978-1-4842-1772-6_6
2. Chia, J., Chin, J.J., Yip, S.C.: Pluggable Authentication Module Meets Identity-
Based Identification. In: Abdullah, N., Manickam, S., Anbar, M. (eds.) Advances
in Cyber Security, pp. 155–175. Springer Singapore, Singapore (aug 2021), https:
//doi.org/10.1007/978-981-16-8059-5_10
3. Fahrnberger, G.: Contemporary IT Security for Military Online Collaboration Plat-
forms. In: Proceedings of the 18th International Conference on Distributed Com-
puting and Networking, pp. 33:1–33:10. ICDCN ’17, Association for Computing
Machinery, New York, NY, USA (jan 2017), https://doi.org/10.1145/3007748.
3007754
4. Fahrnberger, G.: Realtime Risk Monitoring of SSH Brute Force Attacks. In: Phillip-
son, F., Eichler, G., Erfurth, C., Fahrnberger, G. (eds.) Innovations for Commu-
nity Services, pp. 75–95. Communications in Computer and Information Science,
Springer Cham (jun 2022), https://doi.org/10.1007/978-3-031-06668-9_8
5. Fahrnberger, G.: Bloom Filter-Based Realtime Risk Monitoring of SSH Brute
Force Attacks. In: Krieger, U.R., Eichler, G., Erfurth, C., Fahrnberger, G. (eds.)
Innovations for Community Services, pp. 48–67. Communications in Computer
and Information Science, Springer Cham (sep 2023), https://doi.org/10.1007/
978-3-031-40852-6_3
6. Fahrnberger, G.: Pattern-and Similarity-Based Realtime Risk Monitoring of SSH
Brute Force Attacks with Bloom Filters. In: 2024 36th Conference of Open In-
novations Association (FRUCT), vol. 36, pp. 133–144. IEEE (oct 2024), https:
//doi.org/10.23919/FRUCT64283.2024.10749895
7. Geisshirt, K.: Pluggable Authentication Modules: The Definitive Guide to
PAM for Linux SysAdmins and C Developers: A Comprehensive and Prac-
tical Guide to PAM for Linux: How Modules Work and How to Imple-
ment them. Packt Publishing (jan 2007), https://www.uploadbag.com/ofiles/
5c14a11467c9db666bb31e23df07cba5/Pluggable-Authentication-Modules.pdf
8. Grimes, R.A.: The Many Ways to Hack 2FA. Network Security 2019(9), 8–13 (sep
2019), https://doi.org/10.1016/S1353-4858(19)30107-2
9. Grimes, R.A.: Hacking Multifactor Authentication. Wiley (oct 2020), https://
doi.org/10.1002/9781119672357
10. Kraft, A.: Municipal Cybersecurity Enhancement (jun 2024), https://www.
diva-portal.org/smash/record.jsf?dswid=-8666
11. Lehtinen, S., Lonvick, C.: The Secure Shell (SSH) Protocol Assigned Numbers.
RFC 4250 (Proposed Standard) (jan 2006), https://doi.org/10.17487/RFC4250
Citable version at https://doi.org/10.1007/978-3-031-94263-1_2 13
12. Melnikov, A., Leiba, B.: Internet Message Access Protocol (IMAP) – Version 4rev2.
RFC 9051 (Proposed Standard) (aug 2021), https://doi.org/10.17487/RFC9051
13. Myers, J.G., Rose, M.T.: Post Office Protocol – Version 3. RFC 1939 (Internet
Standard) (may 1996), https://doi.org/10.17487/RFC1939
14. Samar, V.: Unified Login with Pluggable Authentication Modules (PAM). In: Pro-
ceedings of the 3rd ACM Conference on Computer and Communications Security,
pp. 1–10. CCS ’96, Association for Computing Machinery, New York, NY, USA
(1996), https://doi.org/10.1145/238168.238177
15. Sermersheim, J.: Lightweight Directory Access Protocol (LDAP): The Protocol.
RFC 4511 (Proposed Standard) (jun 2006), https://doi.org/10.17487/RFC4511
16. Ylönen, T., Lonvick, C.: The Secure Shell (SSH) Authentication Protocol. RFC
4252 (Proposed Standard) (jan 2006), https://doi.org/10.17487/RFC4252
17. Ylönen, T., Lonvick, C.: The Secure Shell (SSH) Connection Protocol. RFC 4254
(Proposed Standard) (jan 2006), https://doi.org/10.17487/RFC4254
18. Ylönen, T., Lonvick, C.: The Secure Shell (SSH) Protocol Architecture. RFC 4251
(Proposed Standard) (jan 2006), https://doi.org/10.17487/RFC4251
19. Ylönen, T., Lonvick, C.: The Secure Shell (SSH) Transport Layer Protocol. RFC
4253 (Proposed Standard) (jan 2006), https://doi.org/10.17487/RFC4253
View publication stats
