Password hashing method using the crypt-sha512 algorithm, To be able to generate password compatible with the crypt-sha512 method avaiable in the standard crypt function since glib2.7 and used on modern linux distros. This provides compatibility with programs and systems that use the glibc crypt library for encrypting passwords (such as shadow passwords used by modern Linux distributions) while providing extra security than the regular crypt-sha1 mechanism (available in Django as CryptPasswordHasher)
To use it you just need to add something like this to your django settings file:
---
PASSWORD_HASHERS = [
'utils.hashers.CryptSHA512PasswordHasher',
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher',
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher',
]
---
You need to keep the standard hashers on the list to be able to convert existing passwords to the new method. The next time a user login after the modification the password will be converted automatically to first hasher on the list.
Thanks mmoreaux for his improvements!!
This is a simple logging [filter](https://docs.djangoproject.com/en/1.5/topics/logging/#topic-logging-parts-filters) to ensure that user-entered passwords aren't recorded in the log or emailed to admins as part of the request data if an error occurs during registration/login.
This is another fork of http://djangosnippets.org/snippets/2729/ that fixes the issue.
Unlike those other versions i give you instructions so it works for you, this is modified a little.
Instructions:
If you want to import the passwords from drupal you need to prepend to each of them the word drupal so it looks like this:
drupal$S$DQjyXl0F7gupCqleCuraCkQJTzC3qAourXB7LvpOHKx0YAfihiPC
Then add this snippet to someapp/hashers/DrupalPasswordHasher.py
And then in your settings add this:
PASSWORD_HASHERS = (
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'someapp.hashers.DrupalPasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher',
)
So, what did i modify
First i added the attribute algorithm to the class, django uses this word to identify wich hasher to use, so the passwords beggining with drupal should be verified with the hasher.algorithm == 'drupal'
Ok so know django knows to use our class, but now our passwords won't validate because we changed them by adding the word drupal, so what do we do? we modify the verify method to remove the word drupal before verification :P
Hope it helps
Completely based on [snippet 2729](http://djangosnippets.org/snippets/2729/) (see that snippet for useful comments!).
The above snippet did not work for me (something with MemoryError), so I looked at the Drula source code and reimplemented...
This BasePasswordHasher allows the easy migration of passwords from Drupal to Django 1.4. Drupal stores its passwords using a SHA512 hash, but with some iterations and postprocessing.
This snippet allows you to migrate the username and passwords over seamlessly- the only necessary change is truncating the first character of each password hash (since Django 1.4 stores each password as algorithm$hash).
Note that this snippet *requires* Django 1.4, but there is no option for that snippet in the list.
Provided as a github gist [here](https://gist.github.com/2344345).
Simple password validation for user registration - requires that password be 7 or more characters and contain both letters and numbers. Original validation with regex approach developed by kurtis. Optimized no-regex version based on code from watchedman ran as fast or significantly faster on all systems on which we tested it.
This functions encodes a password in the same format as django. You can set the auth_user.password column with the result of this function:
update `auth_user`.`password`
set `password` = django_password('secret')
where id = 1234;
At the [Internet Identity Workshop](http://iiw.idcommons.net/Iiw8) in May, 2009, I spoke to Alan Karp and Tyler Close of HP Labs about their research on authorization without identity. Here are my [Delicious links](http://delicious.com/sbwms/ZBAC) on the subject.
This led me to write code to generate a "web-key," the shared secret needed to implement the access control method discussed.
In his paper, Tyler Close recommends 70 bits for the shared secret, encoded as a 13-character Base32 string. I used 72 bits, so the secret is a 12-character, URL-safe Base64 string without padding characters.
I'm new to Python and Django, so I welcome refinements!
A python implementation of the old MySQL PASSWORD() function.
This is insecure. There is a reason MySQL changed this in version 4.1.
Use it only if you have to!
I've often found myself wanting to store passwords for other web services (e.g. maillist managers, IMAP accounts, IM accounts etc) for use by a web application, but have not wanted to hard-code them in `settings.py` or store them as plaintext in the database.
This uses the [pycrypto][] library to encrypt each bit of information using the concatenation of a salt value and the SECRET_KEY value from your `settings.py`, hopefully leading to a bit more security and flexibility.
[pycrypto]:http://www.dlitz.net/software/pycrypto/
You'll probably want to add some views to let people edit these things as I can't find a way to make the admin interface play nicely with it.
**Example usage:**
In [1]: p = Password(
name='IMAP account', slug='imap',
username='example', password='password',
host='imap.gmail.com'
)
In [2]: p.host
Out[2]: 'imap.gmail.com'
In [3]: p.e_host
Out[3]: '6wdyMDKYy8c=$YXw6t/Q9wI[...]'
In [4]: p.save()
Sometimes when a Django site's authentication backend goes down, a login will fail with a 500 error. This has happened to me when using an LDAP backend for authentication. A glitch with the settings, or ldap temporarily disappearing can make logins flake out for a short period of time.
That's fine, but when a 500 error occurs it e-mails detailed information about the error to the ADMINS. We like this behavior for most errors, but it is quite frustrating when it is a login form with a password as part of a POST. If it is one of us who gets our password e-mailed out, it's even more frustrating. It hits a mailing list first, and goes to the archives to be stored in plain text. It goes to several e-mail inboxes, some of which are not local inboxes.
I decided that enough was enough. Drop this middleware in, and it will change a "password" field in the POST to twenty asterisks. This was the default way to display other sensitive settings on the DEBUG page, so I figured I'd be consistant with that.
This snippet is distributed under the GPLv3 License http://www.gnu.org/licenses/gpl-3.0-standalone.html
An example of how to modify the admin user creation form to assign an unusable password to externally authenticated users when they are created.
This code is more intimate with the django.contrib.auth classes than I'd like, but it should be fairly straightforward to maintain should the relevant django.contrib.auth classes change.
DualPasswordForm is a simple form that contains two password fields and validation to ensure that the two passwords match. A minimum password length of 7 characters is imposed, but feel free to change that.