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.
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.
IntroductionDigital 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 EnoughAccording 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.
Passwordless authentication methodsPasswordless 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)
Single-factor and Multi-factor authenticationSingle-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)
- 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)
- Something the user knows (a password or a PIN)
- Something the user has (customer’s device)
- Something the user is (biometric verification)
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.
FIDO Alliance standardsFIDO 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 UAFUAF 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 U2FUniversal 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.
- 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.
- 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.
- 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
- 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 WebauthFIDO2 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).
- U2F flow, also known as Client to Authenticator Protocol v1 (CTAP1), and
- Passwordless flow, CTAP2.
Registration using Webauthn
- The website generates a challenge – a random code. It prevents replay attack
- The website creates an instance of PublicKeyCredentialCreationOptions.
- Browser validates rp against the origin. It prevents phishing.
- The authenticator checks user presence and consent. It prevents silent tracking. For example, the user is asked to touch the USB fob.
- 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.
- 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
- The attestation is added to the user account.
Integration with SAP Commerce CloudFind 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 modeIn the second-factor mode, the username is known in this process: the user entered it before the process starts.
- The website generates a challenge – a random code. It prevents replay attack
- The Browser validates rp against the origin. It prevents phishing.
- The Authenticator checks user presence and consent. It prevents silent tracking and covert login
- The Authenticator retrieves the private key for the user from the storage
- The Authenticator checks and signs the client data (hashed challenge + domain) with the private key and sends the signed package back to the browser
- The Browser sends this information to the website
- 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).
Authentication sequence: the first factor-modeIn 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
- Multi-factor authentication configuration page
- List of second-factor methods
- Add a new security key
- Remove a security key
- 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:
ThanksThe author would like to thank Igor Sokolov for constructive criticism of the article, advice and recommendations.