我正在用php/MySql开发一个应用程序,并从安全的角度寻找最佳方法。应用程序将使用和存储敏感信息。我意识到所有方法都有风险,但我需要最好的方法来将这个应用程序的敏感信息的安全风险降到最低。
以下是应用程序的基础:
1)整个应用程序使用https和php 7运行。
2)用户在register.php注册帐户,注册过程中密码被散列为password_hash和Password_BCRYPT。
3)用户通过login.php登录到web应用程序。
4)登录后,用户访问管理凭据页面(Manag-Accounts.php),并在网站上为第三方网站输入url、用户名和密码(基本上就像密码管理器)。
5)下一次用户访问Manag-Customer.php页面,并输入包含ssn#的敏感客户信息。
6)最后,用户访问submit-customer.php页面。
以下是我的问题:
1)对于这样的系统,什么样的加密/安全方法被认为是最大限度地提高存储在步骤4和5中的敏感信息的安全性的最佳实践?
2)通过iframed表单将信息从步骤4和步骤5传送到第三方网站的最安全的方法是什么?
3)将步骤4和5中输入的敏感信息存储在服务器上还是客户端上更好?如果是在客户端,该如何处理呢?
发布于 2017-06-18 03:48:53
这个问题的全部范围是巨大的(安全应用程序设计的几个方面)。我不确定这里一个简单的问答就够了。
考虑到您所尝试的事情的严重性,您应该在您的团队中获得一个强大的AppSec专业人员,并考虑一种包括威胁建模、安全设计、安全编码原则、安全测试和验证的整体方法。
我将尝试简短地回答一些尖锐的问题--免责声明说,AppSec专家仍在讨论其中的一些问题,特别是其中一些答案正在“演变”(例如,安全凭证存储-一些围绕支持K12和Blake2而不是PBKDF2 2/ bcyrpt / scrypt)的讨论。
这不是一个问题,而是:
请确保你使用的是相当大的随机盐。请参阅此关于散列和盐分大小的旧讨论,以获得一些了解。 OWASP有关于此这里的体面的和最新的指南。请注意,2013年的讨论约为64位和128位。OWASP提到64字节(而不是比特) salt。也推荐一些关键的功能--不仅仅是简单的散列。
最后,您提到了“基本上像密码管理器”。这使事情变得有点复杂。你会想要让用户控制-至少有一个合理的保证,王国的部分钥匙被锁在他们的大脑或他们的系统。通常的方法是用户的主密钥(密码)不存储在任何地方(甚至不在本地系统上),而是用于派生用于密码存储的密钥(S)。
现在请回答你们的问题:
。
该系统将需要一个全面的威胁建模+隐私,以及从地面安全设计。这是好的,你开始相当好-但请不要低估手头的任务。OWASP对大部分部分都有指导,尽管人们知道有着深厚的专业知识的人会在某些领域提出异议(通常是因为“这并不完美”)。我认为这是一种迂腐的反对。
作为一个有安全意识的用户,我不相信iframes。我不推荐给用户。如果您所做的类似于密码管理器功能--我建议您探索其他方法。
请参阅前一段我提到的主密钥(密码)。
如果您遵循这个建议,那么您应该将每个用户的密码哈希存储在您的服务器上。在用户的系统上存储正确的散列/加密密码没有真正的(技术)优势,在那里,由于多种原因,密码很容易被删除。
https://security.stackexchange.com/questions/162182
复制相似问题