这是一个创建于 3738 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在是 ios客户端 跟我说 登录的时候 密码 是 md5 加密之后，在传给我的，说这样安全，即使被截包了，也不知道原始密码，我是觉得说，明文给我就好了，因为网站也是需要登录的，肯定也是明文给我的。
现在的疑问就是，app的登录，在用户输入密码之后，app本身需要对密码做什么处理么？如果做处理，那么web登录，也需要做相应的处理么？
顿感，经验不够呀。
现在的疑问就是，app的登录，在用户输入密码之后，app本身需要对密码做什么处理么？如果做处理，那么web登录，也需要做相应的处理么？
顿感，经验不够呀。
 |
1
alex321 2014-09-03 12:04:20 +08:00
token 和 salt 混合之后 base64 接入专门负责 client 登录的 api 吧。。。
|
 |
3
shajiquan 2014-09-03 12:30:13 +08:00
APP 把 raw_password 加密后提交。
数据库里只存加密后的密码。 |
 |
4
xylophone21 2014-09-03 12:39:48 +08:00
web端有https
|
 |
5
sobigfish 2014-09-03 12:46:22 +08:00
所以说http的表单是不安全的，但国内有几个https的。。。。
|
 |
6
kisshere 2014-09-03 13:34:37 +08:00
别md5，彩虹表就可以破了，加点盐更好
|
 |
7
pimin 2014-09-03 13:48:38 +08:00 via iPhone
md5和明文没太大区别，聊以自慰而已。
回到楼主的问题，客户端md5($passwd),web也一样处理就好了。 |
 |
8
PP 2014-09-03 14:02:08 +08:00
加盐也够呛啊！
|
 |
9
hging 2014-09-03 14:36:49 +08:00
想要安全.先密码MD5,然后再找个算法跟时间戳之后再怎么怎么的. 手机跟服务器同时用这个算法. 或者找不对称加密什么的. 恩.
|
 |
10
chrischan168 2014-09-03 14:45:17 +08:00
@alex321小阿斯顿
|
 |
11
heaton_nobu 2014-09-03 14:50:17 +08:00
|
|
12
alex321 2014-09-03 15:15:30 +08:00
@dryyun 我现在的考虑的状况是各种接入来源和 n 多的第三方联合登录。
所以，在用户登录块会有一个全局的中间应用来负责，这个应用同时维护着不同接入来源的 token 和去除 salt 的规则，页面的登录也可以理解为其中一个接入应用。 处理下来，在用户的登录资料中，面向数据库的都是统一的 uuid/username/email/phone 和 hash 之后的密码；而面向不同的应用则是各自 token、salt 和密码组合的 base64 编码。 这个话题主要讨论的是密码传输形式的安全，和是否启用 ssl 的途径关系不大；是否启用 ssl 是传输的渠道，和传输形式可以叠加。 @chrischan168 啊，啥？新款蒙迪欧？ |
 |
13
wangyongbo 2014-09-03 18:24:44 +08:00
我有一个问题，如果客户端传过来的是MD5过的密码，那服务器存储的是什么？原样保存客户端传过来的经过MD5过的密码？
|
 |
14
dorentus 2014-09-03 20:34:54 +08:00 via iPhone
https 明文
另外不管客户端怎么传，服务器端加盐哈希还是不能少。 app 传 md5 后的密码的话，网页里用 js 一样做就好了。好处是服务器端永远不会知道用户的密码。 不过这 md5 后的密码被人截获的话，一样可以被用来直接发请求到服务器登录，对安全性其实没啥加强。 |
 |
15
dryyun OP @shajiquan 数据库存加密后的密码，这个我知道。 那app 对密码加密之后给我，我还需要什么处理么？就跟数据库中的比较一下。
|
|
17
alex321 2014-09-03 22:47:33 +08:00
@dryyun token 是服务端生成的，作为应用和服务端沟通的凭证，否则不响应。
salt 是应用自行生成，可以随时在应用和服务端进行调整变换；但是其混淆的规则和对应的解混淆规则需要在服务端配置并保持互逆，也可以直接每次都由服务端随机提供混淆和解混淆的规则。 比如，salt 是 abcdef，明文密码是 12345，混淆规则是 slat 随机两个一组进行分解，并针对明文密码的 0、1、2 位插入，那么得到的密码可能是 ab1cd2ef345/ac1be2fd345/…，再进行 base64 编码后与登录用户名一起发送给服务端验证。 服务端接到密码后进行 base64 解码，然后按照 0、1、2 位去除两个字符的形式还原，然后以系统的 salt(如果存在或者必要)进行 hash，得到最终的密码，并和数据库中保存的密码比对，成功则返回登陆成功信息，失败则返回登陆失败信息。 |
|
18
shajiquan 2014-09-04 13:25:18 +08:00
@dryyun 请参考这样的步骤：
[注册时] client 发 username、password（加密后的）给 server，sever 直接保存。 [登录时] client 仍然发 username、password（加密后的）给 server，server 比对，如成功，返回 session 信息，如失败，返回错误提示。 [数据库] 应该有一个专门的 session 表，用于存放『成功登录』的用户的 session 信息，包括 session_id，user_id 及其他信息，如果用户登录成功，server 返回给 client 的 session 信息就得包括这些。 [客户端] client 需要将这些 session 信息保存到它的本地，以便请求需要授权的接口。 [需要授权] 在访问需要授权（登录）的接口时，把 session 信息的 session_id, user_id 等传给 server，server 判断这个 session 是否有效，有效则继续，无效则抛出错误。 [退出登录] client 携带 user_id session_id 等一类信息请求退出登录接口，sever 把 session 表中的相关记录删除。 |
Select Language