Authentication Reuse

So authentication reuse. When we’re talking about the different factors, it’s worthwhile separating out the concept of a one-time password from multi-factor authentication. So we’ve talked about the different factors. That does not mean that those different factors have to change. So reuseable credentials include typically passwords, or a hard token that you plug into a device, or your fingerprint. These different authentication types don’t change, or change infrequently. So your password, it may change, but it will not change each time you raise an access request. So traditionally, most authentication processes will reuse the credentials. A username and any factors that don’t change, passwords, pin numbers, have an inherent weakness. And that’s that they can be captured, and then they could be replayed.

And they can be replayed until they expire or until somebody discovers the inappropriate access. So as an alternative to this, we have the idea, the concept, of a one-time password. And a one-time password can occur within a single-factor authentication transaction, within a dual-factor authentication transaction, or a multi-factor authentication transaction. What we’re trying to do, though, is to provide a uniqueness to each authentication attempt to increase the level of assurance linking the identity to the person that has asserted that they are linked to that identity. So we get increased accountability as a result. So the one-time password, we can use via SMS messages, via a soft token or a hard token. SMS messages typically are used by large enterprises.

This is where we link a mobile telephone number to an individual. And when they log on, they are sent a text message with some kind of pin number, some kind of information that they use to complete that authentication process. Soft tokens and hard tokens are slightly different. Here, we see a soft token as a piece of software, usually a smartphone app, or a hard token, which is a physical device. And these are synchronized with the server mathematically and so that they generate a code for each individual log-on that can be entered as part of the authentication process. The hard tokens used to be very popular and, with the increase in use of soft tokens, are becoming slightly less common.

Hard tokens we see increasingly restricted to higher levels of assurance, for example, governments, high-security private sector enterprises. We see this with banking as well. Soft tokens, these will pop up on your telephone, on your smartwatch, on your mobile devices, offering you a code, sometimes just offering you an approve or decline request. And what we’re trying to do is to link the individual to the token. The soft token and hard token do have some restrictions. If you do not have the device with you, as a second factor, we’re talking about something you have, then you have an obvious problem. You have an immediate problem in that the individual cannot log on.

Also, with those hard tokens, if they are misplaced or lost, we need to make sure that we have processes in place for revoking access, for invalidating the soft or hard tokens to make sure that somebody cannot misuse them as part of an attack at some point in the future. The soft tokens, as we’ve said, very, very popular now. Companies like Google offer these, and you can use these as part of your log-in into something like Gmail, for example. So very, very popular. Some banks will allow soft tokens. For higher transaction limits, typically they move towards hard tokens. A hard token’s typically more expensive because you are issuing a physical piece of equipment.

And the hard token as well requires consideration in terms of its longevity. Hard tokens typically have a fixed period of life beyond which they expire. For some hard tokens, you can change the battery in them to extend the life. For others, you cannot. So something to be aware of if you’re considering the use of hard tokens. Soft tokens, they can have self-enrollment. You see self-enrollment possible within organizations, and you have a much more stringent enrollment process for the establishment of the soft token. But once that soft token is in place, it makes subsequent access via the second factor easier for people.

Now, the soft token, very, very popular, as we’ve said, with organizations, but do be aware that we need the processes again to establish the soft token that are appropriate and tailored to your organization. Also, be aware that we may want to tie in the revocation of these credentials, of these tokens, soft and hard, with our leavers process. If somebody leaves the organization, that we need to make sure that those tokens become invalidated. For the software token as well, updates to the Android or the iOS platform, the platform that the app is installed to, can also result in the token being invalidated and may require re-registration.

So think about the validity period that you want to issue these tokens for, the default validity period, again, because we may want to limit that to a fixed point in time. Again, think about this as part of your implementation.