Protecting access to sensitive information and providing strong authentication for all financial transactions is expected of any financial app. However the hardware limitations, platform semantics and the lack of knowledge of most users make the hard problem of securing access harder.
Authentication is usually done based on either what user knows (password, PIN, etc.), what user has (token, chip card, etc.), or what user is (biometric data). The password based model that is still being used by many financial apps and services is fraught with security vulnerabilities. Services often rely on additional, second factor authentication in the form of a one time password (OTP) sent through SMS. This model is reasonably secure in the desktop browser world, but it is broken in the android world, since most apps and most human attackers can access the data stored on an Android device, such as the SMS messages.
We believe that the password model, the OTP model and models that combined the two are unreliable for a financial application. Biometrics based approaches are impractical for a large number of Android users. We couldn’t always rely on what user knows, as it was impractical to expect all the users to be cautious in both specifying what they know and to not share the same information with others. We brainstormed a few approaches that rely on what user has and what user is. Trusted Contacts is one such model that relies on both what user has and what user is in an interesting and simple way.
Trusted Contacts relies on humans as the challengers and the verifiers of identity. Humans naturally use biometrics and other ambient signals to authenticate people in everyday interactions. This process is too complex for a machine to emulate and is practically infeasible. With Trusted Contacts, we wanted to rely on this natural power of humans and convert the result of such authentication to a value which is easily representable, transmittable and has sufficient entropy. Such a value, can then be presented to the system and be used for authentication by the user who was challenged.
A user first sets up his Trusted Contacts by nominating a set of at least 3 contacts identified by their mobile numbers. The nominated contacts need not be users of our system. The contacts are informed about their nomination and their role in securing the user’s account. They are told that when the user attempts to re-login from a clean state they will receive a code from Zeta. The contacts are requested to ascertain the identity of the user before they share the code they received.
When an existing user attempts to login, he is challenged with OTP based first factor. After successful authentication with an OTP, if the user has his Trusted Contacts setup, he is challenged to provide authentication codes from at least 2 of the nominated contacts. The User indicates the contacts he would like to rely on in this particular instance. Zeta sends codes to those contacts along with a brief reminder about their role in this exercise. The user is expected to get in touch with his trusted contacts and receive the codes. If the user provides the right codes, he is given access to his account with Zeta.
 |
 |
During authentication, the interaction between User and his contacts is unknown to the system. The system does not provide any hints other than the name (and possibly a picture, in the future) of the contact as known to Zeta, on how to contact and/or how to establish identity. Authentication codes are securely generated 4 digit random numbers and are specific to the current authentication session of the user. As of now, the authentication codes are sent to contacts by SMS. If the contact is a Zeta user as well, we intend to use secure channels to communicate authentication codes. We intend to provide hints to the contacts on how they could challenge the user, so that they are alerted to the sensitivity of the role and can fulfil it meaningfully.
If the contacts play their role reasonably well, we believe this model will be highly reliable. Given the required human interaction involved, it will also be a very unattractive target for computerised attacks. While the contacts are also likely to have Android phones, we have tried our best to make the auth code SMS messages not usable by malware and spyware.
The success of this feature and thereby the reliability of the security it can offer hinges a good deal on the user education and the overall user experience. We have done several iterations to arrive at the current interactions. We do believe that there is a lot of room for improvement in the overall Trusted Contacts experience. However, we think it is sufficiently ready for initial adopters and to gather feedback. We would love to hear what you think!
NOTE: Trusted Contacts in isolation is not sufficient security measure or a complete authentication approach. This is only one of the elements of a more elaborate system and application security model and relies quite heavily on other modules of the model to provide the security we rely upon.