api设计 - php 接口 token 数据加密

最近在用php写app的接口,有一些疑问

首先关于token(令牌)
token是用户登录的时候生成的
用户token在服务端保存入库 客户端则缓存在本地 大部分接口都要求客户端发送token 和服务端数据库中的token进行验证

每个用户唯一token 是由 年月 和 客户端机器码标识 用户id 组成的
(年月是做登录保存期限用的 机器码是在持保证用户下次登录时,快捷识别登录来源,判断是否需要重新登录的重要凭证,用户id其实是顺便加的)

问题来了
=。= 这东西感觉做出来就和session没什么区别
**如果直接抓一下包
每个用户通一个平台的客户端的token都是一样的 对于防攻击并没有什么用**
而且这种token是基于用户的 所以用户的登录 注册验证(防机器人)验证上这种token是帮不了忙的
=。=我还在再设计一个啥 来验证 (有办法在这种token思路上 把登录注册验证也做了吗)

回复内容:

最近在用php写app的接口,有一些疑问

首先关于token(令牌)
token是用户登录的时候生成的
用户token在服务端保存入库 客户端则缓存在本地 大部分接口都要求客户端发送token 和服务端数据库中的token进行验证

每个用户唯一token 是由 年月 和 客户端机器码标识 用户id 组成的
(年月是做登录保存期限用的 机器码是在持保证用户下次登录时,快捷识别登录来源,判断是否需要重新登录的重要凭证,用户id其实是顺便加的)

问题来了
=。= 这东西感觉做出来就和session没什么区别
**如果直接抓一下包
每个用户通一个平台的客户端的token都是一样的 对于防攻击并没有什么用**
而且这种token是基于用户的 所以用户的登录 注册验证(防机器人)验证上这种token是帮不了忙的
=。=我还在再设计一个啥 来验证 (有办法在这种token思路上 把登录注册验证也做了吗)

 

此问题简单至极,以php举例。
但和session不一样,和cookies有点接近,设计这个是为了解决cookies传值麻烦的问题。


首先在登陆的过程中,用户向服务端提交数据应有
usernamepasswordclient_key
php在服务端拿到这些数据之后,用校验算法获取校验值,如md5
(ps:不加密码是不行的,否则用户修改密码后之前的还是可以快捷登陆,这不坑人吗)
$salt是一个加密key,防止别人猜到加密算法。

$token=md5($username.$password.date('yyyy').date('mm').$client_key.$salt);

计算完成后将$token返回到客户端,作为存储。以后客户端只需要向服务端发送此$token和用户名。

当php收到这个$token就再做一次上面的运算,看是否一致即可快捷判断。


如果需要防止恶意注册和登陆,就需要在客户端对client_key进行加密,然后服务端解密做验证,然而这并没有什么卵用,一切客户端的代码都是不安全的,可以通过反编译,反混淆来分析,然后照样伪造。所以客户端的加密没有意义。
另外,服务器通过ip判断也是一个办法。
然而,从根源上来讲,防止恶意攻击就需要验证手机号才能注册,目前基本上通过此种方法实现。

 

我也在写,还没有实现

 

1.如果用户是通过token验证登陆的,在app上也就是类似cookie的东西,用户拿来登陆是没什么问题,如果是当用户换客户端登陆,则需要重新登陆,那在验证的时候再获取客户端机器码匹配一下.

另外客户端的token也可以做复杂,用js进行加密处理,在php获取再进行解析.

 

虽然token在一定程度上是不安全的,但是相比较,比传递用户密码来的安全。
使用token的场景一般是无状态无cookies的模式,如果有token充当cookies中的sessionID的作用。
token虽然不安全,但是由一定程度的验证模式,那么还是可以使其可信的

 

刚好前不久自己写了篇博客,虽然没有涉及到一些技术细节,但思路还是有的,看看对你有没有帮助吧。

 

首先你要明确,Token是用于登录后验证身份的,所以一开始就否决了你期待用它来做防恶意注册,这两者完全不搭嘎。其次,要说TokenSession有什么区别,那区别就在于Token更具有定制型,因为它是由你实现的,就能干很多Session不方便干的事情,比如更好的做设备认证,更方便的控制有效期,更好的跨平台性……最重要的,HTTP协议本身定义就是无状态的,而Cookie这种东西的存在无疑有损无状态这个定义,所以几乎所有的接口都拒绝使用Cookie,弃了Cookie,那Token自然成了验证的首选。最后,Token的安全性着重于其不会被破解,不会被篡改,而不在于它传输时会不会被截取造成中间者攻击。截取的防护应该是由你加强传输过程中的安全性来实现的,比如增加参数签名,或者直接上HTTPS。

posted @ 2018-04-10 10:13  你背后的那个人  阅读(7827)  评论(0编辑  收藏  举报