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, the enterprises are turning inside out. Formerly closed systems reside in the cloud, often outside of the traditional zone of control of security departments. When the company exposes its systems and internal information to agents, partners, and customers, the security risks are growing. SAP Commerce Cloud is widely used as a platform for taking B2C experience 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 the 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 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 which are hard to remember. Easy passwords are guessable.
• We are lazy. People reuse passwords at 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 it, 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 is built with virtual duct tape and chewing gum approach. Cross-site scripting vulnerabilities may expose your password in the browser. Key loggers and other malware snoop passwords. Many websites store your password as plain text.

According to 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 rarely changing passwords for work accounts (23% do this at most twice a year) and personal accounts (67%). The service providers do not always follow the recommendations and security standards. The reasons are different. Last March, Facebook confirmed that they store millions of user passwords in the plain text for years. Although this did not result in the data breach, we see that even giants deviate from the best practice endangering user’s privacy and business reputation. Of course, for millions of smaller services, the situation is even worse: many of them cut corners and go with 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 a cyber attack. This method of trying to gather personal information using deceptive e-mails and websites is the fastest growing sport in the hacker community. Data protection and security implications in the corporates are fundamental today not to only ensure user privacy but to also potentially save a company from damages worth millions. Adding the 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 of communication devices and services.
  • SMS-based. One-time password sent as text messages. This approach is used by some mobile apps as the only authentication method. It is also widely used as a 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.
  • E-mail link. You are asked to check the e-mail and click a link. Basically, the link contains a one-time password, but it is usually not human readable.
  • E-mail OTP. One-time password sent as an email message.
• Involving of 3rd party services and special devices:
  • OTP (TOTP/HOTP). One-time passwords cryptographically generated by the 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 so: in many countries, the phone numbers are reassigned to a new user 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 have the specific communication services enabled. For example, being in roaming many prefer to turn these off that makes the 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 the cellular services, the attackers can use the social engineering of phone companies to redirect messages and even manipulation of the Signaling System 7 network.

Read more

‘Sim swap’ gives fraudsters access-all-areas via your mobile phone, The Guardian, 26 Sep 2015. SIM swap fraud: The multi-million pound security issue that UK banks won’t talk about, International Business Times

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 have agreed to replace. Literally a couple of months ago, Google Titan announced free replacement for the keys because of the “misconfiguration in the pairing protocols” and risk of being hacked. The 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 password-based. 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 e-mail or SMS (or a link with OTP sent by email)

The third pattern, “single-factor authentication with a hardware security key only”, is not supported by main browsers yet. At the time of writing (May 2019) this is only supported 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 a password-based authentication with a passwordless approach with the use of 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/e-mail links/hardware tokens
• First method: Passwordless, such as hardware tokens Second method: Password (pin code)

So, hardware security keys can be used with ease for the second-factor authentication, as one-time password generators or as containers of private keys. Multi-factor (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)

Last two components involve the hardware devices into play.  Let’s have a look at the hardware security keys in detail.

Hardware Security keys (tokens)

Many years one-time password hardware tokens along with X.509 browser certificates seemed unbreakable. Some of the 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 the 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 the exact 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-sec periods). TOTP passwords can be phished, but requires attackers to proxy the credentials in near real-time (within 30 sec) rather than collect them later on in time.
  • 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 with no cost,
• FIDO U2F. Second-factor authentication. This type of token basically consists of a secure microprocessor, a counter which it can increment, and a secret key. For the website, the key creates a 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 would send a phished domain to the security key, and authentication would fail because of the domains mismatch. If the attacker somehow managed to clone the security key (it’s generally believed that it is impossible, but let’s say), the system would notice that your increments are no longer monotonically increasing, and at least detect you will 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’s tasked itself with a mission of making the authentication simpler for consumers and easier for service providers to deploy and manage as well as addressing “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 and
  • CTAP: FIDO Client to Authenticator Protocol
  • All these protocols are based on public key cryptography and strongly resistant to phishing (to varying degrees).

Universal Authentication Framework, or UAF

UAF is a standard for passwordless authentication. It involves the use of client-side authenticator which may sample biometric data such as a face image, fingerprint, or voice print to unlock private key used for singing the authentication response. (taken from https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-overview-v1.1-id-20170202.html) The 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 facet 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 the biometrics data are compromised and fell into the hands of hackers.
• Biometric characteristics are immutable. When stolen, it cannot be changed [without being re-born].

Universal Second Factor, or U2F

Universal Second Factor (U2F) is meant to replace second-factor authentication from non-secure SMS-based to secure U2F token based. This standard was developed by Google and Yubico. Currently, U2F seems to be the lightest, safest and phishing-resistant multi-factor authentication known today. A U2F token like 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 proves 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 the sensitive operation is requested. The strong second factor allows the service to simplify its passwords (e.g. 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 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 CTAP1 (Client to Authenticator Protocol). CTAP1 tokens cannot be used without the user entering a username. Its newer version, CTAP2, is capable to store the username (see the next section), but this mode 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 the physical presence (Yubikey – by tapping),
• Check confirms whether or not a key-pair is known to a security key.

What is important is that the users can self-provision their own security keys. 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 devices 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 a CTAP1 protocol.
• The hardware key signs it with the private key (one for the ID) and sends 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:

FIDO2 and Webauth

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

• WebAuthn – JS API for account management based on public keys. This is a W3C standard, that means all browsers should eventually support it.
• CTAP2 – Client-to-Authenticator 2, a standard of the communication protocol for USB, NFC and BLE devices. It utilizes a CBOR message format (RFC-7049) for security and performance. 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.

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 the private keys in the 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 activated Web Authentication 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 Web Authentication API. As for May 2019, Edge, Firefox, Chrome, Opera and Android browsers support WebAuthn. Apple is working on integrating it into their products. The latest Safari Technology Preview includes some support already. It may sound confusing, but “supporting WebAuthn” doesn’t mean “supporting WebAuthn in full”. For example, Google Chrome and Firefox have only implemented 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 but 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 the 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 attack
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. 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. 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. Website verifies 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 the 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) to 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 a user presence proof: 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 attack
2. The website sends the challenge, top-level domain (rp) and username (user) to Browser using 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 the 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 validate the response:

• Website checks the challenge against the original challenge
• Website checks the origin against the top-level domain from the package
• Website checks the validity of the private key signature. It prevents man-in-the-middle and phishing.
• Website checks the data against the public key which 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 the 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, 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 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 the 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 “the single-factor mode”. The customer can (or even is required to) select two or more authentication factors, one is from “what I have” group, such as a Yubico key authentication, and another is from “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 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 key’s extra capability.  OTP stands for One-Time-Password. With this feature, your key is basically an another external keyboard with a single button. Touching this button generates a 44-character keystroke which can be processed by any app capable to work with the 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 passwords generators are vulnerable to phishing and social engineering attacks. The problem that the generated password can be stolen by the attacker because it is exported to the form in the plain form. The following diagram shows how OTP generation and check is 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