Authentication with Hardware Security Keys and WebAuthn in SAP Commerce Cloud

In this article, I give a technical overview of hardware security key-based authentication and take you through a worked example of SAP Commerce and hardware security key integration.

Introduction

Digital transformation is happening everywhere, and as a result, enterprises are turning inside out. Formerly closed systems now reside in the cloud, often outside the traditional zone of control of security departments. When a company exposes its systems and internal information to agents, partners, and customers, security risks increase.

SAP Commerce Cloud is widely used as a platform for bringing B2C experiences into the B2B world. You need to be able to provide peace of mind to your business partners and customers that their sensitive data won’t be compromised. When it comes to opening up such data to anyone outside the company, security becomes a key concern.

In this article, I give a technical overview of hardware security key-based authentication and take you through a worked example of SAP Commerce and hardware security key integration.

In the experiments and PoC, I used hardware keys from Yubico: YubiKey 5 NFC and YubiKey NFC Security Key, multi-protocol key-sized devices supporting FIDO2/WebAuthn.

Let’s start with a short overview of authentication methods, their advantages, and their drawbacks. What’s wrong with good old passwords?

Passwords Are No Longer Enough

According to the market survey from SecureAuth Corp., 39% of companies use password-only authentication. OneLogin reports that 93% of their respondents said their companies have guidelines around password complexity. Single authentication provided by passwords is no longer sufficient, and there are six reasons for that:

• We forget these passwords. Users have problems remembering the passwords used for different web services; these services have different password policies that create password variations that are hard to remember. Easy passwords are guessable.
• We are lazy. People reuse passwords on many sites and tend to use the same password for many accounts. One hacked website leads to others. The easier the password is for the owner to remember, the easier it will also be for the attacker to guess.
• We are gullible. We tend to think that everything around us is built properly, but in fact, the vast majority of websites are built with a virtual duct tape and chewing gum approach. Cross-site scripting vulnerabilities may expose your password in the browser. Keyloggers and other malware snoop passwords. Many websites store your password as plain text.

According to the Market Pulse Survey, 75% of respondents said they reuse passwords across different accounts (compared with 56% in 2014), 47% reuse passwords for both personal and work accounts, and users rarely change passwords for work accounts (23% do this at most twice a year) and personal accounts (67%).

Service providers do not always follow recommendations and security standards. The reasons vary. Last March, Facebook confirmed that it had stored millions of user passwords in plain text for years. Although this did not result in a data breach, we see that even giants deviate from best practices, endangering users’ privacy and business reputation. Of course, for millions of smaller services, the situation is even worse: many of them cut corners and rely on security through obscurity to release early.

In other words, a password is a weak link in this chain. OK, if not passwords, then what? Phishing.

According to Gartner, phishing is the most common targeted method of cyberattack. This method of trying to gather personal information using deceptive emails and websites is the fastest-growing sport in the hacker community. Data protection and security implications in corporations are fundamental today, not only to ensure user privacy but also potentially to save a company from damages worth millions.

Adding a second authentication mechanism is becoming a must in all B2B solutions where security risk is high.

Passwordless Authentication Methods

Passwordless methods can be used for primary and/or secondary authentication steps, as well as a single-factor authentication method where only one step is present. Some methods are designed only for second-factor authentication.

The following methods are generally associated with a passwordless login:

• Involving communication devices and services.
  • SMS-based. One-time passwords sent as text messages. This approach is used by some mobile apps as the only authentication method. It is also widely used as second-factor authentication.
  • A phone callback. You receive an automated phone call that requires you to press any key to confirm your identity.
  • Outgoing phone call. You are asked to dial out to confirm your identity.
  • Email link. You are asked to check the email and click a link. Basically, the link contains a one-time password, but it is usually not human-readable.
  • Email OTP. One-time password sent as an email message.
• Involving third-party services and special devices:
  • OTP (TOTP/HOTP). One-time passwords cryptographically generated by remote services (Google Authenticator) or attachable devices (YubiKey OTP).
  • Cryptographic tokens. Hardware USB tokens (RSA SecurID, U2F Security Tokens).

Some of the methods above assume that the phone number is uniquely associated with a user. In fact, it is not: in many countries, phone numbers are reassigned to new users when abandoned. Text messages and phone calls can be redirected to another device or service. Also, all listed methods require you to be connected to the communication network and to have the specific communication services enabled. For example, when roaming, many people prefer to turn these off, which makes authentication impossible or expensive.

SMS-based authentication is not safe, especially if your mobile provider doesn’t provide the required level of security. Being locked to cellular services, attackers can use social engineering against phone companies to redirect messages and even manipulation of the Signaling System 7 network.

Hardware security keys are currently the best solution for multi-factor authentication. However, they do not guarantee absolute immunity. In March 2011, RSA Security was hacked, compromising up to 40 million tokens, which RSA agreed to replace. Literally a couple of months ago, Google Titan announced free replacement for the keys because of a “misconfiguration in the pairing protocols” and the risk of being hacked. Companies learn from their mistakes, and the latest products seem to be very secure and stable.

Passwordless methods can be used in combination with each other and with password-based methods. Let’s have a closer look at these options.

Single-Factor and Multi-Factor Authentication

Single-factor authentication (SFA) is a process for securing access to a system that identifies the party requesting access through only one category of credentials.

There are two common single-factor authentication methods:

• Username/password, the most common method
• One-time password, by email or SMS (or a link with an OTP sent by email)

The third pattern, “single-factor authentication with a hardware security key only,” is not supported by the main browsers yet. At the time of writing (May 2019), this is supported only by Edge on Windows.

Two-factor authentication, also called two-step verification, adds an extra step to the sign-in process: the second factor.

The most common form of two-factor authentication is mixing password-based authentication with a passwordless approach using SMS services. This assumes that the user has a personal device, a mobile phone, nearby each time the system requests a second verification.

There are two common patterns for two-factor authentication:

• First method: username and password authentication
  Second method: passwordless, such as SMS/phone calls/email links/hardware tokens
• First method: passwordless, such as hardware tokens
  Second method: password (PIN code)

So, hardware security keys can be easily used for second-factor authentication as one-time password generators or as containers of private keys.

Multi-factor authentication (MFA) requires two or more authentication methods combined to log in.

With this method, the authentication credentials are combined from:

• Something the user knows (a password or a PIN)
• Something the user has (customer’s device)
• Something the user is (biometric verification)

The last two components involve hardware devices. Let’s have a look at hardware security keys in detail.

Hardware Security Keys (Tokens)

For many years, one-time password hardware tokens, along with X.509 browser certificates, seemed unbreakable. Some keys, such as Sentinel’s, require installing OS-specific drivers. The need to install drivers and/or use Java applets resulted in a popular backlash.

There are three groups of protocols generally associated with hardware security keys:

• TOTP/HOTP. The hardware one-time-password generators. They are becoming less and less popular because everyone has a much more powerful computer in their pocket: a smartphone, which is capable of doing exactly the same thing. “Gartner’s expectation is that the hardware OTP form factor will continue to enjoy modest growth while smartphone OTPs will grow and become the default hardware platform over time.”
  • TOTP: Time-based One Time Passwords (OTP). Generates an OTP by taking uniqueness from the current time (30-second periods). TOTP passwords can be phished, but require attackers to proxy the credentials in near real time (within 30 seconds) rather than collect them for later use.
  • HOTP: HMAC-based One Time Passwords. Uses two parameters: an increment and a private key. The key and the server increment the counter independently of each other. Because the passwords are not limited in time and smartphones can do basically the same at no cost,
• FIDO U2F. Second-factor authentication. This type of token basically consists of a secure microprocessor, a counter it can increment, and a secret key. For the website, the key creates an HMAC-SHA256 of the domain and a secret key, and uses both to generate a public/private key pair. This pair is used to authenticate. If the user gets phished, the browser sends the phished domain to the security key, and authentication fails because of the domain mismatch. If the attacker somehow managed to clone the security key (it’s generally believed that this is impossible, but let’s say), the system would notice that your increments are no longer monotonically increasing, and at least you would be able to detect that the key has been cloned. See more information about U2F in the next chapters.
• FIDO2/WebAuthn. Passwordless authentication. Can be used for single-factor or first-factor authentication and implements the concept of passwordless authentication. See more information in the next chapters.

In this article, I focus mainly on the last two types of protocols. Both have FIDO in the name. What is that?

FIDO Alliance Standards

FIDO is an organization, founded in 2012, that tasked itself with a mission to make authentication simpler for consumers and easier for service providers to deploy and manage, as well as address “the problems users face with creating and remembering multiple usernames and passwords.”

The alliance has published three sets of specifications for simpler, stronger authentication:

• UAF: FIDO Universal Authentication Framework
• U2F: FIDO Universal Second Factor
• FIDO2, which includes:
  • WebAuthn: W3C’s Web Authentication specification
  • CTAP: FIDO Client to Authenticator Protocol
  • All these protocols are based on public key cryptography and are strongly resistant to phishing, to varying degrees.

Universal Authentication Framework, or UAF

UAF is a standard for passwordless authentication. It involves the use of a client-side authenticator that may sample biometric data such as a face image, fingerprint, or voice print to unlock the private key used for signing the authentication response.

(taken from https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-overview-v1.1-id-20170202.html)

Biometric or PIN authentication in UAF happens locally on the device.

There are three key problems with biometric identification:

• Biometrics are not private. Your ears, eyes, and face are exposed. You leave fingerprints everywhere you go. Someone can record your voice.
• Biometrics are hackable. There are plenty of videos on YouTube demonstrating how iris recognition systems or fingerprints can be fooled if biometric data are compromised and fall into the hands of hackers.
• Biometric characteristics are immutable. When stolen, they cannot be changed [without being reborn].

Universal Second Factor, or U2F

Universal Second Factor (U2F) is meant to replace non-secure SMS-based second-factor authentication with secure U2F token-based authentication. This standard was developed by Google and Yubico. Currently, U2F seems to be the lightest, safest, and most phishing-resistant multi-factor authentication known today.

A U2F token such as the YubiKey performs an authentication handshake with a relying party, such as a website. It not only proves to a website that it’s your unique key, but also requires that the website prove its identity too, preventing lookalike sites from stealing credentials.

With this approach, the user logs in with a username and password as before. The app can also prompt the user to present a second-factor device immediately after, or before, a sensitive operation is requested. The strong second factor allows the service to simplify its passwords (e.g., a 4-digit PIN) without compromising security.

U2F is comprised of two basic components:

• FIDO U2F authenticator, which is basically a key fob.
• U2F JavaScript, to be able to interact with and use security keys via the browser API. There is a more capable extension of this interface, WebAuthn, explained in the next chapter.

These components communicate with each other using a protocol called CTAP1 (Client to Authenticator Protocol). CTAP1 tokens cannot be used without the user entering a username. Its newer version, CTAP2, is capable of storing the username (see the next section), but this mode is not supported by the majority of browsers yet.

The U2F spec contains three functions:

• Register creates a new key pair.
• Authenticate signs with an existing key pair after the user confirms physical presence (YubiKey — by tapping).
• Check confirms whether or not a key pair is known to a security key.

What is important is that users can self-provision their own security keys. There is no need to get them registered upfront by admins, as it was with first-generation keys.

Registration flow:

• The user logs in using a username and password.
• The server hashes the password using the Scrypt, Argon2, or bcrypt hashing algorithms and saves it into the server’s database.
• The user adds their device. The device generates private and public keys. The private key resides in the device, while the public key is sent to the server. The server saves the public key into the database and associates it with the user.

Authentication flow:

• The user logs in using a username and password.
• The server hashes the password and compares the hash with the one in the database.
• The server generates a random challenge and sends it to the client along with the ID.
• The browser sends a challenge, ID, as well as token binding and the origin (domain), to the hardware key using the CTAP1 protocol.
• The hardware key signs it with the private key (one for the ID) and sends it back to the browser.
• The server validates the signature against the public key for the user and initiates the session if everything is in place.

There is also a software “keyless” implementation of the authenticator, Soft U2F.

The following browsers currently support the use of U2F security keys:

• Google Chrome, version 38 and later.
• Opera, version 40 and later.
• Mozilla Firefox, version 57 and later. Most Firefox versions that currently support U2F do not enable support by default. You need to activate security.webauth.u2f in about:config.
• Microsoft Edge 11 build 17723 and later.

FIDO2 and WebAuthn

FIDO2 is an evolution of the U2F standard and is backward compatible with it. It has two parts:

• WebAuthn – JS API for account management based on public keys. This is a W3C standard, which means all browsers should eventually support it.
• CTAP2 – Client-to-Authenticator 2, a standard communication protocol for USB, NFC, and BLE devices. It utilizes a CBOR message format (RFC 7049) for security and performance. It is backward compatible with U2F (CTAP1).

WebAuthn has two flows:

1. U2F flow, also known as Client to Authenticator Protocol v1 (CTAP1), and
2. Passwordless flow, CTAP2.

The authenticator generates and securely stores credentials. Private keys, PINs, and biometric information never leave the authenticator. It is a write-only device and onboard app with standard interfaces.

One of the major enhancements of CTAP2/WebAuthn devices is that they are able to store private keys in persistent memory along with the username and domain. That makes it possible to provide an identity (username) and authenticate it in the same flow.

When a website prompts a user to get authenticated, and the user taps on the connected key, the website (browser → JavaScript → server) receives a signal that the user can be authenticated, as well as the username and domain.

Because the standard is too young, Chrome and Firefox don’t yet support passwordless authentication. If you want to try it, use Windows 10 v.1809+ with Microsoft Edge. Yubico says that the latest macOS with Safari Technology Preview is also capable. On my machine, Safari T.P. Release 82 with Web Authentication activated couldn’t detect YubiKey 5 NFC.

By 2022, Gartner predicts that 60% of large and global enterprises and 90% of midsize enterprises will implement passwordless methods.

All major browsers are on track to implement the Web Authentication API. As of May 2019, Edge, Firefox, Chrome, Opera, and Android browsers support WebAuthn. Apple is working on integrating it into its products. The latest Safari Technology Preview already includes some support.

It may sound confusing, but “supporting WebAuthn” doesn’t mean “supporting WebAuthn in full.” For example, Google Chrome and Firefox have implemented only the U2F flow of the spec, and Firefox’s feature needs to be manually activated. The CTAP2 (passwordless) flow is not yet available in all browsers except Microsoft Edge at the time of writing. Because the standard has already been approved by W3C, this will definitely happen one day, and major services have already added support to their products to get 100% ready. Both WebAuthn and the FIDO2/FIDO U2F authentication protocols are already supported by Dropbox, Facebook, GitHub, Salesforce, Stripe, and Twitter, with other popular websites expected to integrate support for these standards in the coming months.

Registration Using WebAuthn

1. The website generates a challenge – a random code. It prevents replay attacks.
2. The website creates an instance of PublicKeyCredentialCreationOptions.
3. The browser executes a create command of the Web Authentication API (JavaScript: navigator.credentials.create).
4. The browser validates rp against the origin. It prevents phishing.
5. The authenticator checks user presence and consent. It prevents silent tracking. For example, the user is asked to touch the USB fob.
6. The authenticator creates a pair of keys: private and public. The secret key is not shared with the browser. It is inside the authenticator. The browser will receive the public key.
7. The website verifies the attestation signature created by the authenticator, namely:
   • Origin against the top-level domain from the package
   • Challenge against the original challenge
   • The validity of the public key signature
8. The attestation is added to the user account.

The details are well explained here: https://developers.yubico.com/FIDO2/FIDO2_WebAuthn_Developer_Guide/WebAuthn_Client_Registration.html

Integration with SAP Commerce Cloud

Find below screenshots from the proof-of-concept project of YubiKey integration with the SAP Commerce Cloud out-of-the-box Powertools Accelerator. It demonstrates how registration works:

Step 1. The customer uses the out-of-the-box password-based authentication.

Step 2. The customer can, may, should, or must — depending on the business security requirements — add a secondary authentication method:

Step 3. The customer adds their security key to the account. The customer clicks on the “ADD SECURITY KEY” button:

“Next”: the browser asks for proof of user presence:

Touch the Yubico fob inserted in the USB port:

And user consent:

The key has already been registered. The system asks for a name for the key. By default, the name is built from the first name of the user (from the profile) and a key number.

“Next,” and we see our key added to the system. You can add more than one key.

Authentication Sequence: The Second-Factor Mode

In the second-factor mode, the username is known in this process: the user entered it before the process starts.

1. The website generates a challenge – a random code. It prevents replay attacks.
2. The website sends the challenge, top-level domain (rp), and username (user) to the browser using the Web Authentication API (JavaScript: navigator.credentials.XXXXXXXXXX).
3. The browser validates rp against the origin. It prevents phishing.
4. The authenticator checks user presence and consent. It prevents silent tracking and covert login.
5. The authenticator retrieves the private key for the user from storage.
6. The authenticator checks and signs the client data (hashed challenge + domain) with the private key and sends the signed package back to the browser.
7. The browser sends this information to the website.
8. The website validates the response:
   • The website checks the challenge against the original challenge.
   • The website checks the origin against the top-level domain from the package.
   • The website checks the validity of the private key signature. It prevents man-in-the-middle attacks and phishing.
   • The website checks the data against the public key that was stored in the database (see registration).

Integration with SAP Commerce Cloud

The simplest implementation activates the second authentication method once the first has been passed:

Click “Log in.” If the user has only one second-factor method configured and password authentication is the first-factor method, there is no need to show a “use alternative methods” link. However, if you have more than one second-factor method configured (for example, a U2F/FIDO2 hardware key, one-time password, or text message), you need to implement a simple pop-up window with a list of methods and allow the choice of one option from the list. For the single second-factor method configured, we can request the browser OOTB window. This is what it looks like in Google Chrome:

In Firefox:

Insert the key you used at registration, and touch the key.

If the user attempts to use a fob not assigned to the account, the system shows the following message:

The system knows what public key is expected from the user, and this check is performed by the browser, not JavaScript.

Authentication Sequence: The First-Factor Mode

In the first-factor mode, the username is not known. The username is sent along with the signature from the device, so the user doesn’t have to enter a username. The website just finds a user with the user handle received from the authenticator, retrieves a public key associated with the user, and checks the validity of received data against the public key.

You might say that it is insecure: if the fob is lost, someone else can access the system. That is why “first-factor mode” is not the same as “single-factor mode.” The customer can (or even is required to) select two or more authentication factors: one is from the “what I have” group, such as Yubico key authentication, and another is from the “what I know” or “what I am” group, which can be a PIN code, password, or biometrics. For the password case, the password form is available only if the YubiKey is valid. Unlike in the second-factor authentication mode, the attacker can’t brute-force the password or PIN code because the login form is not available. It makes the password/PIN code requirements much simpler: even a four-digit PIN will work well if the number of failed attempts is limited to a few.

SAP Commerce Integration

1. Multi-factor authentication configuration page

• List of second-factor methods
• Add a new security key
• Remove a security key

2. Enhanced login page (with 2FA)

• Check if the second-factor method is in play and configured
• Show the pop-up if more than one mechanism is configured; one is selected by default (available for the device)
• Activate the second-factor mechanism if present/selected

Yubico OTP (One-Time Password)

OTP is one of six applications available on YubiKey 5 NFC. Think of this as an app inside the key, or the key’s extra capability. OTP stands for One-Time Password. With this feature, your key is basically another external keyboard with a single button. Touching this button generates a 44-character keystroke that can be processed by any app capable of working with user input.

OTP is a simple yet strong authentication mechanism that can be used as the second factor in a two-factor authentication scheme or on its own, providing single-factor authentication.

The most common pattern is using OTP in combination with username and password:

Because of the ability of YubiKey OTP to emulate a USB keyboard, it works from any computer for any number of applications with only user-level rights and no client software needed. When you touch the key, it generates a series of keystrokes from a virtual keyboard. There are no special drivers that need to be installed to use the fob. Any browser will support OTP if the app in the browser is designed to support OTP authentication.

The architecture diagram of SAP Commerce Cloud / YubiCloud integration for OTP mode:

All one-time password generators are vulnerable to phishing and social engineering attacks. The problem is that the generated password can be stolen by the attacker because it is exported to the form in plain form.

The following diagram shows how OTP generation and check are implemented in the YubiKey services:

Thanks

The author would like to thank Igor Sokolov for constructive criticism of the article, advice, and recommendations.

Useful Links

• https://github.com/Yubico/java-webauthn-server
• https://www.imperialviolet.org/2018/03/27/webauthn.html
• https://developers.yubico.com/yubico-java-client/
• https://github.com/elukewalker/PasswordlessWorkshop
• https://www.theverge.com/2019/2/22/18235173/the-best-hardware-security-keys-yubico-titan-key-u2f
• https://support.yubico.com/support/solutions/articles/15000014219-yubikey-5-series-technical-manual