Road Map: Replacing Passwords with OTP Authentication
Published: 03 November 2010
Many organizations wish to move to the desired state of password reduction because of security and usability concerns, but struggle due to insufficient knowledge about how to get there. In this road map document, Research Director Mark Diodati specifies the strong authenticator selection process. Additionally, he discusses the milestones, decisions, and processes associated with the deployment of a one-time password strong authentication system. A future document will road map the milestones, decisions, and processes associated with a smart card deployment. Milestones include core implementation, identity management integration, distribution and binding, application migration, and the creation of emergency access procedures.
Table Of Contents
- Current State
- Desired State
- Password Elimination vs. Reduction
- Strong Authentication Choices
- Authenticator Selection Process
- 1. Analyze Current and Future Applications
- 2. Is a Clientless Authenticator Required?
- 3. Is Strong Authentication to Windows Workstation a Requirement?
- 4. Do Critical Applications Support RADIUS?
- 5. Do Critical Applications Support SecurID, or Is a SecurID Agent Provided?
- 6. Is PACS Authentication a Requirement?
- 7. Does the Organization Own the Workstation?
- OTP Main Process
- 1. Design the Authentication System to Meet Availability Requirements
- 2. Does the OTP System Require a Directory Service?
- 3. Does the Organization Have a Suitable Directory Service?
- 4. Install a New Directory Service
- 5. On Premises or Hosted?
- 6. Install Production Authentication Servers
- 7. Load the OTP Records into the Primary Authentication Server
- OTP IdM Implementation Sub-Process
- 1. Do You Have an Authoritative Provisioning System?
- 2. Does the Provisioning System Support OTP System?
- 3. Manage Users, Groups, and OTP Devices via the Provisioning System
- 4. Does the OTP System Require a Directory Service?
- 5. Can the OTP System Leverage a Directory Service?
- 6. Does the Organization Have an Authoritative Directory Service?
- 7. Does the OTP System Extend the Schema?
- 8. Manage Users, OTPs, and Groups via Directory Services
- 9. Manage Users and Groups via Directory Services and OTPs via OTP Server
- 10. Manage Users, OTP Devices, and Group Membership via OTP Server
- OTP Distribution and Binding Sub-Process
- 1. Smartphone or Hardware OTP?
- 2. RSA SecurID or VeriSign VIP?
- 3. Assign the User an OTP Serial Number
- 4. BlackBerry or iPhone?
- 5. The Device ID Is Retrieved from BES and Bound to OTP Serial Number
- 6. BES Deploys OTP Software to BlackBerry Devices
- 7. The OTP Software Presents the Device ID as an Activation Code
- 8. The iPhone UDID Is Retrieved and Bound to the Token Serial Number
- 9. The User Downloads the OTP Software from iTunes
- 10. The Activation Code and CT-KIP URL Are Distributed to the User via OOB
- 11. The User Authenticates to the OTP Server
- 12. The Mutual Secret Is Generated on the Device and the OTP Server
- 13. The User Downloads the OTP Software
- 14. The OTP Software Contacts the OTP Server
- 15. The OTP Server Generates the Symmetric Key and Serial Number
- 16. The OTP Software Downloads the Symmetric Key and Serial Number
- 17. The Self-Service Portal Authenticates the User via an OOB Mechanism
- 18. The OTP Server Binds the User to the Credential ID
- 19. "Cookie Jar" or "Birthday Cake"?
- 20. In-Person or Remote Identity Proofing?
- 21. Administrator Binds User to OTP
- 22. OTP Device Is Sent to User
- 23. Self-Service Portal Authenticates User via OOB Mechanism
- 24. Self-Service Portal Activates OTP
- 25. OTP Device Distribution, Identity Proofing, and Binding
- 26. The User Procures an Unbound Hardware OTP
- 27. Self-Service Portal Authenticates User via OOB Mechanism
- 28. The Self-Service Portal Binds the User to the OTP Serial Number
- OTP Emergency Access Sub-Process
- 1. Implement OOB via the Self-Service Portal
- 2. Is the Device Locked or Unavailable?
- 3. Does the OTP Server Support Password Authentication?
- 4. Leverage the OTP Server's Native Password Capability
- 5. Does the OTP Server Support Expiry of Password?
- 6. Use the OTP Server's Password Expiry Feature
- 7. Create a Process to Revert to the OTP Authentication Method
- 8. Do Applications Support Mixed Authentication?
- 9. Create a Process to Change the Authentication to Password
- 10. Create a Process to Revert to OTP
- 11. The User Authenticates to the Self-Service Portal
- 12. Alert the Employee's Manager of the Emergency Access Event
- OTP Application Migration Sub-Process
- 1. Have OTPs Been Distributed to All Users of the Application?
- 2. Train Users to Use OTP with the Application
- 3. Alert Users About the Application Migration Date
- 4. Configure the Application to Use OTP
- 5. Does the Application Support Mixed Authentication?
- 6. Is There Organizational Pressure to Use OTPs ASAP?
- 7. Distribute OTPs to All Users of the Application
- 8. Does the OTP Server Support LDAP Authentication?
- 9. Configure Proxy Authentication to Directory Services
- 10. Implement a Virtual Directory or RADIUS Service
- Making the Most of Your Strong Authentication Investment
©2019 Gartner, Inc. and/or its affiliates.
All rights reserved.
Gartner is a registered trademark of Gartner, Inc. and its affiliates.
This publication may not be reproduced or distributed in any form without Gartner’s prior written permission.
It consists of the opinions of Gartner’s research organization, which should not be construed as statements of fact.
While the information contained in this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information.
Although Gartner research may address legal and financial issues, Gartner does not provide legal or investment advice and its research should not be construed or used as such.
Your access and use of this publication are governed by Gartner’s Usage Policy.
Gartner prides itself on its reputation for independence and objectivity.
Its research is produced independently by its research organization without input or influence from any third party.
For further information, see
Guiding Principles on Independence and Objectivity.