无需 SSL 的安全身份验证 [英] Secure authentication without SSL

问题描述

我开始编写一个小型 Web 应用程序并开始考虑保护登录(仅用于管理).

I'm starting to write a small web application and have started thinking about securing login (only used for administration).

如果可以的话，我会安装一个 CACert 或自签名 SSL 证书，因为现在我将是唯一登录的人，但我的主人不太乐于助人.

If I could, I'd install a CACert or self-signed SSL certificate, since for now I'll be the only one logging in, but my host isn't too accommodating.

是否有任何合理的选择可以在没有 SSL 的情况下保护站点?我一直在考虑身份验证选项:

Are there any reasonable options for securing the site without SSL? I've been thinking about options for authentication:

1. 在 JavaScript 中实现加盐哈希.加载登录页面后，生成一个salt 服务器端.将其以明文形式发送给客户端并将其存储在会话变量中.

1. Implement a salted hash in JavaScript. When the login page is loaded, generate a salt server-side. Send it to the client in the clear and store it in a session variable.

摘要式身份验证.我刚刚发现这个想法浏览 SO，它可能比滚动我自己的身份验证更合理.

Digest authentication. I just found this idea browsing SO, and it's probably a lot more reasonable than rolling my own auth.

OpenID.这是一个开放标准，不需要密码(我可以劫持"我的 OpenID 提供商的 SSL 以增加登录过程的安全性)，但我不知道 OpenID 是如何工作的或它有多安全.(需要研究.例如，可以重放 OpenID 身份验证吗?)

OpenID. It's an open standard, no passwords are required (and I can "hijack" my OpenID provider's SSL to add security to the login process), but I have no idea how OpenID works or how secure it is. (Needs research. For example, can an OpenID authentication be replayed?)

所有这些的问题在于:

• 会话可能被劫持
• 只有登录是安全的，其他一切都一目了然

我能想到的在登录后保护应用程序的唯一选择是一些令人厌恶的 JavaScript 和 PHP 来回发送加密的 ASCII blob.我不想这样做.

The only option I can think of for securing the app after login is some disgusting JavaScript and PHP sending encrypted blobs of ASCII back and forth. I don't want to do this.

是否有任何加密(用于页面加载和 POST)可以在我选择的服务器端脚本语言中实现，而无需我的主机的支持或参与，但浏览器会支持?会话是否可以在没有 SSL 的情况下防止劫持(实际上)?

Is there any encryption (for pageloads and POSTs) that can be implemented in my server-side scripting language of choice without the blessing or involvement of my host, but that would be supported by the browser? Can sessions be secured from hijacking (practically) without SSL?

遇到这种情况你会怎么做?

What would you do in a situation like this?

推荐答案

您可以安全地进行身份验证，而无需实施窃听保护.例如，您可以阻止其他人发送请求，即使他们可以阅读您请求的内容.如果您需要防止窃听，我建议您前往可以使用 SSL 的地方.

You can securely authenticate without needing to implement protection against eavesdropping. For example, you can prevent others from sending requests, even though they can read the contents of your requests. If you need to protect against eavesdropping, I'd recommend just going somewhere where you can use SSL.

如果您只需要简单的身份验证而没有真正的安全性，您的提供商可能会支持 HTTP Basic.这(以及限制功能和备份的良好设计；)是您担心其他问题的合理临时解决方案.

If you just need simple authentication without real security, your provider will probably support HTTP Basic. This (along with a good design which limits capabilities, and backups ;) is a reasonable interim solution while you worry about other problems.

为了验证您的身份，OpenID 无法重播.每个身份验证序列都经过签名.但是，OpenID 本身仅允许您与服务器建立身份.它不会让您签署或以其他方式验证请求.OAuth 可以，但它需要对部分协议进行传输加密.

For authenticating your identity, OpenID can't be replayed. Each authentication sequence is signed. However, OpenID by itself only lets you establish your identity with the server. It won't let you sign or otherwise authenticate a request. OAuth would, but it requires transport encryption for part of the protocol.

您可以使用共享密钥签署每个请求.这将阻止攻击者提交或重放请求，但请求本身仍然可以被窃听者读取.请参阅 Amazon AWS 身份验证(包括客户端库)或 flickr 身份验证的文档.基本协议是:

You could sign each request with a shared secret. This would prevent an attacker from submitting or replaying a request, but the requests themselves can still be read by an eavesdropper. See the documentation for Amazon AWS authentication (which includes client libraries) or flickr's authentication. The basic protocol is:

• 需要一个时间戳(可能还有一个随机数)作为请求参数
• 规范化、排序、连接所有请求参数
• 连接 URI、主机、动词等.
• 使用密钥进行散列
• 在请求头中发送哈希
• 服务器做同样的事情并比较签名

这篇关于无需 SSL 的安全身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！