Webfrontend #315

Set password policy

Added by Alexander Blum over 3 years ago. Updated about 1 year ago.

Status:NeuStart date:
Priority:NiedrigDue date:
Assignee:Meik Michalke% Done:

0%

Category:-Estimated time:1.00 h
Target version:Repertoire 2) Testing phase II

Description

  • Length: 10
  • Blacklist

Related issues

Related to collecting_society - Konzept #271: Password constraints? Erledigt

History

#1 Updated by Alexander Blum over 3 years ago

#2 Updated by Alexander Blum over 2 years ago

  • Assignee set to Thomas Mielke

sounds like something you could do during the first cup of tea in the morning :)

#3 Updated by Thomas Mielke over 2 years ago

currently

validator = colander.Length(min=8)

is in effect for passwords. You want me to raise this to 10?

What kind of blacklist do you have in mind?

#4 Updated by Thomas Mielke over 2 years ago

  • Assignee changed from Thomas Mielke to Alexander Blum

#5 Updated by Thomas Mielke almost 2 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.

#6 Updated by Thomas Mielke almost 2 years ago

  • Assignee changed from Alexander Blum to Meik Michalke

#7 Updated by Thomas Mielke almost 2 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."

Hypothesis:

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 1 year ago

Using bloom filter on Troy Hunts blacklist would reduce the needed storage from 10 to 1 GB:

https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2724

#9 Updated by Meik Michalke over 1 year ago

i think of two risk factors here:

  1. an attack (brute force) on the login page directly
  2. 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

#10 Updated by Alexander Blum about 1 year ago

  • Target version changed from 2) Testing phase II to Repertoire 2) Testing phase II

#11 Updated by Alexander Blum about 1 year ago

  • Project changed from repertoire to collecting_society

Also available in: Atom PDF