php 不使用HTTPS登录，如何安全？

Login without HTTPS, how to secure?

提问by sibidiba

For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure? E.g.:

对于 Web 应用程序，当 HTTPS 作为安全措施不可用时，是否仍然可以使登录有些安全？例如：

• Tokenize logins, to make repeat attacks difficult?
• Somehow encrypt the sent password from a HTML password field?

• 令牌化登录，使重复攻击变得困难？
• 以某种方式加密从 HTML 密码字段发送的密码？

In particular I'm using CakePHP and an AJAX POST call to trigger authentication (includes provided username and password).

特别是我使用 CakePHP 和 AJAX POST 调用来触发身份验证（包括提供的用户名和密码）。

Update on the problem:

问题更新：

• HTTPS is not available. Period. If you don't like the the situation, consider it a theoretical question.
• There are no explicit requirements, you have whatever HTTP, PHP and a browser (cookies, JavaScript etc.) offers in real life (no magic RSA binaries, PGP plugins).
• Question is, what is the best, you can make out of thissituation, that is better than sending the passwords plaintext. Knowing the drawbacks of each such solutions is a plus.
• Any improvement better than plain passwords is welcome. We do not aim for a 100% l33tG0Dhx0r-proff solution. Difficult to crack is better than complicated to hack which is better than a trivial sniffing revealing the password.

• HTTPS 不可用。时期。如果您不喜欢这种情况，请将其视为一个理论问题。
• 没有明确的要求，您拥有现实生活中提供的任何 HTTP、PHP 和浏览器（cookies、JavaScript 等）（没有神奇的 RSA 二进制文件、PGP 插件）。
• 问题是，什么是最好的，您可以摆脱这种情况，这比发送密码明文更好。了解每个此类解决方案的缺点是一个加分项。
• 欢迎任何比普通密码更好的改进。我们的目标不是 100% l33tG0Dhx0r-proff 解决方案。破解难比破解复杂好，破解好过简单的嗅探泄露密码。

回答by rook

HTTPS is absolutely vitalin maintaining a secure connection between a website and a browser. Public wifi networks put users at risk, and when used correctly, HTTPS is the only toolthat can protect user accounts from this vulnerability.

HTTPS对于维护网站和浏览器之间的安全连接绝对至关重要。公共 wifi 网络使用户处于危险之中，如果使用得当，HTTPS 是唯一可以保护用户帐户免受此漏洞影响的工具。

If your host doesn't support HTTPS then a service like Cloudflare Universal SSLcan be used to ensure all browsers connect to your site using HTTPS, even if your server doesn't support SSL/TLS. The connection between Cloudflare and your website will still be unprotected, but this Cloudflare service is intended to protect users against threats found on public wifi networks. From the perspective of a penetration tester, not providing HTTPS is highly suspect, if you aren't providing a basic security requirement as delivering traffic, then what other security requirements are you missing? HTTPS certificates can be obtained for free using Let's Encryptor Start SSL, there is no legitimate reason not to support HTTPS.

如果您的主机不支持 HTTPS，则可以使用Cloudflare Universal SSL 之类的服务来确保所有浏览器都使用 HTTPS 连接到您的站点，即使您的服务器不支持 SSL/TLS 也是如此。Cloudflare 和您的网站之间的连接仍然不受保护，但此 Cloudflare 服务旨在保护用户免受公共 wifi 网络上发现的威胁。从渗透测试人员的角度来看，不提供HTTPS是非常值得怀疑的，如果您没有提供基本的安全要求作为传输流量，那么您还缺少其他哪些安全要求？可以使用Let's Encrypt或Start SSL免费获取 HTTPS 证书，没有正当理由不支持 HTTPS。

HTTPS vital because it does lot more than just "encrypt passwords". Another important role is that it should prevent the user from giving logging into a malicious server that is impersonating a real server. Using a system to protect the password alone is still a violation of OWASP A9 - Insufficient Transport Layer Protectionbecause you would still be transmitting session credentials in plain text which is all the attacker needs (Firesheep).

HTTPS 至关重要，因为它不仅仅是“加密密码”。另一个重要作用是，它应该防止用户登录冒充真实服务器的恶意服务器。单独使用系统来保护密码仍然违反OWASP A9 - 传输层保护不足，因为您仍然会以纯文本形式传输会话凭据，而这正是攻击者所需要的（Firesheep）。

1. JavaScript-based cryptography cannot be used to construct a secure transport layer.

2. "Tokenize logins": If an attacker is sniffing the traffic, they'll have the plain text username/password and then they can just login with these new credentials. (Replay attack)

3. "Somehow encrypt the transmitted password": After the person has logged in an attacker can sniff the traffic to get the valid session id(cookie) and then just use this instead of logging in. If the entire session was protected with SSL/TLS then this is not a problem.

1. 基于 JavaScript 的密码学不能用于构建安全传输层。

2. “令牌化登录”：如果攻击者正在嗅探流量，他们将拥有纯文本用户名/密码，然后他们可以使用这些新凭据登录。（重放攻击）

3. “以某种方式加密传输的密码”：在此人登录后，攻击者可以嗅探流量以获取有效的会话 ID(cookie)，然后只需使用它而不是登录。如果整个会话都受 SSL/TLS 保护，那么这不是问题。

There are other more complex attacks that affect both this system and our current SSL infrastructure. The SSLStripattack goes into greater detail. I highly recommend watching Moxie Marlinspike's Blackhat 2009 talk, which lead to the HTTP-Strict-Transport-Security standard.

还有其他更复杂的攻击会影响这个系统和我们当前的 SSL 基础设施。该SSLStrip攻击进入更多的细节。我强烈推荐观看 Moxie Marlinspike 的 Blackhat 2009 演讲，该演讲导致了HTTP-Strict-Transport-Security 标准。

回答by mctylr

Since you cannot do SSL at the web server, and you are not a security expert, look for an existing secure authentication service that you can utilize, and let them handle both the SSL and the complexities of handling credentials for you.

由于您无法在 Web 服务器上执行 SSL，而且您也不是安全专家，因此请寻找您可以使用的现有安全身份验证服务，让他们为您处理 SSL 和处理凭据的复杂性。

In particular, I would suggest that you use a free third-party authentication service, such as OpenID. They have libraries for PHPincluding one for CakePHP.

特别是，我建议您使用免费的第三方身份验证服务，例如OpenID。他们有PHP库，包括CakePHP库。

---

---

Edit: (about risks)

编辑：（关于风险）

While using a 3rd-party secure authentication service (that uses HTTPS itself) can mitigate the problem doing authentication itself without using HTTPS (on your server), it does not entirely eliminate the possibility of attacks.

虽然使用第 3 方安全身份验证服务（使用 HTTPS 本身）可以缓解在不使用 HTTPS（在您的服务器上）的情况下自行进行身份验证的问题，但并不能完全消除攻击的可能性。

The most common two attacks would be replayattacks, and session-hiHymaningwhere the attacker is able to either re-uses a genuine login session token later, or use a valid session token for their own malicious purpose.

最常见的两种攻击是重放攻击和会话劫持，攻击者可以稍后重新使用真正的登录会话令牌，或者将有效的会话令牌用于自己的恶意目的。

The replay attack can be mitigated by having the session token expiry, and preferably by using a nonceto prevent session replay and to reduces the risk of session hiHymaning. With a nonce, a legitimate session generates an error if successfully hiHymaned, because the nonce has expired (been used), so their own session is no longer valid.

重放攻击可以通过使会话令牌到期来减轻，并且最好使用随机数来防止会话重放并降低会话劫持的风险。使用随机数，如果成功劫持合法会话会产生错误，因为随机数已过期（已被使用），因此它们自己的会话不再有效。

If you cannot use HTTPS to encrypt the session token while being transmitted to and from your server, you cannot entirely prevent active attacks such as session-hiHymaningor man-in-the-middleattack. This maybe acceptable in some cases, such as websites with a small user base for non-commercial usage.

如果在传输到服务器或从服务器传输会话令牌时无法使用 HTTPS 加密会话令牌，则无法完全阻止主动攻击，例如会话劫持或中间人攻击。在某些情况下，这可能是可以接受的，例如用于非商业用途的用户群较小的网站。

回答by ircmaxell

The short answer is that without SSL endpoint to endpoint encryption, it's impossible to do it securely...

简短的回答是，如果没有 SSL 端点到端点加密，就不可能安全地进行...

One of the primary reasons for this is that you can't do secure crypto in a browser. See this reference - Javascript Cryptography Considered Harmful.

造成这种情况的主要原因之一是您无法在浏览器中进行安全加密。请参阅此参考资料 - Javascript Cryptography 被认为有害。

Additionally, there's no way that you can be sure that the source of the credentials are indeed who you're talking to. Meaning that there's absolutely no way without SSL to be sure that there's not a Man-In-The-Middle Attackgoing on.

此外，您无法确定凭据的来源确实是您正在与之交谈的人。这意味着没有 SSL 绝对无法确保不会发生中间人攻击。

So no, you can't do it.

所以不，你不能这样做。

Additionally, don't even try. Get SSL. You can get free certificates. Hosts will usually give you a dedicated IP for a few $$$ per month. And if you really care about security, you'd be using at least a VM with a dedicated IP address anyway.

此外，甚至不要尝试。获取 SSL。您可以获得免费证书。主机通常会以每月几美元的价格为您提供专用 IP。如果您真的关心安全性，无论如何您至少会使用具有专用 IP 地址的 VM。

To even attempt this would be Security Through Obscurityat best, and nothing at worst. SSL is a solved problem. Why not use that solution. Security is not something to guess at. Use the proper techniques. Don't try to invent your own. It won't work...

甚至尝试这样做，充其量只是通过默默无闻的安全，而最坏的情况是没有。SSL 是一个已解决的问题。为什么不使用该解决方案。安全性不是可以猜测的。使用正确的技术。不要试图自己发明。它不会工作...

回答by Justin Ethier

As you suggested, you may be able to generate a unique token each time the page is created. That same token would need to be sent back with the form data and could not be reused. You could also keep the password safe by using JavaScript to hash it, if you can rely on it being enabled by your users.

正如您所建议的，您可以在每次创建页面时生成一个唯一的令牌。同样的令牌需要与表单数据一起发回，并且不能重复使用。您还可以通过使用 JavaScript 对其进行散列来确保密码安全，前提是您可以依靠用户启用它。

This scheme is still not secure, however. An attacker could still see everything going across the wire. They could intercept the token and send a response back to you before the user does. Or they could just wait for someone to login, steal that person's credentials (as they are sent over the wire), and just make their own login request later on.

然而，这个方案仍然不安全。攻击者仍然可以看到通过网络传输的所有内容。他们可以拦截令牌并在用户之前向您发送响应。或者他们可以等待某人登录，窃取该人的凭据（因为它们是通过网络发送的），然后再提出自己的登录请求。

Bottom Line- you need to use HTTPS to guarantee the site is secure.

底线- 您需要使用 HTTPS 来保证站点的安全。

回答by Remus Rusanu

You can use HTTP Digestauthentication, which is supported by most browsers and does not send the password in clear over the wire.

您可以使用大多数浏览器支持的HTTP Digest身份验证，并且不会通过网络以明文形式发送密码。

The downside is the ugly log in box displayed by broswer. If you preffer to stick with forms, then you can implement exactly the same protocol as HTTP Digest in your forms authnetication: send hidden fields containing the realm and the challenge, and have the client add in JavaScript the nonce and compute the digest. This way you'll use a well known and proven exhange protocol, rather than roll your own.

缺点是浏览器显示的登录框丑陋。如果您更喜欢使用表单，那么您可以在表单身份验证中实现与 HTTP Digest 完全相同的协议：发送包含领域和挑战的隐藏字段，并让客户端在 JavaScript 中添加随机数并计算摘要。这样，您将使用众所周知且经过验证的交换协议，而不是自己动手。

HTTP Digest requires only hash operations.

HTTP Digest 只需要散列操作。

回答by SLaks

You can encrypt the password using Javascript and decrypt it on the server.

您可以使用 Javascript 加密密码并在服务器上解密。

I would recommend generating an RSA keypair on the server, send the public key along with a timed salt to the browser, then encrypting the password, combined with the salt, using the public key in Javascript.

我建议在服务器上生成一个 RSA 密钥对，将公钥和定时盐一起发送到浏览器，然后使用 Javascript 中的公钥加密密码，结合盐。

You can find an RSA implementation in Javascript here

您可以在此处找到 Javascript 中的 RSA 实现

You should include both the IP address and the entire X-FORWARDED-FORhedaer in the authentication cookies to prevent cookie theft behind proxies.

您应该在身份验证 cookie 中包含 IP 地址和整个X-FORWARDED -FORhedaer，以防止代理背后的 cookie 被盗。

If you're dealing with sensitive data, you could generate a random AES key in Javascript, then send it to the server along with the password encrypted with RSA.
You could then make the entire application use encrypted AJAX requests from a single page and not use an auth cookie at all.

如果您正在处理敏感数据，您可以在 Javascript 中生成一个随机的AES 密钥，然后将其与用 RSA 加密的密码一起发送到服务器。
然后，您可以让整个应用程序使用来自单个页面的加密 AJAX 请求，而根本不使用身份验证 cookie。

Note that it is not possible to protect against an active man-in-the-middle attack without SSL. An active attacker can completely replace your site with his own proxy, and there isn't any way to defend against that. (Since there cannot be any known good code)

请注意，如果没有 SSL，就无法防范主动的中间人攻击。活跃的攻击者可以用他自己的代理完全替换您的站点，并且没有任何方法可以防御。（因为不可能有任何已知的好代码）

回答by smcjones

HTTPS has numerous use cases, most of which are designed to defend against Man-in-the-middle attacks. Anyone with a hacker's mindset will shudder to tell you that there is no way other than the established way to accomplish something. The fact is that just because you use TLS (the standard which modern HTTPS uses), does not mean you are using it well. Additionally, just using TLS does not prevent someone from exploiting known weaknesses. Just as you may be finding creative ways to secure your data, there are people who are finding creative ways to exploit your security measures.

HTTPS 有许多用例，其中大部分旨在防御中间人攻击。任何有黑客思维的人都会不寒而栗地告诉你，除了既定的方法之外，别无他法。事实是，仅仅因为您使用 TLS（现代 HTTPS 使用的标准），并不意味着您使用得很好。此外，仅使用 TLS 并不能阻止某人利用已知弱点。正如您可能正在寻找创造性的方法来保护您的数据一样，有些人也在寻找创造性的方法来利用您的安全措施。

So, what to do?

那么该怎么办？

First of all, if you're going to forego TLS, it is helpful to understand how it works. And it is all about a handshake.

首先，如果您打算放弃 TLS，了解它的工作原理会很有帮助。这一切都与握手有关。

Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure.[7] During this handshake, the client and server agree on various parameters used to establish the connection's security:

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
• The server sends back its identification in the form of a digital certificate.[contradiction] The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key.
• The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding.
• In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key.
• From the random number, both parties generate key material for encryption and decryption.[contradiction] This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails, and the connection is not created.

一旦客户端和服务器同意使用 TLS，他们就会通过握手过程协商一个有状态的连接。 [7] 在此握手期间，客户端和服务器就用于建立连接安全性的各种参数达成一致：

• 当客户端连接到启用 TLS 的服务器请求安全连接并提供支持的密码套件（密码和哈希函数）列表时，握手开始。
• 从这个列表中，服务器选择一个它也支持的密码和散列函数，并将决定通知客户端。
• 服务器以数字证书的形式发回其标识。[矛盾] 证书通常包含服务器名称、受信任的证书颁发机构 (CA) 和服务器的公共加密密钥。
• 客户端可以联系颁发证书的服务器（如上所述的可信 CA）并在继续之前确认证书的有效性。
• 为了生成用于安全连接的会话密钥，客户端使用服务器的公钥加密一个随机数并将结果发送到服务器。只有服务器应该能够使用其私钥对其进行解密。
• 从随机数中，双方生成用于加密和解密的密钥材料。 [矛盾] 这结束了握手并开始安全连接，该连接使用密钥材料进行加密和解密，直到连接关闭。

如果上述任一步骤失败，则 TLS 握手失败，并且不会创建连接。

Source: Wikipedia

资料来源：维基百科

So, is it possible? Yes. I was taught that anything is possible. It may be expensive, but it is always possible.

那么，有可能吗？是的。我被教导一切皆有可能。它可能很贵，但总是有可能的。

I want to fully disclose that I am NOT a security professional, just an enthusiast. I do not recommend attempting this for a production-grade project or anything other than your own edification. You should DEFINITELY check out this SO postwhich provides an excellent explanation as to roadblocks in setting up your own security protocol.

我想完全公开我不是安全专家，只是一个爱好者。我不建议为生产级项目或除您​​自己的教育之外的任何其他项目尝试此操作。您绝对应该查看这篇 SO 帖子，它对设置您自己的安全协议的障碍提供了很好的解释。

However, if you want to move on, here are some thoughts that come to mind. These are realities that will exist regardless of which direct you went with this project.

但是，如果你想继续前进，这里有一些想法。无论您选择哪个项目，这些都是将存在的现实。

• HTTPS is supported by all major modern browsers. Even with this reality, HTTPS load times are slower than plain HTTP. Without extensive production, it is highly likely your alternative implementation will be a fraction as secure while being significantly slower. This will be a drawback of any homegrown implementation unless you are utilizing browser features, which brings us full circle back to using TLS, which is what modern HTTPS utilizes.

• If you manage to encrypt your password without TLS on the browser side using Javascript in an unpredictable enough fashion that an MiTM attack would be difficult, don't rest there. You also should be securing the data you send back and forth. Otherwise the password being encrypted really is irrelevant. Sure, an attacker might not know bobsmith109's password, but he doesn't need it, because he can sniff every single activity on the network. He knows what times bobsmith109 logs in, can probably trace his IP, and any other sensitive piece of data you send back and forth.

• No matter what security measures you take, there is security in depth. So one thing that you can do right off the bat is make sure you encrypt your data in the database while also requiring strong passwords.

• 所有主要的现代浏览器都支持 HTTPS。即使在这种现实情况下，HTTPS 加载时间也比普通 HTTP 慢。如果没有大量生产，您的替代实施很可能只是安全性的一小部分，而速度却要慢得多。除非您使用浏览器功能，否则这将是任何本土实现的一个缺点，这使我们回到使用 TLS 的完整循环，这是现代 HTTPS 所使用的。

• 如果您设法在浏览器端使用 Javascript 以一种不可预测的方式在没有 TLS 的情况下加密密码，以至于 MiTM 攻击将变得困难，请不要停在那里。您还应该保护来回发送的数据。否则被加密的密码真的无关紧要。当然，攻击者可能不知道 bobsmith109 的密码，但他不需要它，因为他可以嗅探网络上的每一个活动。他知道 bobsmith109 登录的时间，可能可以追踪他的 IP，以及您来回发送的任何其他敏感数据。

• 无论您采取何种安全措施，都有深度的安全保障。因此，您可以立即做的一件事是确保对数据库中的数据进行加密，同时还需要强密码。

I reiterate that I am nota security professional and strongly discouragethis as anything other than to satiate your curiosity. It is astronomically improbable that you can create a viable alternative to TLS without an extraordinarily large group of security professionals contributing to a project for years if not decades, which is what SSL/TLS can boast. That being said, a good starting point if you choose to go forward is to look at the handshake model above and see how you can implement a version of this without TLS.

我重申，我不是安全专业人士，并且强烈不鼓励这样做，只是为了满足您的好奇心。如果没有大量的安全专业人员为一个项目贡献数年甚至数十年的时间，您就可以创建 TLS 的可行替代方案，这在天文上是不可能的，而 SSL/TLS 可以夸耀这一点。话虽如此，如果您选择继续前进，一个很好的起点是查看上面的握手模型，看看如何在没有 TLS 的情况下实现此版本。

I would be remiss to not share in my post that most real-life barriers to using HTTPS are being actively fought against. One of the largest - cost - is very close to becoming a non-issue. A free certificate authority will be coming out 2Q 2015 is supported by some big guns, including Mozilla and Akamai, to name a few. Here is an article.

我很遗憾没有在我的帖子中分享使用 HTTPS 的大多数现实障碍正在积极对抗。其中最大的一个——成本——非常接近成为一个非问题。免费的证书颁发机构将于 2015 年第二季度推出，得到一些巨头的支持，包括 Mozilla 和 Akamai，仅举几例。这是一篇文章。

回答by AndiDog

What about HTTP Digest Authentication? It provides security by MD5-hashing username, password and a nonce (among other things) before sending it to the server. MD5 isn't really secure, but it's a good way for simple security with HTTP.

什么HTTP摘要式身份验证？它通过 MD5 散列用户名、密码和随机数（以及其他内容）在将其发送到服务器之前提供安全性。MD5 并不是真正安全，但它是通过 HTTP 实现简单安全性的好方法。

Of course this doesn't prevent hackers from changing the message... but it secures your password.

当然，这并不能阻止黑客更改消息……但它可以保护您的密码。

回答by dnozay

Login without HTTPS, how to secure?

不使用HTTPS登录，如何安全？

Since there is no secure channel between your server and your client:

由于您的服务器和客户端之间没有安全通道：

• because there is no secure channel, anybody can snoop your traffic.
• because anybody can snoop the traffic, you are open to a MITM attack.
• because you are open to MITM attack, there is no guarantee you client will see a legitimate page.
• because the pages are not legitimate and your page is in effect not being served (the guy in the middle is serving the pages), all tricks used server-side are rendered useless.

• 因为没有安全通道，任何人都可以窥探您的流量。
• 因为任何人都可以窥探流量，所以您很容易受到 MITM 攻击。
• 因为您对 MITM 攻击持开放态度，所以不能保证您的客户会看到合法页面。
• 因为页面不合法并且您的页面实际上没有被提供（中间的人正在为页面提供服务），服务器端使用的所有技巧都变得无用。

What can you do? Theorically?

你能做什么？理论上？

• both client and server need to use encryption to make snooping / MITM less susceptible.
• assume you cannot have a handshake,
• assume your client already has your key and knows how to speak the same gibberish as your server.
• how about some SSL over HTTP but wrapped in base64-encoded message for some gibberish?

• 客户端和服务器都需要使用加密来降低窥探/MITM 的敏感性。
• 假设你不能握手，
• 假设您的客户已经拥有您的密钥并且知道如何说与您的服务器相同的胡言乱语。
• 一些基于 HTTP 的 SSL 但包装在 base64 编码的消息中如何？

But wait... Since you said no magic binary, or plugin, not even RSA, I don't know if any of this is possible save for (some potentially very weak) in-house encryption.

但是等等......因为你说没有神奇的二进制文件或插件，甚至没有 RSA，我不知道除了（一些可能非常弱的）内部加密之外是否有可能。

--

——

回答by Umur Kontac?

You can try to replicate it to some point, by using public key encryption (GPG maybe) and making use of browser caching.

您可以尝试将其复制到某个点，方法是使用公钥加密（可能是 GPG）并利用浏览器缓存。

This is not something secure, even just putting up SSL won't be enough for a sophisticated attacker, you need to make use of HSTS, public key pinning etc to just to consider a web site secure today.

这不是安全的东西，即使只是建立 SSL 对一个老练的攻击者来说也是不够的，你需要利用 HSTS、公钥固定等来考虑今天的网站安全。

The rest of the answer is just food for thought.

其余的答案只是思考的食物。

1. Create a public-private key pair. Keep private one secure.
2. Create a js file containing the public key and a encryptfunction, find a secure encryption algorithm. This function should encrypt a given string (serialized form) with an additional timestamp, to avoid a replication attack.
3. Serve this file with Cache-Control:public, max-age=31536000HTTP header. We try to mitigate when the attacker tries to replace the script. The file will always be served from the browser cache.
4. Send all the forms via Javascript, using the encryptfunction. Serve these with the same header as above.
5. At the server side, decryptthe data, check the timestamp, if it's still valid. Do you thing, if not, discard it.
6. Create a cookie token which can only be used once for a very short amount of time. If the attacker captures a cookie, he won't have much time to do stuff. However, if the attacker is fast enough, then he might log the original user out.
7. Change the cookies with every response. But then what do you do when the user sends multiple requests at once and then they arrive in the reverse order? Which cookie is valid? This creates tons of problems at the cost of a false sense of security.

1. 创建公私钥对。保持私人安全。
2. 创建一个包含公钥和encrypt函数的js文件，找到一个安全的加密算法。此函数应使用附加时间戳对给定字符串（序列化形式）进行加密，以避免复制攻击。
3. 使用Cache-Control:public, max-age=31536000HTTP 标头提供此文件。当攻击者试图替换脚本时，我们会尝试进行缓解。该文件将始终从浏览器缓存中提供。
4. 使用该encrypt函数通过 Javascript 发送所有表单。使用与上述相同的标题提供这些服务。
5. 在服务器端，decrypt数据，检查时间戳，如果它仍然有效。做你的事，如果不是，丢弃它。
6. 创建一个只能在很短的时间内使用一次的 cookie 令牌。如果攻击者捕获了 cookie，他将没有太多时间做任何事情。但是，如果攻击者足够快，那么他可能会注销原始用户。
7. 更改每次响应的 cookie。但是当用户一次发送多个请求然后它们以相反的顺序到达时，你会怎么做？哪个 cookie 是有效的？这以错误的安全感为代价产生了大量问题。

Any listeners won't be able to make use of the data going back and forth, and they won't be able to change/inject the existingJSfiles until the cache expires / user clears the cache. However, any sophisticated attacker can replace the whole HTMLfile which would discard all the security measurements I have just mentioned. If you can at least serve this file / form over HTTPS, you mightget away with it, put them on github pages or whatever. However, if you put the file some other domain, then you need to set up CORSfor the receiving domain for this to work.

任何侦听器都无法使用来回传输的数据，并且在缓存过期/用户清除缓存之前，他们将无法更改/注入现有JS文件。但是，任何老练的攻击者都可以替换整个HTML文件，这会丢弃我刚才提到的所有安全措施。如果你至少可以提供这个文件/表单HTTPS，你可能会逃脱它，将它们放在 github 页面或其他任何地方。但是，如果您将文件放在其他域中，那么您需要设置CORS接收域才能使其正常工作。

Another try

另一个尝试

One time passwords sent to email.

一次性密码发送到电子邮件。

1. User fills out their email, clicks a link which then sends a link to their email with a token that will enable them logging in.
2. User clicks the link
3. Server checks the token, logs the user in.
4. Rolls the cookies like the previous example.

1. 用户填写他们的电子邮件，点击一个链接，然后将一个链接发送到他们的电子邮件，并带有一个令牌，使他们能够登录。
2. 用户点击链接
3. 服务器检查令牌，让用户登录。
4. 像前面的例子一样滚动饼干。

All in all, whatever you do, it is not secure. Given a fast, sophisticated attacker, nothing stands in the way.

总而言之，无论你做什么，都不安全。鉴于一个快速、老练的攻击者，没有什么可以阻挡的。

Get SSL, if the infrastructure does not support it, change it. If your manager does not believe in SSL, convince him/her. Don't create a false sense of security. Protect your user's data, depending on your location, you are legally required to protect the data of your users.

获取 SSL，如果基础架构不支持，请更改它。如果您的经理不相信 SSL，请说服他/她。不要制造虚假的安全感。保护您用户的数据，根据您所在的位置，法律要求您保护用户的数据。

Then let's talk about how to make a site secure with SSL.

然后让我们谈谈如何使用 SSL 使站点安全。