对于Web应用程序，当HTTPS不能用作安全措施时，是否仍可以使登录更安全？例如：
特别是，我使用CakePHP和AJAX POST调用来触发身份验证（包括提供的用户名和密码）。
问题更新：
Answers:
HTTPS对于维持网站和浏览器之间的安全连接至关重要。公共wifi网络使用户处于危险之中，正确使用HTTPS是唯一可以保护用户帐户免受此漏洞影响的工具。
如果您的主机不支持HTTPS，那么即使您的服务器不支持SSL / TLS，也可以使用Cloudflare Universal SSL之类的服务来确保所有浏览器都使用HTTPS连接到您的站点。Cloudflare与您的网站之间的连接仍然不受保护，但是此Cloudflare服务旨在保护用户免受公共wifi网络上的威胁的侵害。从渗透测试人员的角度来看，高度怀疑是否提供HTTPS，如果您在提供流量时没有提供基本的安全要求，那么您还缺少其他哪些安全要求？可以使用Let's Encrypt或Start SSL免费获得HTTPS证书，没有正当理由不支持HTTPS。
HTTPS至关重要，因为它不仅具有“加密密码”的功能。另一个重要作用是，它应防止用户登录到冒充真实服务器的恶意服务器。仅使用系统来保护密码仍然违反OWASP A9-传输层保护不足，因为您仍将以纯文本格式传输会话凭据，这正是攻击者所需要的（Firesheep）。
“标记登录名”：如果攻击者正在嗅探流量，则他们将具有纯文本用户名/密码，然后就可以使用这些新凭据登录。（重播攻击）
“以某种方式加密传输的密码”：该人登录后，攻击者可以嗅探流量以获取有效的会话ID （cookie），然后仅使用它代替登录。如果整个会话都受到SSL / TLS的保护，则这不是问题。
还有其他更复杂的攻击会同时影响此系统和我们当前的SSL基础结构。该SSLStrip攻击进入更多的细节。我强烈建议观看Moxie Marlinspike在Blackhat 2009上的演讲，该演讲引出了HTTP-Strict-Transport-Security标准。
由于您不能在Web服务器上执行SSL，并且您不是安全专家，因此请寻找可利用的现有安全身份验证服务，并让它们为您处理SSL和处理凭据的复杂性。
特别是，我建议您使用免费的第三方身份验证服务，例如OpenID。他们有用于PHP的库，其中包括一个用于CakePHP的库。
编辑：（关于风险）
尽管使用第三方安全身份验证服务（本身使用HTTPS）可以缓解不使用HTTPS（在您的服务器上）而进行身份验证的问题，但是并不能完全消除攻击的可能性。
最常见的两种攻击是重播攻击和会话劫持，攻击者可以在以后重新使用真正的登录会话令牌，或者将有效的会话令牌用于自己的恶意目的。
重播攻击可以通过使会话令牌到期而减轻，并且最好通过使用随机数来防止会话重播并降低会话劫持的风险。使用随机数，如果成功劫持，则合法会话会生成错误，因为随机数已过期（已使用），因此其自己的会话不再有效。
如果在与服务器之间进行传输时无法使用HTTPS加密会话令牌，则无法完全阻止主动攻击，例如会话劫持或中间人攻击。在某些情况下（例如，非商业用途的用户群较小的网站），这可能是可以接受的。
简短的答案是，如果没有SSL端点到端点的加密，就不可能安全地进行加密...
造成这种情况的主要原因之一是您无法在浏览器中进行安全加密。请参阅此参考-Javascript密码术被认为有害。
此外，您无法确定凭据的来源确实是您正在与之交谈的人。这意味着没有SSL绝对不可能确保不会发生中间人攻击。
所以不，你做不到。
此外，甚至不要尝试。获取SSL。您可以获得免费证书。主机通常会为您提供专用IP，每月只需几美元。而且，如果您真的关心安全性，那么至少要使用具有专用IP地址的VM。
甚至尝试这样做，充其量不过是通过模糊实现安全，而在最坏情况下则没有。SSL是一个已解决的问题。为什么不使用该解决方案。安全性不是猜测。使用适当的技术。不要试图发明自己的。那行不通...
您可以使用Javascript加密密码，然后在服务器上将其解密。
我建议在服务器上生成一个RSA密钥对，将公共密钥和定时盐一起发送到浏览器，然后使用Javascript中的公共密钥对密码和盐进行加密。
你可以找到在Javascript中的RSA实现这里
您应该在身份验证Cookie中同时包含IP地址和整个X- FORWARDED -FOR hedaer，以防止Cookie被代理盗用。
如果您要处理敏感数据，则可以在Javascript中生成一个随机AES密钥，然后将其与使用RSA加密的密码一起发送到服务器。
然后，您可以使整个应用程序使用单个页面中的加密AJAX请求，而根本不使用身份验证cookie。
请注意，如果没有SSL，就无法防范主动的中间人攻击。活跃的攻击者可以用自己的代理完全替换您的站点，并且没有任何方法可以防御。（因为没有任何已知的好的代码）
您可以使用大多数浏览器都支持的HTTP摘要式身份验证，并且不会通过网络直接发送密码。
缺点是浏览器显示的丑陋的登录框。如果您喜欢使用表单，则可以在表单身份验证中实现与HTTP Digest完全相同的协议：发送包含领域和质询的隐藏字段，并让客户端在JavaScript中添加随机数并计算摘要。这样，您将使用众所周知且经过验证的交换协议，而不用自己动手。
HTTP摘要仅需要哈希操作。
什么HTTP摘要式身份验证？在将其发送到服务器之前，它通过MD5散列用户名，密码和随机数（除其他外）来提供安全性。MD5并不是真正的安全性，但这是通过HTTP实现简单安全性的一种好方法。
当然，这并不能阻止黑客更改消息……但是可以保护您的密码。
HTTPS有许多用例，其中大多数用于防御中间人攻击。任何有黑客思维的人都会不停地告诉您，除了确定的方法之外，别无他法。事实是，仅仅因为您使用TLS（现代HTTPS使用的标准），并不意味着您使用得很好。此外，仅使用TLS并不能防止某人利用已知的弱点。正如您可能会找到创新的方法来保护数据安全一样，有些人也在寻找创新的方法来利用您的安全措施。
那么该怎么办？
首先，如果您要放弃TLS，了解它的工作原理将很有帮助。一切都与握手有关。
一旦客户端和服务器同意使用TLS，他们就会通过握手程序协商有状态连接。[7] 在此握手期间，客户端和服务器会同意用于建立连接安全性的各种参数：
- 当客户端连接到启用了TLS的服务器以请求安全连接并显示受支持的密码套件（密码和哈希函数）列表时，握手开始。
- 服务器从该列表中选择一个它也支持的密码和哈希函数，并将决定通知客户端。
- 服务器以数字证书的形式发回其标识。[矛盾]证书通常包含服务器名称，可信证书颁发机构（CA）和服务器的公共加密密钥。
- 客户端可以与颁发证书的服务器（如上所述的受信任CA）联系，并在继续操作之前确认证书的有效性。
- 为了生成用于安全连接的会话密钥，客户端使用服务器的公共密钥对随机数进行加密，然后将结果发送到服务器。只有服务器应该能够使用其私钥对其进行解密。
- 双方都从随机数生成用于加密和解密的密钥材料。[矛盾]这结束了握手，并开始了安全连接，该安全连接使用密钥材料进行加密和解密，直到连接关闭。
如果以上任何一个步骤失败，则TLS握手失败，并且不会创建连接。
资料来源：维基百科
那么，有可能吗？是。我被告知一切皆有可能。它可能很昂贵，但始终是可能的。
我想充分说明我不是安全专家，而是狂热者。我不建议您将其用于生产级项目或您自己的版本之外的其他项目。您应该明确查看此SO帖子，它为设置您自己的安全协议提供了很好的解释。
但是，如果您想继续前进，请记住以下一些想法。无论您直接从事此项目如何，这些现实都会存在。
所有主要的现代浏览器都支持HTTPS。即使在这种情况下，HTTPS加载时间也比普通HTTP慢。如果不进行大量生产，则您的替代实现很可能仅是安全性的一小部分，但速度明显慢得多。除非您使用浏览器功能，否则这将是任何本地实现的缺点，这使我们全面回到使用TLS（现代HTTPS使用的功能）的角度。
如果您设法在浏览器端使用Javascript以一种无法预测的方式来加密密码而不使用TLS，以至于MiTM攻击将很难进行，请不要就此止步。您还应该保护来回发送的数据。否则，加密的密码实际上是无关紧要的。当然，攻击者可能不知道bobsmith109的密码，但是他不需要它，因为他可以嗅探网络上的每个活动。他知道bobsmith109登录的时间，可能可以跟踪他的IP以及来回发送的任何其他敏感数据。
不管您采取什么安全措施，都需要深入的安全性。因此，您可以立即做的一件事是确保您在加密数据库中的数据的同时还要求使用强密码。
我重申，我不是安全专家，因此除了满足您的好奇心外，强烈建议不要这样做。从天文学角度讲，您不可能创建一种可行的TLS替代方案，而无需花费大量的安全专业人员来为一个项目贡献数年甚至数十年的时间，而这正是SSL / TLS所能证明的。话虽如此，如果您选择继续前进，一个很好的起点是查看上面的握手模型，并了解如何在不使用TLS的情况下实现该版本。
我不愿在我的帖子中不分享正在积极反对使用HTTPS的大多数现实障碍。其中最大的一项-成本-即将成为非问题。包括Mozilla和Akamai在内的一些知名人士将在2015年第二季度发布免费的证书颁发机构。这是一篇文章。
由于服务器和客户端之间没有安全通道：
但是，等等...因为您说过没有魔术二进制或插件，甚至没有RSA，所以我不知道除了内部加密（某些可能非常弱）之外，是否有可能这样做。
-
您可以尝试通过使用公共密钥加密（可能是GPG）并利用浏览器缓存来将其复制到某个点。
这是不安全的，即使仅仅安装SSL也不足以满足高级攻击者的需要，您需要利用HSTS，公共密钥固定等功能来确保当今的网站安全。
剩下的答案只是思考。
encrypt函数的js文件，找到安全的加密算法。此函数应使用附加的时间戳来加密给定的字符串（序列化形式），以避免复制攻击。Cache-Control:public, max-age=31536000HTTP标头提供此文件。当攻击者尝试替换脚本时，我们尝试缓解。该文件将始终从浏览器缓存中提供。encrypt函数通过Javascript发送所有表单。用与上述相同的标题服务。decrypt检查数据是否仍然有效。如果没有，您是否丢弃它？任何侦听器将无法使用来回的数据，并且他们将无法更改/注入现有 JS文件，直到缓存过期/用户清除缓存。但是，任何高级攻击者都可以替换整个HTML文件，这将丢弃我刚才提到的所有安全度量。如果至少可以将此文件/表单提供给HTTPS，则可以摆脱它，将它们放在github页面上或其他任何东西上。但是，如果将文件放在其他域中，则需要CORS为接收域进行设置才能使其正常工作。
一次将密码发送到电子邮件。
总而言之，无论您做什么，都是不安全的。对于快速，精明的攻击者，没有任何障碍。
获取SSL，如果基础结构不支持SSL，请对其进行更改。如果您的经理不相信SSL，请说服他/她。不要制造错误的安全感。保护您的用户数据，根据您所在的位置，法律上要求您保护用户的数据。
然后，让我们谈谈如何使用SSL保护网站安全。
使用非对称密码创建公钥/私钥对。
在服务器上创建一个对称密钥。
将公钥发送到客户端。
为对称密码客户端创建一个随机密钥。
使用公共密钥客户端对该随机密钥进行加密。
将加密的密钥发送到服务器。
服务器执行以下操作：
一种。使用私钥解密随机对称密钥。
b。创建一个包含生成的客户端密钥的令牌。
C。签署令牌。
d。使用服务器对称密钥对令牌进行加密。
e。使用客户端生成的密钥对已经加密的令牌进行加密。
F。向下发送加密令牌。
客户端收到此令牌并执行以下操作：
一种。用它生成的密钥解密令牌。
b。存储解密的令牌。
C。此时，仅使用服务器对称密钥对存储的令牌进行加密。
在从客户端到服务器的每一个上：
一种。使用客户端生成的密钥对出站数据进行加密。
b。发送令牌+加密数据
在每个请求中，服务器都会收到：
一种。使用服务器对称密钥解密令牌。
b。验证签名。
C。使用存储在令牌中的客户端生成的密钥解密数据。
看看“安全远程密码协议”。
让我从他们的网站上引用一下，而不是自己制定：
安全远程密码协议对易记的简短密码执行安全的远程身份验证，并抵御被动和主动网络攻击。
和：
[the]协议将零知识证明技术与非对称密钥交换协议相结合，与可抵抗诸如增强型EKE或B-SPEKE等被盗验证者攻击的强大扩展方法相比，该协议提供了显着提高的性能。
尽管斯坦福大学本身未提供PHP和JavaScript的实现，但它们链接到某些第三方实现。
这些链接之一指向“ Clipperz”，这是一个在线密码管理器。它也可以作为社区版本在GitHub上获得。他们在那里托管了实现协议的“ javascript-crypto-library”和“ password-manager”本身，其中包含用PHP和Python编写的后端。
我不能说提取代码的相关部分有多困难，但是也许您可以重用它们的实现（该代码已通过AGPL许可）。
编辑2014/10/24：
维基百科有关SRP的文章列出了更多实现。与PHP / JS相关：
对于某种程度安全的HTTP连接，我所见的最佳解决方案是使用md5sum（或其他某种哈希）的Javascript实现，以避免以明文形式传输密码。您可以在Javascript中创建表单onsubmit处理程序，以原始值的哈希值替换密码字段。这为不安全的连接增加了适度的安全性，但是要依靠浏览器中运行的Javascript才能正常工作。
我猜您是否关心将密码安全传输到服务器？我的答案是：不要将密码传输到服务器:)
实际上，您可能无法将任何内容从浏览器（用户）传输到服务器以对用户进行身份验证，因为监视HTTP流量的攻击者还可以重新传输数据并进行身份验证。
提案：
显而易见的解决方案是使用源自服务器的单向，一次性交易身份验证；例如只能使用一次的交易号。最终，您仍然需要一次安全通道来与用户同步交易号列表。
您可以使用某种Google身份验证器，但是您需要一次安全通道来在任一侧设置参数。如果您认为电子邮件是安全的，那将是一种方法。
我的系统也有同样的问题。我已采取措施尝试提高安全性，而又不会因复杂的机制而损害用户体验。我注意到的是，绝大多数用户是使用同一浏览器（但不一定是相同的IP地址）从同一台计算机登录的，或者是从几个浏览器（例如台式机或移动设备）登录的。我决定可以使用它来识别模式。
1）在注册过程中，要求用户具有强密码（以防止字典攻击），安全问题/答案和标准电子邮件验证（以真实身份证明）
2）登录期间，在5次失败的登录尝试之后（而不是之前），将显示一个验证码，以防止蛮力攻击。
3）最后，在成功登录后，我创建了部分用户代理字符串的哈希，其中包含用户操作系统，浏览器（一般不是版本）和语言-形成了一种辅助密码。如果下次登录时useragent哈希明显不同，则要求用户回答安全性问题。然后，如果回答令人满意，则对新的UA字符串进行哈希处理并将其添加到其“安全机器”列表中，这样就不会再从此机器上询问他们了。这类似于Steam游戏系统采用的机制。
大约700个用户已经成功使用了一年多，并且它还具有防止“登录共享”的额外好处-多个用户为了方便而使用相同的凭据！
答案是简短的，而且如果您真的对安全性有问题，则总是可以选择不同官僚级别的选择。
绝对安全性不存在。木马和键盘记录器始终是客户端的头号漏洞。SSL并没有帮助。
1）代币生成器：银行使用它们，然后暴雪使用。它可以是设备或应用程序。好吧..它很贵。
2）SMS引脚。有趣且价格合理的解决方案。市场上有很多来自短信的价格不错，而且每个人都有一部能够接收它的电话。
3）如果必须使用HTTP，则可以强制使用第三方oauth服务，例如google或facebook。如果没有令牌生成器，那是最好的选择。
使用哈希机制来存储密码，并始终将哈希密码进行比较，那么即使您也没有人知道真实密码。这很简单，但是很有效，但是没有什么是完全安全的，并且有一些方法可以打破安全层。
如果您不能使用HTTPS或不想使用HTTPS，请考虑使用jCryption。jCryption为通过HTTP请求（POST，GET等）发送的数据提供加密。
您可以在此处测试该技术：http : //www.jcryption.org/#examples
如果您使用的是Firebug，则会看到所有数据都已加密。
它具有用于在前端加密数据的jQuery库和用于在后端解密数据的PHP库。
尝试以下操作：在登录页面的每个请求上，发送随机数和时间戳。在发布到服务器时，发送以下四个详细信息：
用户名，随机数和时间戳为纯文本格式。然后，用分隔符（例如：换行符）将上述内容连接起来，并使用用户密码作为链块密码模式下的加密进行加密。
在服务器端，使用用户名查找密码并验证加密的字符串。
由于永远不会以明文形式发送密码，因此它是安全的，并且可以使用时间戳来避免重新提交相同的数据。
为了避免通过中间人攻击获得会话密钥来劫持会话，密码或密码哈希可以由客户端上的应用程序存储在内存中，并用于生成唯一的会话密钥用于服务器验证。
看看OAuth 1.0也不是坏主意。
如果没有，很难保证通信的安全trusted third party，但是，有一些安全技巧可为您提供：
每个敏感信息都应进行适当的哈希处理或公共密钥加密。注意：如果您选择通过公共密钥加密用户的敏感信息，请确保用户可以验证公共密钥。例如，您可以通过SMS甚至自动呼叫向用户发送某种公钥指纹。
安全登录事务后，应生成一个共享机密。生成过程可以参考SSL Handshake。注意：共享机密一旦生成，就必须继续进行传输。它的唯一功能是加密/解密之间的数据Server和Broswer
愿这些技巧可以帮助您