定义
OTP（One-Time Password，一次性密码）是仅能使用一次、通常有时效（如 5 分钟）的验证码，用于身份验证、登录确认、支付确认等场景。OTP 通过 SMS Gateway 以 A2P 短信发送，或通过邮件、Authenticator 应用下发，与 2FA 双因素认证配合，显著增强账户与交易安全。
应用场景
OTP 在 ICMP 中的典型应用：登录验证——2FA 双因素认证，用户输入密码后需再输入 OTP；敏感操作——API Key 创建、权限变更、大额支付等需 OTP 确认；密码重置——验证用户身份后发送 OTP，完成重置；设备绑定——新设备首次登录时 OTP 验证。OTP 通过 SMS Gateway 发送时，属于 A2P 短信，需确保通道合规与送达率。
技术实现
OTP 常见实现：TOTP（Time-based OTP）——基于时间与密钥生成，如 Google Authenticator；HOTP（HMAC-based OTP）——基于计数器；SMS OTP——通过 SMS Gateway 发送随机码。SMS OTP 依赖网络与短信通道，可能延迟或被拦截；TOTP 无需网络，但需用户预先绑定 Authenticator。平台可同时支持多种方式，满足不同客户偏好。
在 ICMP 中的实践
达希物联 ICMP 支持 OTP 验证：IAM 登录、敏感操作可配置 2FA；通过 SMS Gateway 发送 SMS OTP；支持 TOTP Authenticator 绑定；Audit Trail 记录 OTP 验证事件，满足 PCI DSS、GDPR 等合规要求。
短时口令的通道与失效
一次性密码的技术含义，是一段只能成功使用一次、并且很快失效的校验值。基于时间的口令由双方共享的密钥和当前时间窗口计算，不需要平台把口令发出去；短信或邮件口令则由平台生成，经通道送到用户，再由用户回填。无论哪一种，校验成功之后该值或该时间窗口都应作废。它证明的是“持有这个通道或这个密钥的人完成了一次确认”，不是证明设备、卡或公司主体的长期身份。
使用前要选定场景和参数。登录、重置密码、导出清单、确认付款，风险不同，有效期和是否允许重发也不应相同。短信口令依赖号码仍然由本人控制，跨境号码还要确认通道能够送达。时间口令依赖用户事先绑定密钥，时钟偏差过大时要规定允许几个窗口。口令校验应发生在授权或会话建立的环节，而不是只在页面上比对后就信任浏览器。调用管理接口的服务程序不应靠人工转发来的短信口令长期运行，那会把一次确认变成永久凭证。成功和失败都要留下不含口令明文的接口访问记录，便于追查是哪一次操作被确认。
验证码被当成设备身份
容易出错的是用短信验证码代替卡或设备的认证。物联网模组没有人可以回填六位数字，把一次性密码设计成设备入网条件，现场无法执行，也会诱使实施人员把验证码写进固件。另一个错误是验证码可重复使用，或失败次数没有上限。攻击者可以在有效期内反复试，或者截获一条短信后在多处使用。
把口令全文写进日志、工单或客服聊天，等于把第二因素交给了每一个能看日志的人。重发如果过于频繁，用户会同时收到多条，不知道哪一条仍然有效。正确的做法是新口令发出后旧口令立即失效，校验只接受最近一条，并且记录的是“通过或拒绝”，不是口令本身。一次性密码只覆盖这一次人为确认，卡的签约和设备的入网仍要走各自的身份机制。
同一账号在有效期内只保留最近一次发出的口令，新口令生效时旧口令立即作废。连续失败达到约定次数后，应暂时停止校验并要求更换通道或等待冷却，而不是无限重试。客服协助时只能触发重新发送，不能查看口令内容。基于时间的口令还要记录绑定设备的停用时间，用户更换手机后，旧绑定不应继续通过校验。
基于时间的口令要约定允许的时钟偏差。偏差窗口太大，同一个口令可以在较长时间内反复使用；窗口太小，用户手机时间略有出入就会失败。窗口内用过的值要记住，防止在剩余时间内重放。短信口令则不依赖手机时钟，但依赖号码仍由本人掌握，号码变更时应先用原有因素或其他已绑定方式确认，再改发送目标。两种口令的失败计数不要共用一个永远不重置的计数器，否则用户昨天的输错会把今天锁死。
发送频率按账号和目标号码同时限制。只限制账号时，攻击者可以换账号向同一号码刷验证码；只限制号码时，同一人可以换号码不断试自己的账号。限制触发后，界面只提示稍后重试，不说明是账号被限制还是号码被限制，避免给人探测账号是否存在的线索。日志记录限制动作，不记录口令。
一次性密码不能恢复被盗的长期会话。它只在用户提交的那一次确认里有效。确认之后发出的会话仍要有自己的到期和撤销。用户报告验证码被别人看到时，应废止尚未使用的口令，并撤销已经靠该口令建立的会话。只重新发一条新口令，旧会话里的操作还会继续。