Skip to main content

How Django stores passwords

 

Django Password



Django provides a flexible password storage system and uses PBKDF2 by default. Django saves the password as below.

<algorithm>$<iterations>$<salt>$<hash>

example of a Hashed password stored in database:

pbkdf2_sha256$390000$LCm33kvO7rbjbZhwJA90Sf$xfuGOzl/MJyUxqWNhsNdSThaQUvn1EjEfxZ48HA8HF4=

Those are the components used for storing a User’s password,separated by the dollar-sign character and consist of: 

1. The hashing algorithm

2. The number of algorithm iterations (work factor)

3. The random salt

4. The resulting password hash. 



Most password hashes include a salt along with their password hash in order to protect against rainbow table attacks.

Example of Making Hashed password:



Here’s a simplified overview of how Django handles password storage:


  1. 1. Password Creation or Change:

    • # When someone creates a new account or decides to change their password, Django takes their chosen password and performs a process called hashing. Hashing is like scrambling the password into a format that is hard to reverse.

    • # To add an extra layer of security, Django also generates a random value called a "salt." This salt is mixed with the password before hashing. Think of it like adding a secret ingredient to a recipe.

  2. 2. Storing the Password:

    • # After hashing the password with the salt, Django saves both the resulting scrambled password (technically called a hash) and the salt into the database. It's like putting the locked recipe (hash) and the secret ingredient (salt) into a safe (database) for later use.

  3. 3. Logging In:

    • # When a user wants to log in, they provide their username and password.

    • # Django looks up the stored hash and salt associated with that username from the database.

  4. 4. Verifying the Password:

    • # Django then takes the password provided during login and repeats the hashing process using the stored salt.

    • # If the result of this process matches the stored hash, it means the provided password is correct. It's like recreating the locked recipe using the same secret ingredient. If the recreated recipe matches the one stored in the safe, Django lets the user in.

This process ensures that user passwords are stored securely and cannot be easily compromised, even if an attacker gains access to the database.

# Why django uses 'random' salt beside 'one' salt string?

Because if you would have one salt you could generate rainbow tables attack for your database easier than when there are random salts. 

If you would like to generate rainbow tables to decrypt django hashes you would have to generate tables for each different salt in database. Generating of rainbow tables take very long time, it's just brute force or dictionary attack.


By default, Django uses the PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST. This should be sufficient for most users: it’s quite secure, requiring massive amounts of computing time to break.

If anyone need to use different password Hashing Algorithm then it's flexible to do in django. 

# How to use different Password Hashing Algorithm ? 


Django chooses the algorithm to use by consulting the PASSWORD_HASHERS in settings.py. 

This is a list of hashing algorithm classes that this Django installation supports. For storing passwords, Django will use the first hasher in PASSWORD_HASHERS. To store new passwords with a different algorithm, put your preferred algorithm first in PASSWORD_HASHERS.

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


For verifying passwords, Django will find the hasher in the list that matches the algorithm name in the stored password. If a stored password names an algorithm not found in PASSWORD_HASHERS, trying to verify it will raise ValueError.


All references are taken from Django official doc 


Author:

Mahfujul Hasan
Software Engineer

linkedIn: https://www.linkedin.com/in/shojibhasan/ 

Labels:

Comments

Post a Comment

Popular posts from this blog

Django pk vs id

 Django pk VS id If you don’t specify primary_key=True for any fields in your model, Django will automatically add an IntegerField to hold the primary key, so you don’t need to set primary_key=True on any of your fields unless you want to override the default primary-key behavior. The primary key field is read-only. If you change the value of the primary key on an existing object and then save it, a new object will be created alongside the old one Example: class UserProfile ( models . Model ): name = models . CharField ( max_length = 500 ) email = models . EmailField ( primary_key = True ) def __str__ ( self ): return self . name suppose we have this model. In this model we have make email field as primary key. now django default primary key id field will be gone. It'll remove from database. we can not query as   UserProfile.objects.get(id=1) after make email as primary key this query will throw an error.  Now we have to use pk  Us...
Post a Comment
Read more

WSGI vs ASGI: What Every Django Developer Should Know !

  If you've been developing with Django, you've probably come across WSGI (Web Server Gateway Interface), the trusted friend of all traditional, synchronous web apps. But in this fast-moving, real-time world, you may have also heard about its dynamic, asynchronous cousin ASGI (Asynchronous Server Gateway Interface). WSGI (Web Server Gateway Interface): 1. The OG (original) Django interface, designed for synchronous HTTP requests. 2. Perfect for blogs, CMS, e-commerce, and standard web apps. 3. Uses servers like Gunicorn or uWSGI. 4. Limited to handling one request at a time. ASGI (Asynchronous Server Gateway Interface): 1. The modern, scalable interface designed for asynchronous web apps. 2. Ideal for handling WebSockets, HTTP/2, and real-time features like chat apps. 3. Built for high concurrency; uses Uvicorn, Daphne, or similar ASGI servers. 4. Allows you to leverage Python’s async and await for non-blocking code. When to Choose What: WSGI: Traditional apps where synchronou...
Post a Comment
Read more

Importance JWT and How Do JWTs Work in Django

Importance of JWT JWT (JSON Web Token) is a form of transmitting a JSON object as information between parties. Let's learn more about what JWTs are and how they work. JWTs are important for two main reasons: 1. Authorization 2. Information exchange JSON Web Token comprises 3 strings separated by “.” as follows where each part is encoded with base64url encoding : “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjp7ImlkIjoiNTlhZDFmZTI0MDVkNzk0YTFkYWQ2YmFkIiwiZGlzcGxheV9uYW1lIjoiQWRtaW4iLCJyb2xlX3R5cGUiOiJhZG1pbiJ9LCJpZCI6IlwiNTliYmJjODc0MDVkNzk0NjYwNGEzZjUyXCIiLCJlbWFpbCI6Imp5b3RpZ2F1dGFtMTA4QGdtYWlsLmNvbSJ9.oGA-goFi7ee6DdKn0Z4sctomaY6Ki0mfuJfxT4OK9WA” 1. Header 2. Payload 3. Signature Header: The header contains:      t ype: the specification that the token is a JWT      algorithm: the signing algorithm used to sign said token Algorithms that are used to sign include RSA, HMAC, or SHA256. The signatures for the tokens serve two purposes – integrity ...
Post a Comment
Read more