Knowledge Byte: Multi-Factor Authentication in the Cloud

MFA provides an extra level of security that you can apply to your cloud computing environment. With MFA enabled when you sign into a cloud service, you are prompted for your username and password along with other authentication factors, such as an instant authentication token or biometric verification. Together, these multiple factors provide increased security for cloud computing resources.

Additional security credentials used within cloud services are:

• Access keys (access key ID and secret access key): Access keys consist of an access key ID (AKIAIOSFODNN7EXAMPLE) and a secret access key (wJalrXUtnFEMI/K7MDENG/ bPxRfiCY).
  • You use access keys to sign programmatic requests that you make to your cloud computing service REST or Query APIs.
  • REST APIs use operations and other existing features of the HTTP protocol. For example, layered proxy and gateway components perform additional functions on the network, such as HTTP caching and security enforcement.
  • Access keys are also used with Command-Line Interfaces (CLIs). When you use a CLI, the commands that you issue are signed by your access keys, which you can either pass with the command or store as configuration settings on your computer.
  • Another type of access key is the X.509 system. Within this system, an organization wanting a signed certificate requests one through a certificate signing request (CSR).

Two examples of access keys are as given:

Key pairs: Key pairs consist of a public and private key, where you use the private key to create a digital signature and then your cloud computing services use the corresponding public key to validate the signature.

X.509 certificates: X.509 certificates contain a public key and additional metadata (like an expiration date that verifies when you upload the certificate). Each certificate is associated with a private key. When you create a request, you create a digital signature with your private key and then include that signature in the request, along with your certificate. The receiver (cloud provider) verifies that you are the sender by decrypting the signature with the public key that is in your certificate. Use X.509 certificates only when you must sign SOAP-based requests. In all other cases, use access keys.

Several cloud service providers offer MFA, either as soft (virtual) MFA or as hardware (physical) MFA, such as RSA or Gemalto devices.

Virtual MFA can be used in your:

● Smartphones

● Tablets

● Computers

Most Virtual MFA controls use an open Standard Time-Based One-Time Password (TOTP) algorithm. TOTP is an example of a hash-based message authentication code (HMAC).

Virtual MFA application supports the OATH standard for TOTP and it can easily be configured by scanning a QR code with your smartphone or by manually entering a configuration key provided. The app supports the ability to generate one-time passwords for one or more virtual tokens, making it easier for customers who require MFA protection for multiple identities.

TOTP combines a secret key with the current timestamp using a cryptographic hash function to generate a one-time password. The timestamp typically increases in 30-second intervals, so passwords generated close together in time from the same secret key will be equal.

To run TOTP on your web application, you need the plugins for SHA1 and SHA256 hashing algorithms.

Hardware MFAs (disconnected tokens) are of two types:

Sequence-Based Token

In a sequence-based token, the token may have a button that is pressed to switch it on and display a new passcode. The cumulative number of button pushes can be used as a challenge. The server, however, must assume that the button may have been pressed a number of times since the last actual use, and attempt the authentication with all likely numbers of button pushes.

Time-Based Token

In a time-based token, the token generally contains a quartz time source, allowing the absolute time to be used as the challenge and a new passcode to be displayed (usually) every 30 or 60 seconds. In this case, the authentication server must allow for a drift in the time source by trying the authentication with a previous and subsequent time as well as the current time. It can hence keep track of the drift in the clock.