如何在Django LDAP登录名上应用哈希SHA256? [英] How to apply hashing SHA256 on Django LDAP login?

问题描述

我正在Django中使用LDAP身份验证，如下所示，并且还使用了密码哈希.

I'm using LDAP authentication in Django, as shown below and also using password hashers.

from django_auth_ldap.config import PosixGroupType, LDAPSearch
import ldap

PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]

# We use a dedicated user to bind to the LDAP server and execute the server.
AUTH_LDAP_SERVER_URI = "ldap://xx.xx.xx.xx:389"
AUTH_LDAP_BIND_DN = "[e-mail]"
AUTH_LDAP_BIND_PASSWORD = "xxxxx"
AUTH_LDAP_CONNECTION_OPTIONS = {
    ldap.OPT_DEBUG_LEVEL: 1,
    ldap.OPT_REFERRALS: 0,
}

# sAMAccountName is mostly used for Micrsoft Active Directory
# objectCategory    CN=Person,CN=Schema,CN=Configuration,DC=corp,DC=xxxx,DC=com
# (cn=%(user)s)
AUTH_LDAP_USER_SEARCH = LDAPSearch("DC=corp,DC=xxxxx,DC=com", 
                                    ldap.SCOPE_SUBTREE, 
                                    "(&(objectClass=user)(sAMAccountName=%(user)s))")

AUTH_LDAP_USER_ATTR_MAP = {
    "first_name": "givenName",
    "last_name": "sn",
    "email": "mail"
}

但是，我的凭据是以纯文本格式传输的.

But, my credential is transmitting in a plain text.

来自Fiddler:

存储在数据库中的密码:

Password stored in DB:

!Qoc6uEP5h0lOXIeqmSov1HWOL8eY4fmlpJ1Z3q

如何应用散列SHA256?

How to apply hashing SHA256?

注意:该站点已部署在Windows Server 2008 r2的Apache2.4上.

Note: Site was deployed on Apache2.4, Windows server 2008 r2.

推荐答案

tl; dr:这个问题是基于一个误解.客户端哈希不会不能提高安全性，因此不受支持.

tl;dr: This question is based on a misunderstanding. Client side hashing does not improve security, and therefore is not supported.

如果客户端对密码进行哈希处理，则哈希将充当密码的角色:拦截流量的人可以看到哈希，并在以后使用它进行身份验证.

If the client would hash the password, the hash would take the role of the password: Somebody who intercepts the traffic can then see the hash, and use it later to authenticate.

这是客户端不对密码进行哈希处理的主要原因.为了保护您的密码在传输过程中，请使用TLS(但似乎您已经拥有该密码).

That is the main reason why clients do not hash passwords. In order to protect your password while in transit, use TLS (but it appears that you already have that).

通常，密码是由一方(通常是客户，在注册帐户时)选择的对称密钥.使用这种类型的机密进行身份验证时，没有办法避免在某些时候进行传输.解决该问题的唯一方法是:

More generally, a password is a symmetric key that is chosen by one side (usually the client, when registering an account). When using this type of secret for authentication, there is no way to avoid transmitting it at some point. The only ways to get around that are:

1. 不允许任何一方选择机密；而是同意一个秘密.这称为密钥交换".一种众所周知的方法是 Diffie-Hellman密钥交换.在这种情况下，虽然双方都知道，但密钥本身从未传输过. (但是请注意，这对身份验证没有帮助，因为它不会告诉您与谁在密钥上达成共识；它仅有助于建立一次性会话加密密钥.)
2. 不使用对称密钥，而是使用由私钥和公钥组成的密钥对.然后，您可以在不损害安全性的情况下传输公钥，并采用其他身份验证方案(例如，服务器可以要求客户端签署挑战；如果成功，服务器可以推断出客户端拥有私钥，而无需要求服务器拥有它.)

1. Don't allow any party to chose the secret; instead, agree on a secret. This is called "key exchange". One well-known method is Diffie–Hellman key exchange. In this case, the key itself is never transmitted, although both parties know it. (Note, however, that this does not help with authentication, as it does not tell you with whom you're agreeing on a key; it only helps establish a one-time session encryption key.)
2. Don't use symmetric keys, but use a key pair consisting of a private and a public key. You can then transmit the public key without compromising security, and employ another authentication scheme (e.g. the server can ask the client to sign a challenge; if that is successful, the servers can deduce that the client is in possession of the private key, without requiring the server to have it).

如您所见，这两种方法都增加了很多额外的复杂性，并且通常都不适合直接的最终用户身份验证.

As you can see, both methods add a lot of additional complexity, and both of them are typically not suitable for direct end-user authentication.

类似地，客户端哈希还增加了比乍看之下要复杂得多的复杂性.公开的问题包括，例如，使用哪种盐，如何传输盐等.同样，即使回答了这些问题并实施了一些复杂的解决方案，所传输的哈希仍将允许中间人攻击者通过简单地重新使用哈希来模拟客户端.

Similarly, client-side hashing also adds much more complexity than it may seem at first sight. Open questions include, for example, which salt to use, how to transmit the salt etc. And again, even if these questions are answered and some complex solution is implemented, the transmitted hash will still allow a man-in-the-middle attacker to impersonate the client, by simply reusing the hash.

总而言之，客户端哈希并不是安全性的改进，避免对称机密(双方都知道)或避免机密传输的替代方法也无法解决问题.因此，最新的解决方案是将用户的密码实际发送到服务器，并封装在TLS连接中.

All in all, client-side hashing is not a security improvement, and alternatives which avoid symmetric secrets (known to both sides) or which avoid secret transmission also do not solve the problem. Thus, the state-of-the-art solution is to actually transmit the user's password to the server, wrapped within a TLS connection.

这篇关于如何在Django LDAP登录名上应用哈希SHA256?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！