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

Prevent common passwords? #211

Open
lucasjkr opened this issue Apr 4, 2018 · 5 comments
Open

Prevent common passwords? #211

lucasjkr opened this issue Apr 4, 2018 · 5 comments

Comments

@lucasjkr
Copy link
Contributor

lucasjkr commented Apr 4, 2018

https://www.theregister.co.uk/2018/04/03/magento_brute_force_attack/

MY read of the article is that there weren't default passwords that were used, just that Admins used easy to guess passwords.

How would you feel about a library that adds rules for passwords (probably just on the admin side, you wouldn't want to make it too difficult for customers to make accounts, especially if you're using a 3rd party gateway for payments).

Simple rules like:

Password can't be the email address

Password can't be in a text file of predefined passwords for this, there's tons of lists of the most common passwords found in various database dumps...

@arnisjuraga
Copy link
Contributor

arnisjuraga commented Apr 4, 2018

Thumbs up! You still would like to have "allow weak passwords" setting either globally or for admin users, as Wordpress does that (You must "click and accept" usage of weak password).

This goes well with GDPR guidlines, because there are no excuses for weak data protection.

Some reading:

https://security.stackexchange.com/questions/116780/how-to-create-dictionary-to-prevent-weak-passwords
https://security.stackexchange.com/questions/32222/are-password-complexity-rules-counterproductive

@lucasjkr
Copy link
Contributor Author

lucasjkr commented Apr 4, 2018

Fantastic!

Yes, I hate default complexity rules that force you to make a password you can't remember.

What's more secure from a brute force angle:

qWe190?t

or

This is my password and it only works for me

But more my initial thought is just a text file that can get populated with various password dumps, so if someone tries to use it says "Sorry, you're trying to use a really common password"

https://www.geeknoob.com/1000-most-common-passwords.html

That's only one list, there's lists of like 1,000 and 10,000.

Obviously, not any dictionary words... Of course, I only have US dictionary!

It'll be a work in progress...

We could set it to only be active if the environment is prod or production. But beyond that, I would disagree with letting the admin override it. What good is trying to make them adhere to better practices if all it takes is a checkbox to override? :)

@andrejuseu
Copy link

First thing: Client will drop like flies in the rain, if there will be password checker.

I don't have time to think about secure password, I need my products delivered ASAP...

Second thing: Better option create passwords for them, send them to e-mail and let them buy products, as many one page checkout modules do.

Stop thinking like developers in client side things, I agree, weak password are bad, but it's clients responsibility to protect his data, shop can make only simple checkups like, if it's same IP address, if not - send email with extra code (2-way auth, but with emails).

@arnisjuraga
Copy link
Contributor

but it's clients responsibility to protect his data,

It's not so simple. IF customer understand risks, then it's ok. But 99% of them are just users and will blame You for anything, as soon as there are possibility.

I agree on simplicity - you should and must make purchase process as simple as possible, but You shouldn't ignore security risks.

Data protection is not only developers concern. In Europe it's becoming even more regulated with GDPR. Yes, agree, it adds more bureaucracy then security, but GDPR introduces huge penalties for non-compliance.

Anyway - data and password security is not only user concern. :)

@lucasjkr
Copy link
Contributor Author

lucasjkr commented Apr 7, 2018

Point was, if we're not storing payment card information directly in the DB (which would be major issue here in the US), then the ramification of customer using a weak password isn't horrible.

The biggest risk they face is re-using passwords between sites. We can't stop that.

We're storing the password in the DB using a strong hash, so that's good too.

How many more rules do you want...

minimum password length? yes.

Prevent stupid passwords? (we can do this, and I think we can ENFORCE it for the admin accounts).

But, you tell me, in Europe, is there an obligation on the store owner/site operator to prevent the customer from choosing password or 12345678 as their passwords?

Here's the top 100 passwords from Ashley Maddison:

https://arstechnica.com/information-technology/2015/09/new-stats-show-ashley-madison-passwords-are-just-as-weak-as-all-the-rest/

Question is, how much friction is acceptable to put on customers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants