首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >在web应用程序和密码恢复中加密部分用户数据

在web应用程序和密码恢复中加密部分用户数据
EN

Security用户
提问于 2015-08-11 13:35:09
回答 1查看 2.6K关注 0票数 7

我正在开发一个存储敏感用户数据的web应用程序。尽管数据是敏感的,但我们希望将其永久存储,因为用户可能希望稍后返回并重用它。用户数据必须在用户会话期间由服务器访问。

我们可以假设,与永久存储的数据集相比,活动会话的数量较少。

  • 资产:存储在数据库中的部分数据非常敏感,但需要在用户会话期间在服务器端进行处理(这是应用程序的重点),并永久存储在那里(出于可用性原因)。
  • 场景:黑客可以访问数据库并能够读取所有的数据。

注意:这并不意味着替代风险分析,也不是安全管理的任何其他部分,也不意味着替代某些其他措施(密码策略、SSL/TLS、审核、…)。(你说吧)。这是为了检查一项具体的安全措施。

提出的对策:用户数据加密

为了减少将所有敏感数据泄漏给访问数据库的攻击者的风险,我想对数据进行加密(非常类似于选项1 在这个问题上):

  1. 在用户注册期间,服务器生成用户密钥U (AES)。
  2. 用户密钥使用密码派生密钥(SHA256) d(p)加密,并存储在数据库AES(d(p), U)中。
  3. 每次用户登录时,密钥都被解密并存储在服务器端会话存储p -> d(p) + AES(d(p), U) -> U中。
  4. 然后,只要会话持续存在,用户就能够处理他/她的数据。数据使用随机AES-密钥(消息密钥m)加密。然后使用用户密钥对AES-密钥进行加密,并将其存储在加密数据(AES(U, m) + AES(m, data))旁边。

问题1:该方案中是否存在明显的安全漏洞(除了攻击者可以访问所有登录用户的数据)?

Password-recovery

上述方案的一个明显缺陷是,没有进程执行密码恢复:一旦密码丢失,用户密钥就无法解密,因此数据也会丢失。

为了解决这个问题,我们生成了另一个RSA-密钥对(M_pub + M_sec)。公钥是应用程序配置的一部分。除以前的计划外:

  1. ( a)用户密钥和用户电子邮件用主密钥加密,并以用户记录作为恢复信息( RSA(M_pub, U+user.email) )存储。

我们在另一个服务器上有另一个应用程序,它可以访问私有主密钥(但不能访问数据库)。然后密码恢复将如下所示:

  1. 用户将像往常一样启动密码恢复功能(使用指向表单的链接重置密码->电子邮件)。
  2. 用户选择一个新的密码p'
  3. 最初的应用程序现在要求密码重置应用程序通过向恢复服务器发送恢复信息RSA(M_pub, U+user.email)和新的密码派生密钥d(p')来解密用户密钥。
  4. 密码重置应用程序解密恢复信息M_sec + RSA(M_pub, U+user.email) -> U + user.email,向user.email发送通知电子邮件(告诉用户如果他/她没有导致恢复)并将新加密的用户密钥AES(d(p'), U)发送回原来的应用程序。

恢复过程将受到速率限制,以便在发现漏洞之前限制被破坏密钥的数量。

优点:

  • 密码恢复仍然是即时的。
  • 攻击者需要黑两个系统才能访问整个数据库。

缺点:

  • 能够访问一个系统的攻击者也有可能访问密码重置系统。

问题2:这种恢复密码的方法能降低加密的效果吗?(还值得做吗?)

问题3:是否有任何其他进程可以提高数据安全性(在被黑客攻击的服务器上),而不会使自动恢复密码成为可能?

EN

回答 1

Security用户

发布于 2015-09-01 10:31:29

很抱歉在每个人的游行上下雨,但这真是个坏主意。(漂亮的线,顺便!但对错误问题的答案是正确的。

您已经创建了一个复杂的DIY冷冻方案,这是一个坏主意,因为您的实现将带来比今天更多的漏洞。

后退一步,做一个威胁分析。

  1. 从资产开始--数据是多么敏感。
  2. 考虑一下漏洞--攻击向量是什么?
  3. 然后想想威胁,然后,只有那时
  4. 关于安全对策的思考

在进行威胁分析之前,千万不要从设计和实现安全对策开始。

现在我已经讲完了-让我们想想一些典型的威胁场景。

威胁场景1:攻击者在猜到SSH密码后获得根访问权,并通过猜测具有sudo权限的用户的密码来提升权限。您的计划将不会有效的提升特权攻击。

威胁场景2: SQL注入-攻击者成功地获得了对您的SQL服务器的管理访问-正确的对策将是使用存储过程和清理您的输入,以确保您减轻SQL注入漏洞。

威胁场景3:用户滥用SOP (分离特权),即用户可能试图查看/URL攻击其他用户的数据。这是敏感医学数据中典型的威胁场景。在这种情况下(我不知道您使用的是哪种Web应用程序框架),适当的安全对策是基于RBAC角色的身份验证,而不是以用户为中心的加密。通常,在MVC框架中,如RoR和CakePHP或Dot都是在框架中烘焙的,所以您不必发明轮子。

威胁场景#4 -有人偷了你的服务器。

你说你在开发一个Web应用程序。我猜你是在使用云服务器。希望能在像Amazon、Rackspace或Azure这样的好云提供商上。

如果有人物理地窃取磁盘或服务器,那么加密服务器上的数据才是一种有效的安全对策。

有人在Amazon,RS或Azure上偷你的VM的可能性是.correct...zero。

有时,rest加密时对数据的遵从性要求几乎总是与可移动/移动设备有关,但如果必须的话,在现代SQL服务器中有TDE (透明数据加密功能),例如MS和PG。

哈哈!

票数 1
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/96558

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档