Pgcrypto avast!: A case-study in Django's password hashers
Drew is an seasoned technology leader. As Sr. Director of Technology at Celerity, he is currently focused on delivering multi-platform digital experiences in support of Celerity's user-focused design, digital strategy, engineering and architecture to clients.
He is the co-founder of Zoombit LLC which offers a cloud-based software QA platform and related quality testing services.
With a background in technology architecture, web engineering, cloud computing, search, and business development, Drew has worked on leading B2C and B2B projects across many industries and platforms.
His experience also includes analytics, quality assurance, SEO, CMS, and content delivery, including a focus on digital media and technical systems integration.
Drew resides in Cabin John, Maryland with his wife and two daughters.
This talk outlines what happened when I needed to migrate hundreds of thousands of end user logins from a legacy application to a Django application for a client (National Geographic). The primary challenge was that each user's password was originally created with the Postgres pgcrypto.crypt() function and only the one-way hash is stored, which is unusable by Django which it's own algorithms for hashing and storing passwords.
- We can't decrypt the hashed passwords for the migration.
- We can try to crack them... :‑/
- Oh, and this all needs to be completely transparent to the end user.
How to seamlessly migrate these users into Django? We will wander through the wonderful world of pgcrypto, Python password hashing, brute force attacks, and Django's authentication and password hashing internals. We will arrive at a successful solution (or will we?) and the Django package I whipped up and open sourced to handle this.
- 50 min
- PGConf US 2017 [PgConf.US]
- Use Cases