Security 如果您不进行金融交易，是否值得使用https？

嘿，对任何专家来说，这只是一个简单的问题。我有一个网站，用户可以通过信息进行交互，注册时只需输入用户名和密码，验证您的年龄，还可以选择添加电子邮件。我想没有什么敏感信息。值得使用https吗。它是否会阻止会话hi劫持并影响性能？

如果您传输密码、电子邮件地址或任何其他私人或个人身份信息，至少是值得的。如果存在任何非HTTPS通信，会话劫持是可能的，但这是许多网站愿意接受的风险，这取决于您的情况

---

性能问题取决于您的硬件和堆栈，但HTTPS和HTTP会对性能造成“一些”影响。这还不足以阻止您保护密码和敏感用户信息。

我以前也考虑过这一点。我认为，当用户登录或更改信息时，您可能需要一个安全的连接。

我认为，一旦您进行了某种登录处理，您就应该保护用户的密码。您可以通过https或使用http摘要身份验证来实现这一点

---

我对加密的主要观点是，相当多的用户将拥有与他们的银行账户或类似账户相同的密码。尽管您站点上的信息不敏感，但密码确实可以保护一些重要信息。

无论何时使用用户名/密码，您都应该使用HTTPS绝对保护整个会话。与暴露用户密码的潜在成本相比，您的成本相对较小。研究表明，人们几乎对他们访问的每个系统都使用相同的密码

此外，除了口令暴露的风险外，还要考虑到你的网站是一个通信工具。被冒充对您的用户有什么潜在的风险或伤害？以他们的身份发送恶意消息

---

这不值得冒险。至少要确保交通安全。

对于某些人来说，密码和年龄将被视为敏感信息。您是否准备好与一些观点与您不同的人打交道？

是的，需要SSL/TLS来维护安全认证的会话。如果您有登录名，则登录名的post和整个会话必须受https保护。即使您有一个简单的web应用程序，将所有流量转发到https也更容易、更安全

问题是，如果使用http，会话id（cookie）可能会泄漏。如果该会话已通过身份验证，则黑客可以使用该会话id与服务器进行身份验证，而无需用户名和密码

这是OWASP 10大A3的明确要求：“断开的身份验证和会话管理”

---

通过http发送cookie也违反了和。

感谢您的专业知识，我认为您和dan story的答案都很好，我比你们投了更高的票。-1用户登录后，攻击者将劫持会话ID。整个会话必须使用https进行保护，这在OWASP前10名中。我希望我能为摘要身份验证再加一个-1，因为它更不安全。请参阅我对answer rook的评论。-1在用户登录后，攻击者将劫持会话ID。整个会话必须使用https进行保护，这是OWASP top 10。rook你在说什么，你可以更具体的lol。你如何通过一个特定的端口使用https，并且只保护会话的一部分。答案怎么会错呢？他只是建议通过加密协议保护服务器交互。如果你的服务器正在使用https进行通信，那么会话不是自动用https进行保护吗？我想他认为我只是建议用https保护登录页面。这绝对不是我的意图；一旦您提示登录，整个会话必须得到保护，直到用户注销。很抱歉，我有点不懂安全性，但如果您将服务器配置为使用该协议，https不会自动这样做，因为所有交互都通过加密通信进行。你说的整个会议的安全是什么意思？抱歉伙计们，我认为这很明显。每个http请求都有您的会话id或“cookie”。如果攻击者可以通过嗅探该行等方式获得该值，那么他们可以使用该行进行身份验证，就好像他们已经提供了用户名/密码一样。请阅读owasp前10名，这清楚地列在会话违规下：顺便说一句，你得到了错误的答案。这与OWASP在会话安全性方面的前10名背道而驰。整个会话必须使用https进行保护，否则就没有意义了。@Rook:根据这个推理，我的前门锁完全没有用，因为有办法通过它。这将阻止那些不想造成可见伤害的临时窃贼，这是一个加分。如果整个会话都是https（尽管大多数证书的中间人很容易受到https的攻击），那就更好了，但这样做只是为了登录，这样可以阻止一些攻击。@david，事实上，是的，你的前门是无用的，可以很容易地找到，pin不倒翁是一种可怕的技术。另外，我同意owasp的说法，如果你泄露了你的会话id，那么攻击者就可以像使用密码一样使用它。SSL/TLS也会停止MITM，这就是它的构建目的。（为了争论而忽略SSLStrip；）为什么你们一直在谈论使用https只部分保护某些功能。我认为它只是自动取代了http协议，所有的通信都通过https格式，从而保护所有的通信，使它们不那么容易受到攻击。有人能详细说明一下这个lol吗，我有点困惑了。@SCAR不客气，你应该给我答案。因为前2名不正确，有人可能