app的登录认证与安全

转载

一、登录机制

粗略地分析, 登录机制主要分为登录验证、登录保持、登出三个部分。登录验证是指客户端提供用户名和密码,向服务器提出登录请求,服务器判断客户端是否可以登录并向客户端确认。 登录认保持是指客户端登录后, 服务器能够分辨出已登录的客户端,并为其持续提供登录权限的服务器。登出是指客户端主动退出登录状态。容易想到的方案是,客户端登录成功后, 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

1.1 登录验证

上述简易的登录验证策略存在明显的安全漏洞,需要优化。

1.1.1 密码的传输

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

  • 客户端向服务器第一次发起登录请求(不传输用户名和密码)。
  • 服务器利用RSA算法产生一对公钥和私钥。并保留私钥, 将公钥发送给客户端。
  • 客户端收到公钥后, 加密用户密码, 向服务器发起第二次登录请求(传输用户名和加密后的密码)。
  • 服务器利用保留的私钥对密文进行解密,得到真正的密码。

1.1.2 登录状态token

再仔细核对上述登录流程, 我们发现服务器判断用户是否登录, 完全依赖于sessionId, 一旦其被截获, 黑客就能够模拟出用户的请求。于是我们需要引入token的概念: 用户登录成功后, 服务器不但为其分配了sessionId, 还分配了token, token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据,也需要加密。于是一次登录的细节再次扩展。

  • 客户端向服务器第一次发起登录请求(不传输用户名和密码)。
  • 服务器利用RSA算法产生一对公钥和私钥。并保留私钥, 将公钥发送给客户端。
  • 客户端收到公钥后, 加密用户密码,向服务器发送用户名和加密后的用户密码; 同时另外产生一对公钥和私钥,自己保留私钥, 向服务器发送公钥; 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。
  • 服务器利用保留的私钥对密文进行解密,得到真正的密码。 经过判断, 确定用户可以登录后,生成sessionId和token, 同时利用客户端发送的公钥,对token进行加密。最后将sessionId和加密后的token返还给客户端。
  • 客户端利用自己生成的私钥对token密文解密, 得到真正的token。

1.2 登录保持

在最原始的方案中, 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id,就认为请求来自相应的登录客户端。 但是只要sessionId被截获, 请求就可以为伪造, 存在安全隐患。

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

1.3 TOKEN失效
用户登录出系统

失效原理:
在服务器端的redis中删除相应key为session的键值对。





App登陆保存数据流程

App因为要实现自动登陆功能,所以必然要保存一些凭据,所以比较复杂。

App登陆要实现的功能:

  • 密码不会明文存储,并且不能反编绎解密;
  • 在服务器端可以控制App端的登陆有效性,防止攻击者拿到数据之后,可以长久地登陆;
  • 用户如果密码没有泄露,不用修改密码就可以保证安全性;
  • 可以区分不同类型的客户端安全性;比如Android用户受到攻击,只会让Android用户的登陆失效,IOS用户不受影响。

App第一次登陆流程:

  • 用户输入密码,App把这些信息用RSA公钥加密:(用户名,密码,时间,mac,随机数),并发送到服务器。
  • 服务器用RSA私钥解密,判断时间(可以动态调整1天到7天),如果不在时间范围之内,则登陆失败。如果在时间范围之内,再调用coreservice判断用户名和密码。

这里判断时间,主要是防止攻击者截取到加密串后,可以长久地利用这个加密串来登陆。

  • 如果服务器判断用户成功登陆,则用AES加密:(随机salt,用户名,客户端类型,时间),以(用户名+Android/IOS/WP)为key,存到缓存里。再把加密结果返回给客户端。
  • 客户端保存服务器返回的加密串

App自动登陆的流程:

  • App发送保存的加密串到服务器,(加密串,用户名,mac,随机数)==>RSA公钥加密
  • 服务器用RSA私钥解密,再用AES解密加密串,判断用户名是否一致。如果一致,再以(用户名+Android/IOS/WP)为key到缓存里查询。如果判断缓存中的salt值和客户端发送过来的一致,则用户登陆成功。否则登陆失败。

不用AES加密,用RSA公钥加密也是可以的。AES速度比RSA要快,RSA只能存储有限的数据。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,686评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,668评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,160评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,736评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,847评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,043评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,129评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,872评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,318评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,645评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,777评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,470评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,126评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,861评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,095评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,589评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,687评论 2 351