Frequently Asked Questions for Security Officers
How does Hitachi ID Password Manager (formerly P-Synch) improve security?
Password Manager improves the security of authentication processes:
- A strong, uniform password policy prevents the use of easily guessed passwords and ensures that all passwords are changed regularly.
- Password synchronization discourages written passwords ("sticky notes").
- Consistent, reliable authentication processes ensures that users are reliably identified before accessing sensitive services, such as a help desk password reset.
- IT support staff can be empowered to assist callers without having administrator accounts on every system and application.
- Extensive audit logs create accountability for password resets.
- Encryption ensures that passwords are not stored or transmitted in plaintext.
How does Password Manager authenticate users?
(1)Users may authenticate into Password Manager as follows:
- On a web GUI:
- By typing their current password to a trusted system (for example Windows / Active Directory, z/OS, RADIUS, etc.).
- By answering a set of system-selected personal questions, whose answers may either be stored inside the Password Manager server or may be validated on an existing system (Oracle, LDAP, mainframe and so on).
- Using a security token (e.g., SecurID pass-code or other device).
- Using a PKI certificate or smart card.
- Using a telephone:
- By keying in one or more personal identification numbers (e.g., employee number, date of hire, driver's license number).
- By matching a voice print sample taken at time of authentication against a previously recorded sample on file (biometric voice print verification)
Moreover, if the user decides to call the help desk, then Password Manager can be configured to have the support staff authenticate the caller by asking for answers to security questions before offering assistance.
(2)Administrators (IT staff) authenticate to the Password Manager web GUI as follows:
- By typing a current network OS or directory password.
- By typing a password and validating it against a password hash stored inside Password Manager itself.
- Using a security token (e.g., SecurID pass-code or similar).
- Using a PKI certificate or smart card.
Multiple authentication factors may be configured as required.
How does Password Manager get challenge/response data for non-password authentication?
Users can authenticate to Password Manager by answering security questions, where the data is stored in the Password Manager identity cache or on an existing system (e.g., Oracle, LDAP, mainframe, etc.)
If the data is stored in Password Manager, then it is normally encrypted using 128-bit AES and a server-designated key. Password Manager will use its own methods to retrieve the challenge/response data.
If the data is stored on an existing system, then Password Manager runs a plug-in program to retrieve and validate the data when it is required. Out of the box, Password Manager comes with a plug-in that is capable of retrieving questions and answers from an LDAP directory or AD and another that works with SQL Server.
Can one user "claim" another user's login ID?
To claim another ID in Password Manager, the user must supply the ID he/she wants to claim and the password for that ID. Consequently, one user can only claim another user's ID into his own profile if he already knows the password for that ID -- i.e., this reflects a security compromise that has already happened.
The process to register or "claim" user IDs in Password Manager is as follows:
- Password Manager web server: prompts user to type his network login ID.
- User: types his network login ID.
- Password Manager web server: prompts user to type his current NOS password.
- User: types current password.
- Password Manager web server: validates the password against the
indicated system.
repeat if authentication failed, lockout if too often.
- Password Manager web server: display a profile of already-attached
login IDs / accounts. Prompts for an additional ID/password.
- User: types his login ID and current password for a system
that does not yet appear on the list.
Note: the user does not explicitly specify which system the login ID is for.
- Password Manager server: finds instances of this ID on the
network, from the previous night's list. Eliminates already-assigned
IDs. Tries to connect to each remaining system with the ID/password
entered by the user. For systems where the login worked, adds the
ID to the user's profile. Discards the password.
- Password Manager web server: notifies user of success / failure.
repeat as necessary.
Does Password Manager transmit all sensitive data encrypted?
(3)Data transmitted to and from Password Manager on the network is cryptographically protected, as follows:
| Data transmitted to/from the Password Manager server | ||
| To/From | Algorithm | Key length |
| Interactive sessions | ||
| User browser | SSL (varies) | 128 bits. |
| Trigger password synchronization | ||
| From Win2K/2K3 AD DC | 128-bit AES | 128-bit shared secret. |
| From z/OS | ||
| From Unix | ||
| From LDAP server | ||
| Set passwords, Create/update users | ||
| To Unix agent | 128-bit AES | 128-bit shared secret. |
| To z/OS task | ||
| To RSA Authentication Manager | ||
| To proxy server | ||
| API (application programming interface) | ||
| From calling system / IVR (interactive voice response) | 128-bit AES | 128-bit shared secret. |
| API | ||
| From calling system / IVR | HTTPS | 128 bits. |
| Set passwords, Create/update users | ||
| To target system | native | Varies. Use proxy server when native protocol is inadequate. |
Does Password Manager store all sensitive data encrypted?
Encryption is used to protect stored Password Manager data as follows:
| Data stored on the Password Manager server | ||
| Data | Algorithm | Key |
| Privileged passwords, used to log into target systems | 128-bit AES | 128-bit random |
| Answers to security questions | 128-bit AES | 128-bit random |
| User old password history | SHA-1 | 64-bit random salt |