2012-03-31 47 views
2

我认为Javascript是一个安全隐患,因此我希望允许我的网站用户在无需启用Javascript的情况下登录。安全的用户认证,不需要javascript

这给我带来了另一个问题。如果没有客户端脚本,我不知道如何在客户端散列用户密码,以避免明文密码传输。 “纯HTML + CSS”如何让我有密码散列。

目前在我看来,唯一安全的选择(没有Javascript)将是一个安全的(加密的)SSL/HTTPS连接并发送密码为纯文本?

无论如何:有没有某种方法来散列用户密码,以避免以明文形式通过互联网发送。这可能只使用客户端脚本?

[更新] 我知道SSL也许是最接近理想的方式。 (正如评论中提到的那样)总之。在任何时候,明文用户名和明文密码都不会通过不安全的通道发送时,这已经是一项安全改进。哈希也可以被嗅探,并且不存在安全(即加密)。但是,嗅探器无法获得用户名和密码的不相关版本。 =>优势在于用户不会公开他们的用户名/密码组合(可能在别处使用)。

毕竟它似乎没有“禁用脚本” - 对(spice)散列某些输入字段值的途径。所以我认为我的问题是无法解决的。

+4

“SSL”响铃吗? SSL是为此目的而制作的。即使使用JS,HTML + CSS也没有真正的“安全性”。 – Joseph 2012-03-31 07:25:17

+0

我会在JavaScript中实现加密,如果用户禁用JavaScript,我会通知他有关不安全的传输(使用HTML的noscript-tag:'')。 但仍然是最好的,我想最常见的解决方案是通过安全连接(HTTPS)传输。 – 2012-03-31 07:25:57

+1

...或者使用HTTPS和客户端证书 – 2012-03-31 07:29:11

回答

2

首先,如果您使用SSL,那么密码不会以纯文本形式发送。除了初始握手以外的所有内容都被加密,并且相当安全。考虑到这是全世界银行,军队和政府每天都要依靠的安全。我并不是说你应该相信它,只是因为其他人都这么做(argument from authority) - 我只是说如果有问题,我们马上就会听到。

其次,你从来没有真正通过客户端散列获得任何东西。您试图阻止的基本攻击是man-in-the-middle (MITM)攻击。无论是有人窃听连接,嗅探重播攻击的密码,还是主动劫持会话(即假装成服务器和客户端连接到连接的另一端),您都无法通过额外的安全措施真正阻止它。

如果假设攻击者可以通过你的SSL加密,然后依靠一些客户端软件正在做或服务器一起发送可能会受到影响的东西任何其他标记突破。如果它有一些客户端散列函数,那么攻击者可以通过检查服务器发送的网页来了解函数是什么,或者只是嗅探哈希值,并在攻击者与服务器通信时使用它来模拟客户端。如果服务器发送一些安全密钥或令牌供客户端使用并作出响应,则攻击者可以截获该密钥或令牌。

我认为你要找的是two-factor authentication