会员提问：
先说明我的需求。金融系统手机端修改支付密码，由于支付密码安全等级较高，故需经过双重验证，手机（已和系统绑定）和原密码验证，且任何一步验证都不能被跳过。
下面是修改支付密码的两个逻辑（移动端）。
1.点击“修改支付密码”——直接发送验证码到手机（验证通过）——输入“当前密码”和“新密码”完成。
2.点击“修改支付密码”——输入“当前密码”和“新密码”（当前密码验证通过发送验证码）——验证码验证通过完成。
问题：
对于第一种逻辑，技术这样反馈。存在漏洞，很可能会绕过手机验证这一步，直接跳到当前密码验证，原因如下：
假如手机验证码的接口地址是L1（短信平台用第三方运营商）,密码页面的接口地址是L2。如果知道L2和参数类型，因为L1和L2没有关联，那么可以在浏览器进入L2，从而跳过了手机验证，进而失去双重认证的作用。
请问各位第一种逻辑是不是存在这样的漏洞？目前支付宝钱包采用的是第二种认证方案。
…………………………分割线…………………………………………………………………
下面再说说第一种逻辑的调整方案和我对第二种逻辑的理解，不当之如望大家斧正。
逻辑1.之前有想在L1验证通过的时候给L2传参钱站手机验证码错误，这样L1L2就有关联了。但依然可以直接跳到L2对传递过来的参数和密码进行验证。
逻辑2.第一步跳不过去是因为第二部要对手机验证，而这个验证码必须是通过第一步的密码验证才能获取。可进行简要说明：进入L2，要验证手机，但第一步验证没通过系就没有执行对手机验证这个操作，自然就无法验证手机，所以第一步就无法被越过了。
会员 说：
首先你进入了技术的怪圈，你的需求，技术提出了担心，然后你就进入了各种思考和纠结，我想说的是，这时候，你需要走出怪圈，你要做的是需求的合理性，系统的安全性，也是你的需求，不能让所谓的技术壁垒改变设计思路，导致需求扭曲，可以说，这件事上，保证系统安全性钱站手机验证码错误，技术需要考虑，他们提到的那些问题，技术上是有解的。
需求本身分析：
建议使用方案2，原因：
1、站在使用者的角度考虑问题，人们的习惯是修改密码，先输入原密码，再设置新密码，设置新密码生效的条件是持有性验证（短信），这个逻辑符合用户操作习惯。(界面上应该告诉用户，为了保证支付密码安全性，在确认了短信验证码之后，才能完成支付密码的修改)
2、上面同学也说到的，短信成本，至少原密码用户还记得，就会过滤一些尝试带来的成本
（当然你也需要考虑短信到达率导致无法接收短信的用户，如何修改支付密码，不能让短信成为修改支付密码的瓶颈）
方案1，从产品经理的角度上，更容易想到是方案1，但是这个产品是给用户使用的，所以，站在用户角度看这个问题，更重要些。
会员 说：
为什么设置成L1和L2两个关联呢？还要平白跳转一个界面，如果发生网络延时什么的就要重新刷新，影响用户体验啊。
搂住的目的是为了保证用户帐户安全，直接在一个页面进行两个验证就可以阿。
1、当前密码

2、新密码
3、手机验证码
1、3两个条件全满足则修改成功，反之失败。
———————————————
如果非要在两种方案中讨论，我个人倾向于第二种。第一种确实有可能像技术所说，可以跳过。
伪逻辑代码：
用户提交申请密码代码
第一种逻辑应该是：
if（手机验证通过）//可跳过
{
填写旧密码
填写新密码
修改成功；
}
第二种逻辑是：
if（填写旧密码||设置新密码 ）//可跳过
{
手机验证
修改成功；
}
如果是按照第二种来理解的话，L2界面是修改新密码，L1是手机验证。
（L2-〉L1。）那么我们可以理解为，修改了新密码，但是还仍需要验证手机，才能正确返回修改成功的参数。如果跳过了L2，直接进入L1，是无法修改成功的，故此第二种方法的逻辑上更为严谨稳妥。
会员 说：
逻辑都没有问题，技术更不存在问题（第一步都走假验证，第二步把第一步用户输入参数和当前界面输入的参数一起提交到服务端验证即可）；唯一的问题是哪种体验更优，这个体验就需要从用户使用习惯的角度去考虑了，
这里我们可以模拟两种场景：
第一种场景：用户操作的就是他的账户，产品需要给他提供的是安全感以及易操作型，第一种方式更合适，但是需要把发送短信按钮放在此界面上，让用户主动触发发送短信；第一步会让用户感觉“哇，真是安全，别人没有我的手机就没有办法修改我的支付密码了”；
第二种场景：用户操作的不是他的账户，产品需要给他提供的是修改的难度，理论上来讲手机丢失的可能性低于账号被盗的可能性，所以验证短信验证码的难度更高，第一步就让盗用者感到威慑。