Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 141

Security tokens such as key fobs are small electronic devices that can be used as part of physical facilities access control or as part of a user login and authentication process. The simplest form of such a token or key fob uses NFC readers to detect the presence of the fob and validate its use as part of granting access through external or internal doors. The provisioning process can tailor the access privileges for each fob for the individual user—for example, allowing guests to freely enter or exit through some doors, but not through others, and only during business hours plus or minus a small margin.

Another common use of a security token is to provide users with an additional identification factor to be used during authentication. Some of these security tokens use an onboard pseudorandom number generator, which is initialized with a seed during provisioning; the same seed is used by a matching generator function in the access control system, which means that the token and the access control system generate the same sequence of numbers as they are repeatedly used. In effect, this provides a limitless one-time pad of secret keys, which can then be used by the chosen authentication protocol. These tokens can either be synchronous, with both the token device and the host access control system moving to the next one-time pad value at controlled time intervals; or asynchronous, which usually requires the user to push a button or activate the token to have it generate and display the next key value in the sequence. Asynchronous token systems often use a login counter value in both the token and the host as part of their synchronization and error detection processes. In either case, users typically must bring the security token physically to the provisioning facility if the token gets out of sync or no longer functions properly. The result of using the security token either can be an additional authentication step or can be appended or prepended to the normal “what you know” password or passphrase and then submitted (suitably hashed, one hopes) to the server for validation.

Security tokens are frequently implemented via mobile device apps. Such so-called soft tokens can provide the same functionality as the physical hard token-based systems do but often can provide important additional benefits. Deployment of multifactor authentication using soft tokens can be a significant cost savings and—with the right mobile device management (MDM) systems approach—be easier to administer. More importantly, such an integrated management of soft tokens and the devices they are associated with allows for more real-time response when a device is reported or suspected to be missing, lost, or stolen (or if its user's privileges are being suspended for other reasons).

Although adding “something you have” to the security stack of authentication is generally sound practice, physical items such as smart card, badges, and tokens can be lost or stolen. Security architectures, policies, and procedures should take this possibility into account and deal with notification and revocation in the wake of such events.

Another concept related to soft tokens is that of an authenticator. Sometimes used synonymously with soft token, the term can also refer to a special onetime code sent to a pre-vetted smartphone. Such authenticators are sometimes invoked in the middle of a login sequence—for example, when a login is attempted by a device unfamiliar to the authentication service. In this case, the code, when read from the phone and typed into the login software, provides a separate, out-of-channel means (such as a separate email to an address on file) of authenticating the request.

Still more complex authenticator schemes involve a challenge-and-response method, whereby the login sequence displays a “challenge.” The user then types the challenge string into an authenticator app on the phone, the app displays a response (often a string of digits), and the user relays the response string back into the challenging software to complete that extra stage of authentication. Amazon, Google, and many Microsoft websites routinely provide this additional challenge-response means as part of authenticating a subject before they can modify their account profiles, for example.