安全的网络编程 - 验证用户的最佳实践

Question

进入网络开发领域，并希望成为制作安全网站的良好选择。任何一般的键入/下面的任何答案将不胜感激。

因此得到了对事物的认证方面的一些问题：

1. 应该如何键入的客户端上的密码进行编码并发送到服务器 - 假设HTTPS已在使用？我听说过一些建议，例如只有散列才会被发送用于安全。它应该加密客户端 - 如何？
2. 1. 类似，但在服务器端。如何保存密码。实际，哈希等？他们应该加密 - 如何？
      另外，有没有一种体系结构可以保护密码的方式，即如果一个密码受到损害，而不是其他人的密码？例如，如果所有密码都存储在一个文件中，则仅访问这一个文件会危及系统中的每个用户。
   2. 如果只有散列必须存储 - 如何处理冲突？
3. 一旦通过身份验证，您应该只依靠会话ID来维护身份验证状态？我已阅读了有关减少会话劫持的技巧，因此想知道是否保持用户身份验证是否是一个好主意/唯一想法。
4. 是否有安全的方式提供autoLogIn功能，以便浏览器记住密码 - 类似于社交网络/网络电子邮件客户端？
------------- 特 - 防止攻击
5. 1. 是否有任何工具，甚至只是一些常见的做法，在那里，必须应用到用户名/密码提供的条目用于防止注入或任何其他类型的攻击？
   2. 如果我使用Java开发环境（使用PlayFrameWork btw），攻击者通常可能在任何形式的条目中包含任何类型的有害代码片段的可能性有多大？

PS 正如我可能会被使用Java PlayFrameWork该网站提到的编码 - 你能提出什么我应该考虑到这个？
任何有关设计模式的提示都必须遵循以达到安全目的。

非常感谢 PPS 您可以建议将工作交给专家，但如果可能的话，我想自己有一些编码经验。我希望这是一个可行的选择？ 可能想建立一个电子商务系统供参考。

Answer 1

在客户端键入的密码应该如何编码并发送到服务器 - 假设https已在使用中？我听说过一些建议，例如只有散列才会被发送用于安全。它应该加密客户端 - 如何？

它不应该以可以恢复的方式发送到服务器。 SSL/TLS和PKI的问题是{username，password}（或{username，hash（password）}）几乎呈现给任何使用证书回答的服务器。该服务器可能是好的或坏的。

这里的问题是频道设置与用户身份验证是分离的，网络开发人员和服务器管理员然后做了一些愚蠢的事情，比如在basic_auth方案中在线路上输入纯文本密码。

它更好地将SSL/TLS通道设置与身份验证集成在一起。这就是所谓的通道绑定。它提供相互身份验证，并且不会做任何愚蠢的事情，比如在电话上放置一个{用户名，密码}，以便轻松恢复。

SSL/TLS提供近80个密码套件，它们不会在电汇上执行dumb {用户名，密码}。它们是预先共享密钥（PSK）和安全远程密码（SRP）。即使一个坏人回答（即控制服务器），攻击者也无法学习密码，因为它没有放置电线进行恢复。相反，他将不得不中断AES（用于PSK）或解决Discrete Log问题（用于SRP）。

所有这些都在Peter Gutmann的Engineering Security书中详细介绍。

类似但在服务器端。如何保存密码。实际，哈希等？他们应该加密 - 如何？

查看Secure Password Storage Cheat Sheet和Secure Password Storage paper John Steven为OWASP写的。它会引导您完成整个威胁模型，并解释为什么事情以特定方式完成。

一旦通过身份验证，您应该只依靠会话ID来维护身份验证状态？

是的，但授权与认证不同。

认证是一种“粗粒度”权利。它提出了一个问题，“用户可以使用这个应用程序吗？”。授权是一种“细粒度”权利。它回答了这个问题，“用户可以访问这个资源吗？”。

有没有提供自动登录功能，以安全的方式让浏览器记住密码 - 类似的社交网络/ Web的电子邮件客户端

这取决于你认为安全的，哪些是在威胁模型。如果您的威胁模型不包括对用户的计算机或设备具有物理访问权限的攻击者，则大多数标准可能都是“安全”的。

如果攻击者可以访问计算机或设备，并且用户没有用密码或别针保护它，那么它可能不被认为是“安全”的。

是否有任何工具或甚至只是一些常见的做法必须应用于提供的用户名/密码条目，以防止注入或任何其他类型的攻击？

是的，用户登录遭受注射。因此，您可以在执行过程中执行一些过滤，但您必须在输出上执行HTML编码。

它不只是用户名/密码和登录。几乎所有的东西都应该有一些输入过滤;并且它在恶意情况下必须具有输出编码。

你一定该在OWASP web site上花这么多时间。如果你有本地章节，你甚至可以考虑参加会议。你会学到很多东西，并且会遇到很多很棒的人。

如果我使用Java开发环境（使用PlayFrameWork btw），攻击者通常可能在任何形式的条目中包含任何类型的有害代码片段的可能性有多大？

Java是黑客的喜悦。自Oracle从Sun购买后，质量和安全性已经下降。更偏执的人（安全意识？）人们建议而不是签署任何Java代码，因为沙箱太破碎了。这可以使合法应用程序正确保存沙箱。从http://threatpost.com/javas-losing-security-legacy：

... “沙箱是Oracle一个巨大的问题，”容格里斯告诉Threatpost。 “每个人都在闯入。他们的解决方案是代码签名，然后离开沙盒 。但是，那么你对该机器有完全的许可。它 没有任何意义。“

它太糟糕了坏人没有得到备忘录。他们将代码签名为恶意软件并从沙盒中跳出来。

为安全起见，必须遵循设计模式的任何提示将会有所帮助。

你也有web服务器的配置，像HTTPS Only和Secure饼干，HTTP严格传输安全（HSTS），以及内容安全策略（CSP），了Suhosin（硬化PHP），SSL/TLS算法，等等。

它有很多，你需要找到合适的硬化指导。