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

Implementing Advance Query Optimization in Django ORM

 Django's ORM makes database interactions seamless, allowing developers to write queries in Python without raw SQL. However, as applications scale, inefficient queries can slow down performance, leading to high latency and database load.  This guide explores advanced query optimization techniques in Django ORM to go beyond basic CRUD (Create, Read, Update, Delete) operations and improve efficiency.  1. Use QuerySet Caching to Avoid Repeated Queries Using cache reduces redundant queries for frequently accessed data. Caching helps reduce repeated database hits. 2. Avoid .count() on Large Datasets Using .count() on large tables can be expensive Inefficient way: Optimized way ( .exists() is Faster) 3. Use Indexes for Faster Lookups Indexes speed up queries on frequently filtered fields. Add db_index=True for frequently queried fields: 4. Optimize Bulk Inserts and Updated Performing operations on multiple records one by one is inefficient. Use bulk_create() for mass insert...
Post a Comment
Read more

Django Optimization Processes for Write Operation for Postgresql

When optimizing a Django project for large write operations, especially when dealing with PostgreSQL, there are several strategies you can employ to reduce the time it takes to perform these operations: 1. Bulk Inserts In django, we create objects using create()  . Asynchronous version is acreate() .It's a  convenience method for creating an object and saving it all in one step.  and  These are same and equivalent. The create() method is used to create and save a single object in the database. Example: Instead of inserting one row at a time, consider using Django's bulk_create() method to insert multiple rows in a single query. This reduces the overhead of multiple database round trips. Example:  The bulk_create() method is used to create and save multiple objects in the database in a single query. It accepts a list of model instances and inserts them into the database in a single batch operation, which significantly reduces the overhead compared to individ...
Post a Comment
Read more

Django: Request/Response Cycle

Django Request Life Cycle  A web application or a website revolves around the request-response cycle and Django applications are no exception to this. But it is not just a two step process. Our Django applications needs to go through various stages to return the end user some result. To understand the Django framework better we must understand how the requests are initiated and the end result is served to the end user. When setting up a new Django project, one of the first things you’ll do is wire up your URLconfs and set up some views. But what’s actually happening under the hood here? How does Django route traffic to the view, and what part do middlewares play in this cycle? Layers of Django Application Request Middlewares URL Router(URL Dispatcher) Views Context Processors Template Renderers Response Middlewares Whenever a request comes in first it goes to the web server (Ngnix /Apache) . The the request goes to django's WSGI (Web Server Gateway Interface) / ASGI  (Asynchr...
Post a Comment
Read more