Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase the minimum number of characters in passwords from 8 to 12 #674

Closed
filipblnt opened this issue Jun 2, 2022 · 8 comments
Closed
Labels
suggestion An improvement of existing features/workflows type: enhancement Improve quality of an existing feature

Comments

@filipblnt
Copy link
Member

8 character passwords are not considered secure anymore. 12 should be the minimum.

@filipblnt filipblnt added type: enhancement Improve quality of an existing feature suggestion An improvement of existing features/workflows labels Jun 2, 2022
@m4rk055
Copy link
Member

m4rk055 commented Jun 3, 2022

8 character passwords are not considered secure anymore

Can you link a source?

I'm against increasing the limit. We already require a capital letter and a number. We also use a slow hashing function, which makes bruteforcing very demanding.
12 characters seems a lot since people are used to reusing their short password, and there is no way to reset the forgotten password currently.

Would like to hear opinions from others.

@milstan
Copy link
Member

milstan commented Jun 3, 2022

I am also horrified with the prospect of having to remember a 12 character password. I would have to write it down :)

@filipblnt
Copy link
Member Author

filipblnt commented Jun 6, 2022

Mainly from a few blog posts about passwords and entropy here and here (they are quite old btw but still relevant I think), arguing that it is preferred to have long passphrases than short complex passwords, which seems like an idea that is gaining more and more traction. Quick search on the subject also gives a couple of sources like this, this and this, and there are more.

I think 8+ characters is awful from the user perspective, but I think we should not make a compromise. Passwords are important part of the system here, if we allow weak password we are allowing users to operate in the context of weak security. I think that this fact is not obvious to users, and even if it were most of them would make a compromise with shorter passwords. I am a strong proponent of the liberty-responsibility idea, but given the nature of blindnet I think we should put some restrictions. I believe password managers are a good option for user friendly password management, and if there is no good user friendly password manager we should make one.

@Clementinev
Copy link
Contributor

We could also add a mnemonic tip on the right panel message when user is in the password field when creating an account. Like for example the sentence trick which is approchable and easy to explain/give an example in few lines of text.
I think having to remember 12 characters seems frightening for the user but in the end having to remember 8 or 12 characters is not very different : in any way you use a password manager (or you write it down) or a mnemonic technique to remember it. So we can help user by giving them tips about the tools to remember it.
Users might be annoyed but they will feel more secure :) (cf our study) and I guess 12 will eventually become the norm

@milstan
Copy link
Member

milstan commented Jun 7, 2022

Well, from the standpoint of complex vs. long, anyone with a computer science degree knows that long is preferable. Forcing complex passwords is simply wrong.

However, stupidity is a widespread desease, causing mnay regulations to mandate this (absolutely wrong) practice. See different regulations here.

NIST recommended the wrong practice for years, however they repented and made a new recommendation in 2017 favoring lenght and recommending the absence of complexity criteria.

As a result, a System can chose to either comply with SOC 2 (8+ chars, lowercase+uppercase, number, symbol) or with the NIST recommendation. This is horrible.

IMHO, blindnet SHOULD not tell people what to do here. Forcing long passwords to clients who may also feel obliged (for SOC2) to use complex passwords, would lead to users being forced to specify a complex and long password which can't be memorized. We can't do that.

So, my opinion has always been to impose nothing and advocate for sanity. I do admit that there are times of global crazyness when advocating for sanity might be challenging, but I think this is what one should always do. This means offering an objective metric of password strenght, and even offering a tool that generates recommendations, hints for the user on how to best choose a passord. I porposed this ideas long ago:

I like the idea from @Clementinev , that can be used in a pedagogic way. I think we can (if such system does not exist) make (and if it exists, extend it) a module for genrating password streght evaluations and hints for end-user on how to acheive a better password. We can strongly recommend our clients to use this module.

However I think our clients, operating uder different regulations that might mandate particular password rules, MUST be able to define their own Password Strenght policy.

To summarize:

  • I am in favour of:
    • Having an objective measure of privacy strenght, such as enthropy
    • Offer client Systems an easy way to evaluate such a measure, and generate hints to teach users to make stronger passwords
    • Allowing client Systems to define and implement their own password strenght policy
  • I am not in favour of:
    • Constrains at the level of our solution, that would apply to every client System (this includes even the constrains that are already in place in our solution)

@milstan
Copy link
Member

milstan commented Jun 8, 2022

I propose to reach a decision on this and record it in Design Principles. See PR #685

@filipblnt
Copy link
Member Author

(this includes even the constrains that are already in place in our solution)

I think we should either impose restrictions for objectively secure passwords or remove all restrictions with an addition of educational guidance. Definitely not keeping restrictions as they are now. So I agree with this statement and the new proposal in general.

@milstan
Copy link
Member

milstan commented Jun 8, 2022

OK, let us finalise this in the PR. Could you and @m4rk055 then, please, follow this guideline?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion An improvement of existing features/workflows type: enhancement Improve quality of an existing feature
Projects
None yet
Development

No branches or pull requests

4 participants