iOS 注册密码加密 添加了时间戳 遇到的问题...
2017-03-06 15:10
190 查看
今天项目 遇到一个事故,我本想用 一个形容这个事故的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 来做决策 所以 几个人讨论...)
这也是我成长路上遇到一个比较考验人的问题吧, 真的很考验人,一个错误不成熟的交互设计, 修改后 到底如何执行, 真的很考验领导者的应变能力和领导力.
解决方案很灵活, 具体事件具体探讨分析,不断成长锻炼,如果有一天 我作为管理者,我必须要有足够理由告诉,说服大家,这么做,是权益最大的一个方案.
还是在成长中啊
是这样的: 有小部分用户反应 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 来做决策 所以 几个人讨论...)
这也是我成长路上遇到一个比较考验人的问题吧, 真的很考验人,一个错误不成熟的交互设计, 修改后 到底如何执行, 真的很考验领导者的应变能力和领导力.
解决方案很灵活, 具体事件具体探讨分析,不断成长锻炼,如果有一天 我作为管理者,我必须要有足够理由告诉,说服大家,这么做,是权益最大的一个方案.
还是在成长中啊
相关文章推荐
- Des 加密处理 iOS 和 安卓 与服务器 处理时 遇到的 补位问题
- Android----- MD5加密(登录注册得到与IOS相同的加密值,并且解决两个平台汉字加密不相同问题)
- IOS开发用户登录注册模块所遇到的问题
- iOS开发用户登录注册模块所遇到的问题
- 文件中用tobase() && frombase64() 对密码进行加密和解密遇到的问题
- 为安卓应用添加手势密码功能,遇到的一些问题以及解决方法
- Android----- MD5加密(登录注册得到与IOS相同的加密值,并且解决两个平台汉字加密不相同问题)
- Django-注册用户时候保存密码加密问题
- django学习——用户注册时的密码加密及登陆时的密码验证问题
- cocos2d-c++ 添加iOS广告sdk遇到的问题(inmobile)
- ios学习之——ios6之后UITableViewCell添加子视图所遇到的问题
- iOS 使用sqlcipher和openssl加密数据库时遇到的问题
- Android----- MD5加密(登录注册得到与IOS相同的加密值,并且解决两个平台汉字加密不相同问题)
- iOS添加手势遇到的问题
- 加密解密时遇到的"不正确的数据"以及"要解密的数据长度无效"问题解决方案
- 一步一步SharePoint 2007之十八:解决允许使用简单密码注册用户的问题
- 加密和解密会员注册密码
- 一步一步SharePoint 2007之十八:解决允许使用简单密码注册用户的问题
- cisco密码 密文加密设置问题!
- 我在用dotnet做一个项目的过程中,遇到了一个ListBox的问题:通过在一个ListBox中双击,把选中的项添加到另一个ListBox中