Set password policy
|Assignee:||Meik Michalke||% Done:|
|Category:||-||Estimated time:||1.00 h|
|Target version:||Repertoire 2) Testing phase II|
- Length: 10
#5 Updated by Thomas Mielke almost 3 years ago
- Subject changed from Set password constraints to Set password policy
- Target version changed from 4) Production phase I to 2) Testing phase II
I have preponed this to Testing II and like to aks Meik and Sarah for their expertise, so we can work out a password policy, possibly to extend it to more C3S services.
#7 Updated by Thomas Mielke almost 3 years ago
To cite Meik from #271: "generally, i think that relying on passwords as the only means to protect access to online accounts is a thing of the past. we should keep U2F in mind to be added in the mid term (but not right now).
that said, demanding a minimal length (i'd vote for 10 instead of 8) in combination with a check similar to e.g. "john the ripper" should do it for the moment. guess that could be implemented using a blacklist, if that particular blacklist is defined reasonably and updated on a regular basis."
If we use a blacklist and and keep it open source, we ironically lower overall entropy: A brute force attacker could simply wipe those passwords from his own dictionary and have better chance with this reduced set of often used passwords. So we have to keep the dictionary a secret, doing security by obfuscation.
#8 Updated by Thomas Mielke over 2 years ago
Using bloom filter on Troy Hunts blacklist would reduce the needed storage from 10 to 1 GB:
#9 Updated by Meik Michalke over 2 years ago
i think of two risk factors here:
- an attack (brute force) on the login page directly
- an attack on a password library that the attacker somehow got out of our servers
the first can be made next to impossible by running fail2ban (or a similar tool) on the webserver. it slows down any brute force attack significantly, so even if an attacker knows the dictionary of passwords he should have no reasonable chance to succeed. for this method to enhance security, passwords must be long enough to not counter measure the temporary IP banning.
for the second i assume that we're already salting and hashing passwords, which should again be a sufficient protection as long as the actual passwords are reasonable long and not easy to guess.
most of this will be rendered osolete with webauthn: https://webauthn.org