Hacker News new | ask | show | jobs
by ygjb 4336 days ago
Sha256+salt. See https://github.com/mozilla/kuma

We are still working on the rest.

2 comments

Why did you decide to use sha256 instead of a kdf like bcrypt or pbkdf2? I'm not attacking you, genuinely curious.
To provide a bit more context, in early 2011 we made a conscious decision to move towards the password storage methods described here : https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

While we were moving in that direction (upgrading apps, etc) we also launched Persona (BrowserID at the time). Some apps opted to switch to Persona, others opted to upgrade password storage mechanisms.

That's an interesting document.

It mainly contains assertions for what one should do. Do you know if there's an explanation for the rationale anywhere? For example _"Passwords must be 8 characters or greater"_ or _"Privileged accounts - Password for privileged accounts should be rotated every: 90 to 120 days"_.

Not on hand, those decisions were made years ago, and done in email discussions and in person meetings.

That said, the password length requirements were driven by the cost of performing effective brute force attacks against properly hashed and salted values at the time we set that length.

Privileged passwords was basically a stop gap measure to ensure that users were refreshing passwords regularly. The correct solution is to deploy multi-factor authentication.

It's what django uses, and this site uses django.
Django 1.3 or lower. Django uses PBKDF2 [1] since 1.4 (March 23, 2012) [2].

[1] https://docs.djangoproject.com/en/1.5/topics/auth/passwords/...

[2] https://docs.djangoproject.com/en/dev/releases/1.4/

MDN was on Django 1.2 for a while, albeit with monkeypatched password hashing (since Django at the time was still defaulting to SHA1, I believe). With the switch to Persona, it no longer matters -- for a new account -- what hasher is used, since Persona doesn't involve storing a password.
Not to mention it's always been easy to implement even when it wasn't bundled by default.

There is utterly no excuse for storing passwords with anything that's not PBKDF2, bcrypt, or scrypt starting in 2009.

Right, they switched over to Persona, which is far better. Unfortunately the old hashes were still left in the DB.
To be clear, the only old hashes were those from folks who haven't used persona to log in.
also the feature was built a long time ago.

current standards for sites not using persona are here: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

As the number of logins per core increases the login latency with these functions increases fairly quickly.
Please try also to improve the page load time by using a cache, faster hardware, etc.