iOS RSA的网络安全模型,iOS签名机制总结(登录,token安全,签名)

原文地址:http://www.jianshu.com/p/2927ca2b3719

摘要

本文将针对RSA登录和http请求作讲解，希望对大家有所帮助

一,登录,登录保持(http请求)

登录机制

登录机制大概分为以下三个阶段:
1.登录验证: 是指客户端提供用户名和密码, 向服务器提出登录请求,服务器判断客户端是否可以登录并向客户端确认.

2.登录保持:是指客户端登录后, 服务器能够分辨出已登录的客户端,并为其持续提供登录权限的服务器.

3,登出:是指客户端主动退出登录状态

第一种网络请求情况(安全级别 | )

一般的情况是这个样子的：一但用户登陆成功（单方面MD5加密：服务器加密则客户端不加密，客户端加密则明文传输），服务器为客户端分配sessionID(也可以称为userID),当然有些服务器不但为客户端分配了userID还有可能会为用户提供token了(这个下面会做解释)，然后每次网络请求都将sessionID当做参数传递给服务器

优点

能够保持用户登录装态, 区分用户, 相对于不返回任何信息的登录安全了一些

缺点

如果通过网络嗅探器(例如:青花瓷)可以获取到http链接, 这样服务器返回的sessionID便会被获取到,这样依然会造成信息泄露,并且还能被伪造请求(浏览器请求).

第二种网络请求情况(安全级别: |||)

第一种存在明显的安全隐患, 但是目前市面上的好多app依然采用第一种方法实现登录,网络请求, 但是对于安全级别较高的app,已经不再适用了,所以在此基础上机型优化----采用非对称加密(公钥,私钥).

登录模型

客户端第一次发出登录请求时,用户密码以明文的方式进行传输, 一旦被截获,后果严重, 因此密码需要加密, 例如采用RSA非对称加密.具体流程如下:

1.客户端想服务端第一次发出登录请求(不传输用户名和密码)

2.服务器利用RSA算法产生一对公钥和私钥,并保留私钥,将公钥发给客户端.

3.客户端收到公钥后,加密用户密码, 向服务器发出第二次登录请求(传输用户名和加密后的密码)

4.服务器利用保留的私钥对密文进行解密,得到真正的密码.

第三种网络请求情况(安全级别: ||||)

再仔细核对上述登录流程, 我们发现服务器判断用户是否登录, 完全依赖于sessionID, 一旦其被截获,黑客就能够模拟出用户的请求,于是我们需要引入token的概念,用户登录成功之后,服务器不但为其分配了sessionID,还分配了token数据,也需要加密.于是一次登录的细节在此拓展

1.客户端向服务器端发送第一次登录请求(不传输用户名和密码),服务器利用RSA算法产生一对公钥和私钥,并且保留私钥,将公钥发送给客户端.

2.客户端收到公钥后,加密用户密码,向服务器发送用户名和加密后的用户密码;同时另外产生一对公钥和私钥,自己保留私钥,向服务器发送公钥;于是第二次登录请求传输了用户名和机密后的密码以及客户端生成的公钥.

3,服务器利用保留的私钥对密文进行解密,得到真正的密码.经过判断,确定用户可以登录后,生成sessionID和token,同时利用客户端发送的公钥,对token进行加密.最后将sessionID和Jamie后的token返回给客户端.

4.客户端利用自己的生成的私钥对token密文解密, 得到真正的token.

登录保持(也是http数据请求阶段)

引入token后, http请求被获取问题便可得到解决.服务器将token和其它的一些变量,利用散列加密算法得到签名后, 连同sessionID一并发送给服务器;服务器去除保存在服务器的token,利用相同的法则生成教研签名, 如果客户端签名与服务器的校验签名一致,就认为请求来自登录的客户端.

注:token失效的两种情况

1.用户登录出系统

2.token在后台的规定时间内失效

失效原理:

在服务器端的redis中删除相应key为session的键值对