昨晚喝了点酒，结果 4 点多一点就醒了，一直到现在睡不着……
不讨论短信下发延迟，以及短信平台哪家强的问题。
问一下你们的验证码短信失效时间是怎么定的？一般流程是点击发送验证码按钮后，会禁用按钮并做 60 秒倒计时，超时之后可以重新点击发送验证码。
我司目前的做法是，短信验证码的时效是 60 秒。也就是你第二次点击发送之后，会生成一个新的验证码。
这里面会遇到一个问题：短信下发延迟。也许你在使用短信验证码的时候，点了发送没反应，过了 60 秒再点，咦，收到了 2 条验证码，并且验证码不一样。该输入那个呢（有可能最后收到的反倒是已经失效的那个）？当然非要说一个一个试那也可以。。。
因此我建议服务器端生成验证码后，失效时间改为 180 秒，当 60 秒后用户重新点击，继续将当前的验证码下发给用户，这样就不会造成收到 2 次验证码不一致的小困扰了。
然而，我们技术同学没有同意（嗯，我就是攻城狮门所不齿的产品汪）
你们是怎么做的呢？
 | 1 ys0290 Aug 11, 2016 via iPhone 我不懂，但我知道有些验证码有编号，比如请注意查收编号为 xxx 的验证码，然后手机上会出现编号为 xxx 的验证码，这应该错不了了吧？ |
 | 4 9hills Aug 11, 2016  1 @clearbug 你的验证码是 [131211] ，验证码序号是 [4] ，有部分网站是这么做的 说正题，这个我见过三种解决办法： 1. 验证码加序号，页面提示输入序号 x 的验证码 2. 验证码有效时间 > 超时时间，超时下发时，重发有效期没有过的验证码 3. 验证码有效时间 > 超时时间，超时下发时，发送新的验证码，但是前后两次的验证码均有效，输入任意一个即可 自由选择吧 |
 | 5 imnpc Aug 11, 2016 银行用的编号标识的多 就是显示网页编号 收到的短信也有这个编号 这样一一对应才有效 |
 | 6 tianshiyeben Aug 11, 2016 via Android 我们是这样做的，验证码十分钟过期，也就是说十分钟内发送的验证码都是相同的 |
 | 7 NeoAtlantis Aug 11, 2016 我见过的一种， 是直接发送类似 ABCD-123456 这样的，然后在网页上提示就是 请输入 ABCD-[（方框）] |
 | 8 xmgit Aug 11, 2016 短信验证码具有强时效属性，还是用编号来区分吧，编号在点击获取的时候网页端随机出一个，再在短信里一一对应。每次获取短信的时候编号都替换掉。 这样就算短信泄漏了，被发送到第三方邮箱，也没有关系。 因为总觉得安卓手机太不安全了。 |
 | 9 int64ago Aug 11, 2016 本来就是这样吧，验证码的失效时间通常比较长，一般短信后面也会跟说下，比如 xxx 分钟内有效，发送间隔的限制一般是为了防误点 /乱点 |
 | 10 imn1 Aug 11, 2016 google 的身份验证器，也是定时变换，试过输入过程中，验证器显示已经变换了，也就是说已经生成新的了，提交前一个也有效 |
 | 11 TimePPT PRO 下发验证码的 CD 时间和验证码本身的有效时间是两码事啊 |
 | 12 zado Aug 11, 2016 看需要取舍，时效越短越安全，但体验越不好。多条短信的话用编号或前缀区分都是个好办法，同时有效的话不利于安全，也会给用户困扰（用户会疑惑到底是那个有效）。 |
 | 13 whisperer Aug 11, 2016 验证码为： XXXX 发送时间： 22 点 20 分 加一个发送时间，建设银行就是这么做的 然后最好网页上再提示：请输入 22 点 20 分 发送的验证码 |
 | 14 SourceMan Aug 11, 2016 via iPhone 以最后一个为准 |
 | 15 UnisandK Aug 11, 2016 短有效时间的短信验证码必需配合三大运营商送达毫无延迟的短信平台，否则很可能留给用户的输入时间都是按秒算的 楼主的做法感觉挺好的，两条相同的验证码看到的瞬间就会明白不用纠结输入那条，用户体验比较好。不过有效时间的逻辑上估计最好再加个刷新，防备由于第一次与第二次点击之间的间隔时间造成用户第二次点击时有效时间剩余过少的问题 |
 | 17 elgoog1970 Aug 11, 2016 我们的短信发送的验证码有效时间设置为 180ms ， 而前端的按钮是 60ms.是用 redis 进行存储数据：） |
 | 18 marvinwilliam Aug 11, 2016 请求发送验证码,先判断缓存中这个手机有没有发过,发过-等待,没有发过-请求发送短信. |
 | 19 helloliao OP 总结了一下大家说的，基本上和 @9hills 说的三种方式一致。但从实现方案上来说（我们目前是短信失效时间＝前端页面的倒计时时间）： 1 、编号的形式（ ABCD-[XXXX]与编号实际上是相同的方案），要做前端页面、后台验证上的调整； 2 、也就是我说的方案，验证码有效期>前端页面倒计时时间，点击重新发送之后，继续发送当前验证码。这种方案技术上改动工作量最小 3 、多次验证码都生效。这种方案的实施难度最高了。需要考虑到“关联”的验证码之间的管理，如果技术方案没做好，相对的安全风险较大。 对于验证码使用场景来说，基本上如果时间过长，用户也就可能离开了，所以太长时间并没有意义，且可能存在一定的安全隐患。 |
| 20 helloliao OP 其实我是建议我们这边使用主、从短信下发平台的。因为通常用户需要点击再次下发验证码，基本上都是短信延迟，没有收到短信（也可能被拦截，但几率很小），为了避免用户等待的焦虑，页面上的重新发送验证码倒计时从 60 秒 改为 30 秒，并且点击重新发送验证码之后，采用第二个平台发送。这样的话才用上面说的第二套方案，体验更优。 |
 | 21 sarike Aug 11, 2016 这次产品汪的要求是合理的。 给产品汪鼓掌……  |
 | 22 function007 Aug 11, 2016 @elgoog1970 180ms...doge |
 | 23 cnZary Aug 11, 2016 @elgoog1970 ms 是毫秒.... |
 | 24 realpg PRO 一般来说 我比较喜欢如下设定 JS 限制重新发送间隔 60 秒 后台限制重新发送间隔 45 秒 验证码写入 redis 队列，有效期 300 秒 如果上个验证码没有被消费，那么再次读取延长验证码有效期 300 秒，仍然用原来的验证码 如果之前用户有后台验证输入失败的记录，那么再次请求下发新验证码无视 300 秒有效期剩余量重新生成新的 |
 | 25 yexiaoxing Aug 12, 2016 @elgoog1970 180ms... 我手机还没打开就过期了 |
 | 26 jlj224 Nov 30, 2016 这种验证码一下收到两条属于你手机的问题。一般来说因为第一条丢失了，发送了第二条又激活了第一条。我们用的是 SUBAMIL http://submail.cn/ 验证码到达速度很利索。 |
Select Language