Signing into P-Synch

Users Signing Into P-Synch®

(1)Users authenticate as follows:

On a web GUI:
- By typing their current password to a trusted system (for example Windows / Active Directory, OS/390, RADIUS, etc.).
- By answering a set of system-selected personal questions, whose answers may either be stored inside the P-Synch 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 P-Synch can be configured to have the support staff authenticate the user via the user's Q-A (Question-and-Answer) profile before the user is helped.

Help Desk Analysts Signing Into P-Synch

Help desk analysts can authenticate callers using some designated subset of their Q-A (Question-and-Answer) profile. The use of a subset ensures that some question/answer pairs in the Q-A (Question-and-Answer) profile can remain private to the user and cannot be seen or modified by the help desk analyst, if so required. Analysts may either see the user's Q-A (Question-and-Answer) profile on their web browser interface (less secure, convenient) or they may have to key in answers to personal questions from the caller's profile.

All access by help desk analysts to user profiles, including profile search and lookup, authentication attempts, password resets, etc. are logged and may trigger automatic creation of e-mails and call tracking tickets.

Authentication with PKI Tokens and Smart Cards

If users have client-side certificates (either in their browser or a smart card) and the customer has a PKI deployment, then the web server hosting P-Synch can be configured to authenticate incoming users with their PKI certificates, for one or more virtual directories. If the web server authenticates the user in this way, then P-Synch can be configured to simply trust it (i.e., accept the REMOTE_USER or similar variable right from the web server, as an authenticated P-Synch profile ID).

Strong Q&A Authentication

P-Synch supports multiple question sets in the context of challenge/response authentication:

Each question set either allows users to define their own question-and-answer pairs or requires users to answer some number of pre-defined questions.
Each question set with pre-defined questions has its own, normally unique, list of questions.
Questions may have formatting constraints (e.g., all numeric for use with a touch tone IVR (interactive voice response) system).
Questions sets may be used in different contexts -- self-service authentication, help desk authentication, displayed to help desk staff or mandatory input by help desk staff, etc.
Users may be required to fill in some minimum number of the questions in each set. For example, a question set may have a set of 20 standard questions and users must populate answers to at least 5.
During authentication, some defined number of questions is drawn from each relevant question set, at random, to carry out authentication.
Question sets can be assigned to authentication screens. This makes it possible to serialize the authentication process. For example, users must successfully answer some questions from their pre-defined set before being prompted to answer their own free-form questions. This can force an attacker to compromise some answers before even starting to figure out the answers to others.
Question/answer data in each question set may be stored in different places. For example, data for one question set may be physically on the P-Synch servers, while a second might be accessed on an LDAP directory and a third validated against an HR application.
There is no limit to the number of question sets, questions per set or answers per user.

Careful configuration of challenge/response authentication is required to ensure that it is at least as strong as hard-to-guess and regularly changing passwords.