iOS 注册密码加密 添加了时间戳 遇到的问题...

今天项目 遇到一个事故,我本想用 一个形容这个事故的adj  算了 既然 叫事故 已经能表达我们处于的一种状态,

是这样的: 有小部分用户反应 app无法注册 总提示密码错误的情况 实际 该步骤 已经通过了本地校验密码的步骤.此时的密码错误反馈 是服务端返回的? 

于是我们判断 密码解码 出了问题.   

对于密码加密规则 真的是每个公司都有一套 很灵活. 我们由于是翻新版本 也出了新的一套密码加密规则,   

如下:                                            

登录加密方式

md5(md5(password))

这个登录加密比较好理解,针对原始密码 二次md5,  此时服务端在注册时候已经知道你的密码 也进行二次md5 再和你上传的password加密结果进行比较 即可

注册加密方式:

几个参数:

appKey :服务端提供的key，放在app本地。用于参与下面的加密

time  : 获得当前时间戳并保留变量，用于上传给服务端 (秒级别)

date:  将时间戳转为 “分:秒:时 日-月-年” 格式

password1: 截取用户输入密码的前m位，再进行字符串反转操作

password2: 用户输入密码的剩余字符，再进行字符串反转操作

code : md5(AppKey+date);

最终公式如下

 passwrod=反转字符串(base64_encode (code+password1+code+password2+code))

NOTE: time 时间戳需要一起上传给服务端

其实 这里的关键问题 就是对 time 和 date的理解,

服务端希望加密结果是动态的,所以引入时间戳加密

然后通过上传的time  服务端再把结果反解密 得到原始密码

其实 说到这里 我们大家就都知道 为什么 用户反馈说无法注册了———服务端没有解密出原始密码!!!!

关键就是这个时间戳 出现了严重的问题.

设计该套加密过程,我们 前端和后端没有约定 这个时间戳到底以什么时区为标准!!!  客户端默认 是用户当地时区处理的

服务端解密 时候 把时间戳 按北京时区处理了,

恰巧 我们的确存在部分海外用户, 注册或者 重新找回密码 直接就失败了.

其实解决很简单

方法我们选择两种

(1)前端后端统一时区

(2)前端不动 后端要对 第一次解密过程判断 如果没有得到密码结果 要遍历其他时区继续解密 至解密成功

当前,为了App Store 用户即可用 我们采用了方法(2)

在接下来的迭代,遵循设计规则(1)

因为这个问题是在临近结束当前开发任务发现的么,我这边的个人想法是: 

a 这个问题客户端马上可以配合修改,执行(1). 这样服务端就少维护一个错误版本 

b 其次考虑到,毕竟后端遍历处理 并发量是一个问题啊, 如此处理 很是鸡肋.

c 客户端处理并且仅仅处理注册这块的和加密相关的一个时间戳时区问题,对于其他功能代码 无逻辑业务功能关联,测试也就测这块, 属于可把控范围内

 

但是其他人的意见是: 

 

a 小范围 影响,仅仅是小部分海外用户  

b  临上线 改东西 影响大  不可预测

c 服务端 在用正常方法解不开时候才for循环

 

最终 我从众 (目前公司没有CTO 来做决策 所以 几个人讨论...)

 

这也是我成长路上遇到一个比较考验人的问题吧, 真的很考验人,一个错误不成熟的交互设计, 修改后 到底如何执行, 真的很考验领导者的应变能力和领导力.

 

解决方案很灵活, 具体事件具体探讨分析,不断成长锻炼,如果有一天 我作为管理者,我必须要有足够理由告诉,说服大家,这么做,是权益最大的一个方案. 

 

还是在成长中啊