Hitachi ID Password Manager has an open authentication architecture, and can plug into existing password systems, corporate directories, two-factor authentication tokens, PKI certificates and biometric engines.
Users sign into the Password Manager web portal using some combination of the following methods (which sequences are available is determined by policy, based on user context):
- By typing their current password to a trusted system (e.g., Windows/AD, LDAP, RAC/F, etc).
- By answering security questions.
- By offering up a biometric sample, which is validated by a trusted service or API.
- Using the Hitachi ID Mobile Access smart phone app to scan a cryptographic challenge displayed on the user's PC screen as a QR code.
- Using third party smart phone apps, such as Duo Security or Google Authenticator.
- Using a hardware or software security token (e.g., RSA SecurID).
- Using a smart card with a PKI certificate.
- Using Windows-integrated authentication.
- Using a Security Assertions Markup Language (SAML) or OAuth assertion issued by another server.
- By typing a PIN that was sent to their mobile phone via SMS.
- Using a device/browser fingerprint and/or cookie, for example to compare current login to previous events.
Two factor authentication for everyone
Password Manager supports multi-factor authentication for all users. This includes both an open integration framework with support for all major MFA technologies on the market and an out-of-the-box mobile app that provides a second factor for users who have not yet been provisioned one.
The recommended sequence for authenticating users into the Password Manager web portal (and where it acts as a federated IdP, through into integrated SP applications) is as follows:
- If the user connects from outside the private/secure corporate network, start with a CAPTCHA.
- Next, prompt for the user's login ID.
- Fingerprint the user's browser -- if the indicated user has signed on successfully from the same browser before, this fact can act as an unobtrusive authentication factor.
- If the user connects from a browser or location not seen before,
prompt for another factor, which may be any of the following:
- If the user has been activated to use a third party MFA technology, such as a one time password token (e.g., RSA SecurID or YubiKey) or a third party app (e.g., Duo Security, Google Authenticator, Okta Verify, etc.), use that.
- If the user had previously installed Mobile Access on their phone, either use push notification to display a PIN on their phone or display a cryptographic challenge in the login screen as a QR code, which the user scans with the app.
- If the user had previously enrolled their mobile phone number,
send a PIN to the user's phone, via SMS and prompt the user to
Note: an SMS broker is required to do this, which may cost as much as a few cents per message.
- If the user had previously enrolled their personal e-mail address, send a PIN to that address, on the assumption that the user has e-mail access on their phone.
- Users may be prompted to select one of several MFA options or one of several alternatives for the same option (e.g., send a PIN via SMS to one of multiple mobile numbers or e-mail addresses).
- Finally, depending on whether the user remembers his password, prompt the user to enter it or answer a series of security questions. Using a second, "knowledge" factor reduces the risk of compromised authentication due to lost or stolen phones or hardware tokens.