谈谈移动互联网应用的用户注冊登录安全考虑之不可逆加密的应用原则
2017-07-30 12:51
543 查看
如今移动互联网应用一般都会採用用户注冊登录机制以便增强用户粘性。
那么为了安全设计。用户的password应该怎样传输?在云端又怎样保存?这个问题我思考过许久。总结下面一些思路。主要涉及到不可逆加密的使用原则。
如果用户的注冊/登录过程均是在全然安全的环境下进行,你能够地设计得非常easy: 注冊就是把设置的password直接保存起来,登录就是直接比較password。
这过程不涉及到不论什么加密技术。
然而在实际应用中。整个过程可能是在不安全的环境下进行,比如保存password的系统可能被黑客攻击,password的传输可能被黑客截获。。。
。这样的环境下,你怎样能保证你的登录过程不会被其它别实用心的人冒充?password怎样不泄露?
下面是注冊和登录过程中password及由它推导出来的信息(我称之为信任信息)的传递示意图:
注冊:
手机应用 云端server
password---->传输---->持久保存
登录:
手机应用 云端server
password---->传输---->与持久保存的信息比較
因为传递过程的不安全性,每多一次信息的传递步骤。就多一次信息泄露的可能性。为了保证信任信息的安全,应该保证信任信息的传递过程是不可逆的。比如哈希加密算法(比如md5,sha1,sha256, PBKDF2, bcrypt等)可达到这一目的。
这些算法可保证无法通过下游的信息推算出上游的信息(比如password)。另外这类算法还可保证同样的输入和參数经过计算可得到同样的输出,这样云端就能够比較两方的结果就可以判断出原始的信息(如password)是否同样的。以达到用户认证的效果。
那么就上述的场景而言。怎样在各环节(如传输/保存)对password进行加密处理?
简单地说,用户在注冊时输入了password。能够先做一次哈希加密。再进行网络传输,云端server收到后,再做一次哈希加密。然后保存起来。登录时的过程类似,云端server所得到或使用的信息是经过了多次(这里是2)哈希加密后的结果。
相比之下,眼下有非常多文章关注的不过password做哈希处理后保存到云端server这一过程。
其实,一个复杂的系统可能存在多个泄露风险的环节, 因此需一一识别出来,并添加必要的哈希加密步骤。
详细而言,比如上述的注冊或登录过程, 假设只做一级哈希加密。 虽然达到保护原始password的效果。但仍存在安全风险的:假设不过云端保存前做哈希加密,那么传输过程仍使用password明文。存在泄露风险。
反之假设不过传输前做哈希加密,一旦该哈希值泄露了。则easy被伪造登录: 。
总结一下:
在信任信息由高信任域向低信任域传递的过程中,不可逆哈希加密处理能够有效控制高信任级别的信息直接扩散到较低信任域。假设在一个系统中存在多级这样的场景。那就应该多次使用不可逆加密处理。
注:
1) 上述提到的一次不可逆加密处理不代表仅仅能是一次哈希加密算法迭代。其实为了加大算法强度,有时可能是使用非常多次哈希加密算法的迭代。
2)在不可逆加密处理中,往往还须要加入盐值。以抵抗彩虹表攻击,这里不做具体阐述。
那么为了安全设计。用户的password应该怎样传输?在云端又怎样保存?这个问题我思考过许久。总结下面一些思路。主要涉及到不可逆加密的使用原则。
如果用户的注冊/登录过程均是在全然安全的环境下进行,你能够地设计得非常easy: 注冊就是把设置的password直接保存起来,登录就是直接比較password。
这过程不涉及到不论什么加密技术。
然而在实际应用中。整个过程可能是在不安全的环境下进行,比如保存password的系统可能被黑客攻击,password的传输可能被黑客截获。。。
。这样的环境下,你怎样能保证你的登录过程不会被其它别实用心的人冒充?password怎样不泄露?
下面是注冊和登录过程中password及由它推导出来的信息(我称之为信任信息)的传递示意图:
注冊:
手机应用 云端server
password---->传输---->持久保存
登录:
手机应用 云端server
password---->传输---->与持久保存的信息比較
因为传递过程的不安全性,每多一次信息的传递步骤。就多一次信息泄露的可能性。为了保证信任信息的安全,应该保证信任信息的传递过程是不可逆的。比如哈希加密算法(比如md5,sha1,sha256, PBKDF2, bcrypt等)可达到这一目的。
这些算法可保证无法通过下游的信息推算出上游的信息(比如password)。另外这类算法还可保证同样的输入和參数经过计算可得到同样的输出,这样云端就能够比較两方的结果就可以判断出原始的信息(如password)是否同样的。以达到用户认证的效果。
那么就上述的场景而言。怎样在各环节(如传输/保存)对password进行加密处理?
简单地说,用户在注冊时输入了password。能够先做一次哈希加密。再进行网络传输,云端server收到后,再做一次哈希加密。然后保存起来。登录时的过程类似,云端server所得到或使用的信息是经过了多次(这里是2)哈希加密后的结果。
相比之下,眼下有非常多文章关注的不过password做哈希处理后保存到云端server这一过程。
其实,一个复杂的系统可能存在多个泄露风险的环节, 因此需一一识别出来,并添加必要的哈希加密步骤。
详细而言,比如上述的注冊或登录过程, 假设只做一级哈希加密。 虽然达到保护原始password的效果。但仍存在安全风险的:假设不过云端保存前做哈希加密,那么传输过程仍使用password明文。存在泄露风险。
反之假设不过传输前做哈希加密,一旦该哈希值泄露了。则easy被伪造登录: 。
总结一下:
在信任信息由高信任域向低信任域传递的过程中,不可逆哈希加密处理能够有效控制高信任级别的信息直接扩散到较低信任域。假设在一个系统中存在多级这样的场景。那就应该多次使用不可逆加密处理。
注:
1) 上述提到的一次不可逆加密处理不代表仅仅能是一次哈希加密算法迭代。其实为了加大算法强度,有时可能是使用非常多次哈希加密算法的迭代。
2)在不可逆加密处理中,往往还须要加入盐值。以抵抗彩虹表攻击,这里不做具体阐述。
相关文章推荐
- 谈谈移动互联网应用的用户注册登录安全考虑之不可逆加密的应用原则
- usb key,互联网网站Web登录,应用系统认证安全保障
- 中国移动139邮箱全面部署 WoSign 品牌 SSL证书,确保139邮箱用户登录安全
- 分享移动互联网:应用为王,安全至上
- 移动互联网经济超千亿元, 爱加密助App开发者解决安全问题!
- usb key,互联网网站Web登录,应用系统认证安全保障
- 中国移动139邮箱全面部署 WoSign 品牌 SSL证书,确保139邮箱用户登录安全
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(中)
- 2013年第一季度中国移动互联网应用安全检测与分析报告
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(上)
- 【移动安全】移动应用加密协议逆向分析成功
- 用户登录模块进行必要的安全处理(MD5加密、加盐和传输过程加密)
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(上)
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(中)
- 移动互联网应用的十项设计原则和小提示
- 和用户、登录、密码与安全标识号(SID)一起移动数据库(转)
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(上)
- 软件评测-信息安全-应用安全-资源控制-用户登录限制(中)
- 通过客户端的cookie标志来设置用户是否登录了安全吗?常用的加密算法加密后安全吗?
- 金融安全:谁忽略了移动应用加密?