Multi-factor authentication, a mechanism where the user provides two or more loosely coupled evidences of their identity, has become ubiquitous in access management of computer systems. Compared to a single factor authentication, no single piece of information about the user is sufficient for authentication, and account take-over requires obtaining multiple kinds of information about the user.

However, known multi-factor authentication schemes rely on a single user’s knowledge, possession, and inherence. Consequently, while breaking multi-factor authentication is harder than breaking single-factor, password or key based, authentication, it still requires access to a single entity only.

For example, if an additional authentication requires entering a code sent via an SMS to the user’s phone, stealing or observing the user’s phone allows unauthorized access. Similarly, the answer to a ’secret question’, such as mother’s maiden name, can be obtained by getting access to the user’s personal file. With traditional multi-factor authentication, gaining unauthorized access to a computer system still depends on attacking and obtaining information about a single user.

A much harder to break would be an authentication scheme in which multiple people were involved in authentication, and in such a way that identity of people involved in authentication of a user’s access or action is not known in advance. In addition, human beings are notoriously good at identifying their acquaintances — in person or by phone, so that it is deemed beneficial to use person-to-person authentication in addition to person-to-computer authentication in a multi-factor authentication scheme with higher security.

Here, we propose to use a network of social connections of the user to establish a stronger multi-factor authentication scheme by requiring another person chosen among the user’s social connections, or pals to confirm the identity of the user and/or the genuineness of the user’s intent to perform the transaction.

In the following sections, we first describe the pal-based authentication scheme. Then, we analyse and discuss the added security it provides, as well as implementation issues.

Algorithm Outline

Let us consider a user undergoing access authorization to perform a certain transaction, such as payment, adding or updating financial details, money transfer, or access to sensitive information such as the user’s medical record.

When the user logs into the system, in addition to entering the password the user is presented with a random choice of a small subset (for example, 2 or 3 people) out of the list of their friends/relatives (whom they registered with the system) so that one of them also authorizes the transaction. Then, the following happens:

• The user chooses one person (the authentication pal) from the presented random subset.
• The user contacts the other person asking to authorize the transaction or log-in, by phone, email, or in person.
• The system sends the person the authentication link.

From this point on, authentication passes if the other person decides to confirm that the user and the user’s intent to perform transaction are genuine and confirms the original user’s identity. The original user does not have to disclose details of the transaction to their authentication pal, just to convince the pal that they are who they pretend to be.

This is a powerful second factor because it involves ’social authentication’ — the other person must become convinced that the user asking to authenticate is indeed their friend/relative and not an impostor. This can be used selectively when a stronger authentication is required, for example when essential information is changed or disclosed, or when a high-volume transaction is performed.

Example

Consider the following example:

• A logs into the system by sending their user id and password.
• The system maintains a list of A’s pals (registered by A and confirmed by each member of the list, just like friendship in Facebook or connections in LinkedIn): K, L, M, N, O, P.
• Out of the above list, the system chooses randomly two users: L and N and presents them to A.
• A chooses N for pal-based authentication.
• The system sends the authentication link to N by email (or by other electronic communication means), along with an explanation that N should only authorize the authentication attempt if they are sure that A is genuine and not an impostor.
• N and A contact each other. Either side may initiate the interaction.
• After talking to A, N becomes convinced that A’s identity is genuine, and follows the authentication link.
• N authenticates themself to the system (using any authentication scheme, such as single-factor, traditional multi-factor, or pal-based multi-factor authentication depending on risk level and environment) authorizes A’s identity.
• A gains access to the system.

Special cases

A problem arises with repeated failing attempts to authenticate using pal-based authentication.

• If the system presents a different random choice each time, the attacker must only gain access to the email and credentials of a single member of the pals’ list.

• On the other hand, if the system re-uses the same choice every time, then the attacker will know which other identity to steal in order to overcome pal-based authentication.

Because of this, if pal-based authentication fails because the other party actively refuses to authenticate the use, the user’s access should be restricted until the user’s identity is verified using different means. This is not a major issue however if pal-based identification is used selectively, in cases of high risk or high potential loss.

Related to this are different types of rejection during pal-based authentication. The following scenarios are possible:

• The user refuses to use pal-based authentication.

• The user agrees to use pal-based authentication, however the other party chosen by the user is unreachable or does not take an action (neither confirms nor rejects the user’s identity) — which is indistinguishable from the point of view of the system.

• As discussed above, the other party rejects the authentication attempt.

In each of the cases, a fallback authentication and re-validation mechanism must be provided.

Now, what if instead of a napkin one of your colleagues has a laptop or a tablet handy? Imagine that you just grab their laptop or tablet, enter URL enapk.in, type in/draw your idea, and let your colleagues scan the barcode or copy the URL of this napkin. Napkins are stored forever; but are only accessible through their short URLs (just like “tiny URLs”).

This way, any computer is just like a napkin, does not require a log-in to take notes or express ideas. Everyone with physical access to the napkin at the time of writing can later retrieve and use it.

• a client on an old tablet or laptop in your kitchen, (sitting on the fridge and also holding a recipe book),
• and a server serving a web page with shopping check list, automatically updated, to a mobile app.

Every time you run out of something (eggs, sugar, tea, …), you add this thing to the list of ‘missing’ goods (lookup/predictive input make adding easier). When you go shopping, whatever you added is in the shopping list, when you buy, you cross out the entry.

A background knowledge module knows how to measure different things (sugar in kg or packets, eggs are counted, etc.), and suggests default amounts to buy. If you have to buy too often, the amount is automatically increased.

1. get (buy) the whole book to read;
2. read another paragraph from this book;
3. read a paragraph from a similar book;
4. read a paragraph from a different book.

The app can remember user’s past history to adjust suggestions. How paragraphs, similar, and different books are chosen is an interesting question.

For testing/development, free text repositories are available, for example, Project Gutenberg, but also many others.