关于登陆的加密思考

几乎每一个App都离不开登录注册这个功能模块,那么作为前端开发,在实现登录注册的时候我们应该进行什么样的处理,才能提高登录注册信息在数据传输过程中的安全性?这里我总结了以下几个方面:

  • “裸体”明文信息,直接将登录注册信息传送给服务器;
  • MD5加密处理后,传输给服务器;
  • MD5和“固定盐”加密处理后,传输给服务器;
  • HMAC加密处理后,传输给服务器;
  • 增添登录请求的时效性。

“裸体”明文

这个没什么好说的,如果你不是写Demo的话,使用明文传输用户信息,想想你的支付宝、银行卡里面的钱不翼而飞,整天被各种销售、房地产给你打电话吧。

MD5加密处理

通常在我们做开发前期,说到登录注册加密,可能最初都是使用MD5进行加密的,并且以为天衣无缝,因为我们都知道MD5是不可逆的。但是:在计算机的世界里,哪有绝对的安全,无时无刻不是在进行加护破解的博弈。MD5也是一样的,针对MD5可以进行暴力破解,至于如何暴力破解,这里附一个网址,它会告诉你一切
CMD5 : http://www.cmd5.com

MD5和“固定”盐加密处理

盐(Salt)
在密码学中,是指通过在密码任意固定位置插入特定的字符串,让散列后的结果和使用原始密码的散列结果不相符,这种过程称之为“加盐”。
                         -----维基百科


static NSString * salt = @"ladsuf89asufiajfdi2oj3rw;oef()fkdk%^%839u48923ksjfklsdjflkf";
- (IBAction)login:(id)sender {
    NSString * user = self.UserText.text;
    pwd = [pwd stringByAppendingString:salt].md5String;
    // do something
}

以上代码块,就是对明文密码进行加盐MD5化,盐Salt是前端和后台服务器提前商定的结果。这样的话,暴力破解的方式就几乎可以避免(如果这样还被暴力破解,只能说运气太差)。
这种方式在一定程度上降低了在传输过程中被中间人攻击后破解得到原文的可能性。
当然上面代码块的加密是最简单的,在此基础上,我们还可以延伸。比如将传输的参数和盐Salt进行字典序排序后进行MD5加密,获取的字符串作为Signature签名,然后再将Signature、参数和盐进行MD5加密,获得最终的加密结果,进行传输。传输到后台后,后台会对传输信息进行匹配。
但是:固定盐加密的方式,有一个严重的弊端。就是固定,不可修改。如果我们的盐Salt无意间泄漏,那么这就是一个大麻烦,因为我们之前的用户密码都是根据这个固定盐生成,如果盐Salt泄漏,当我们想要替换之前的Salt时,会造成之前所有注册过的用户密码失效,这种后果的严重性,不用我说大家也都明白。而这种盐泄漏的风险还是很高的,比如人为泄漏,比如反编译泄漏(App被反编译后,可以看到很多信息,而盐,说不定就是其中一个。)

HMAC加密

- (IBAction)login:(id)sender {
    NSString * user = self.UserText.text;
    NSString * pwd = self.PwdText.text;
    // 拿到注册时从服务器获取的密钥Key
    NSString * key = [KeyChain getSaltWithAccount:user];
    if (key == nil) {
        //1.发送网络请求!获取密钥!!
        key = [self getKeyWithAccunt:user];
        //2.将密钥存储到KeyChain中
        [KeyChain setSaltWithAccount:user];
    }
    //Hamc+key后的密码,进行网络传输
    pwd = [pwd hmacMD5StringWithKey:key];

以上代码块就是简略的HMac和“动态盐”的加密方式。

它的优势在于:Key是由用户注册账号时由服务器分配的,正常情况下,每个账号都拥有一个唯一的Key。这样的方式,在具备了“MD5和固定盐加密”的优点,同时也避免了“固定盐”泄漏所带来的风险。这个方式的大致流程如下图:
屏幕快照 2018-01-05 上午10.23.10.png

特别说明一下登录中步骤5:
当我们注册账户后,会将密钥Key存储在KeyChain中方便以后登录取出使用,但是:当我们更换设备时,就取不到登录所需的密钥Key,针对这种情况,我们需要重新向服务器获取账户对应的密钥Key,这个获取的过程我们可以做成设备锁,类似QQ那种效果的设备锁。当用户重新获取密钥Key时,需要注册时填写的手机号进行短信验证或者回答注册时填写的一些信息。同样,当获取到密钥Key时,需要存储在设备的KeyChain中。

时效性

至此,我想我们的登录请求的安全系数已经提高了很多,但是还存在一定的风险,比如当中间人直接拦截获取登录授权信息,模拟成用户操作。针对这种情况,我们可以对登录请求增添时效性,过期不候。
具体就是在我们的HMAC加密过程中,加密参数增添一个时间戳,这个时间戳应该是从服务器获取的,客户端的时间由于多方面原因吧,可能会造成和服务器时间不一致。当客户端将具有时效特性的信息传输给服务器后,服务器会根据规定的加密规则,进行相同的算法,来和客户端传递的数据相比对。这样即使中间人截获了登录传输的信息,如果是一个过期的数据信息,传输给服务器也是无效的。当然这个有效时间也是客户端和服务器的协定的。

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