Question posted in
Some documentation to get you started can be found here.

How to apply hashing SHA256 on Django LDAP login? – Apache

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 = "[email protected]"
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.

From Fiddler:

enter image description here

Password stored in DB:

!Qoc6uEP5h0lOXIeqmSov1HWOL8eY4fmlpJ1Z3q

How to apply hashing SHA256?

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

Tags:

2

Answers


  1. 0

    If you need hash you password try this:

    import hashlib
HashedPassword =hashlib.sha1('PASSWORD'.encode('UTF-8'))
    Login or Signup to reply.
  2. 0

    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.

    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. 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.

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search