duffn / dumb-password-rules Goto Github PK

don't have a screenshot ATM, but as of yesterday, requirement is 8-16 characters

Ok this isn't an issue but I'm too lazy to do a pull request. And I have a question - can I create a new section for bad username rules? Seriously Hargreaves-Lansdown:

They have the same rule for their passwords, unsurprisingly. Ugh.

See new password rules in attached image

That would be neat.

Health Insurance

https://www.bluecrossma.com/

8-16 Characters
No Special Characters or Spaces

Some images may have to be cropped but many could be resized using html. This would make it a lot easier for mobile viewers.

<img src="url" alt="alt text" width="whatever" height="whatever">

IHG Rewards accounts are protected with a four digit PIN.

https://www.ihg.com/rewardsclub/us/en/join/register

I am thankful that so many people have been willing to create this list.

Thank you!

We now have an ever-growing list of those that have it wrong.
And it appears from this list that most sites have it wrong.

Here's a challenge:
Tell us your preferred password policy that:

• balances usability with security, and
• supports popular password managers and generators, and
• will work at least on popular desktop and mobile browsers and in mobile apps.

Not kidding! Come up with a "good" password policy - so at least when one of these sites fixes their password policy, you can kindly and unarguably remove them from the shame list.

You will be doing the world a great service! Then at least if everyone adopts your policy, everyone will have better passwords, and people can use passwords that follow a pattern even though not the same since everyone reading this knows you SHOULD (RFC 2119) use a different password everywhere.

Once you come up with that, comb through your list again and see if any site is already compliant.

Thank you - sincerely - thank you!

I’ve made the dumb-password-rules organization as it seems a few people are willing to work on the repository and this may be a better way to handle collaborators. I will transfer ownership to the org and add @nitrocode and @dawnerd as members to assist in the next phase of this project (#114).

The OVH 2FA example is using a numerical input field <input type="number"/> which automatically causes some (but not all) browsers to include the lamented increment/decrement buttons.

2FA algorithms that use numbers are common (standardized in RFC 6238) and it makes sense to use type="number" in these cases (for example, this will show a numerical keyboard on phones instead of a QWERTY keyboard).

So OVH is doing 2FA exactly right and should be removed from the list.

Coventry Building Society in the UK, has to be between 6 and 10 characters, can't contain any punctuation and you have to give characters from it on the phone to confirm identity!

Your password must be between 6 and 10 characters long and must not use spaces, commas or any other punctuation.

Appologies, not able to create a PR.

I don't think they advertise it anywhere, but you can try it out if you don't believe me.

Amazing, thank you to be a voice of my frustrations.

It will be so so cool, if u roughly ranked them also based on alexa ranking....

20 max and unclear special character rule.

The US IRS website has some dumb rules.

Here's some more insight (speculation, really) into Fidelity's restrictions. Fidelity accepts passwords in their automated telephone system. The password is mapped to the alpha-numeric mapping on the telephone keypad. In order to use the automated telephone system, a user with the password "password" would enter the number 72779673.

https://login.fidelity.com/ftgw/pages/fesco/html/FAQ.html

Facebook passwords do not have to be exactly correctly and can be slightly bypassed if you are close enough. This greatly reduces the entropy of passwords in certain cases (especially short ones).

It seems that:

• they are case insensitive almost all of the time
• adding an extra character to your password will still result in the password being accepted
• the username/email can be up to 3 characters off and still be accepted
• unknown other conditions

Facebook does employ a trust engine to allegedly require stricter checking from suspicious logins, but even if you set your VPN to say Malaysia / change your user-agent to something random it almost never goes off.

My understanding is this is designed to facilitate convenient/faster logins for users...

NOTE: anyone can take this issue and run with it, but if not I'll just put in a pull request in a few days

I noticed #70 for bad username rules. Would you be interested in websites with bad email rules too?

The one rule that annoys me with email is when they prevent you from signing up using the plus character. e.g. you can filter your email better in gmail if you add a + and then some string to your email like [email protected] will get sent to [email protected] but lots of websites will prevent the plus character.

If you're willing to extend it to bad emails, it may not be too much of a stretch to extend this as bad-form-rules or bad-login-rules to keep it more generic.

Maximum 16 characters.

Requires /\d{6}/ (6-digit numeric).

16 character maximum.

See screenshot below:

From https://cal.sap.com/

Sorry, short on time other wise I would have submitted a PR :-)

The website doesn't allow "some characters", actually it doesn't allow any special character, for security, logically.

PR coming soon.

20 character max, I think? The error message says follow the rules and there are no rules about a max number of characters.

The Paypal link points to https://secure.mindware.orientaltrading.com/web/login/createUser , which doesn't seem to be related to PayPal. 😕

The Internet is not only the web (even though there's a lot of web). I've got an offender they might warrant an entry, even though they're not a website: QuakeNet's IRC services.

Maximum of 10 characters. Bonus points: stored in plaintext!

• https://github.com/quakenet/newserv/blob/master/chanserv/chanserv.h#L63 (defines PASSLEN to 10)
• https://github.com/quakenet/newserv/blob/master/chanserv/chanserv.h#L586 (declares reguser.password as char password[PASSLEN+1])
• https://github.com/quakenet/newserv/blob/master/chanserv/chanservuser.c#L559-L566 (password check function is strncmp() => plaintext password)

Not a website though, should I add this? If not, how should I make the relevant screenshots?

Apple only allows 32 characters maximum for iCloud passwords. Leaving this issue here for anyone to take. If not I'll put in a PR in a couple of days.

sauce : https://twitter.com/natalieweiner/status/1034533245839450113?s=19

For example, if someone had an email [email protected], having any m in the password is not allowed

Password must be 16 characters or longer. Only applies when you change your password. Evidently, shorter passwords are equivalently secure, provided that you had the password before the new requirements were set up.

In the section for AOL, it says

Oh, and thanks for restricting one of the most common special characters!

However, the listed requirements don't appear to restrict any special characters? Rather, it encourages the use of special characters !@.# saying

Strong passwords include special characters (!@.#)

Limiting max length to 16 is still dumb but I'm not seeing any issues with special characters here.

Password must be between 8 and 12 characters.

Companies with names in the middle of the alphabet get to hide in relative anonymity. If you convert this README to a markup language that supports a table of contents (e.g. reStructuredText or Org), their shame will be magnified.

Please see the below screenshot.

Also if you go to this link and then inspect the source code of the page (ctrl+f for the word "consecutive" and it should bring you to the right point) you can verify these requirements are still in force.

I cannot check it out, but i recall a maximum of 20 characters.
http://passrequirements.com/passwordrequirements/paypal

You can change your password to be anything (Excellent!) but when you try to log back in you're locked out. Seems to happen when a password is really long.

I have a 64 character password containing symbols and all the fun stuff generated through 1pass. On login: Sorry, a problem occurred during sign in. Please try again.

It looks like the new password, and the confirmation fields do not have the same password.

The new password has one more dot than the confirmation. I would try submitting matching new/confirmation password again and see if the error continues

https://www.paypal.com/webapps/mpp/security/secure-passwords

Delta recently reduced account security by implementing some pretty dumb password rules.

I'm not sure if they fixed it, but last time I entered a password generated by 1Password that was too long, it allowed me to change it, but when I tried to login it said that it was wrong.

Maybe worth it to verify it and update accordingly.

They only allow 6-15 characters with no special characters.

Yeah that message is uh not good. It's been like that for more-or-less 8 years, good time to tidy up.

This'll be modified in an update post-holiday, The password is invalid. Make sure it does not contain any of the following characters: { } | ~ [ ], here and in other places this message format appears. I'll pull request against this once change is public. Thanks for attention to detail.

AWS ruins the idea of Yubikeys for many users.

Almost all services allow multiple Yubikeys. One to use and one to say put in vault or a secure location for backup. Because AWS allows only one, you better not ever lose that thing or you're out of luck. AWS can restore access to your account I will say, but obviously such a process is slow and involves many checks.

NOTE: anyone is free to take this and create a PR. Please also mention that the "Password Policy" for the AWS IAM service is terrible! Only 6 chars minimum lol.

References:

• https://twofactorauth.org/ generated from https://github.com/2factorauth/twofactorauth
• https://www.dongleauth.info/ generated from https://github.com/Nitrokey/dongleauth

I think adding a small section with rules for good password policies would be a great resource. What do you think?

8-16 characters and some junky special character rule.

No reason to include Izly here. 6 number pin is common and used in many bank websites. If you want to include Izly you should then include all (well most) bank websites.

About the fact that it is not translated in French maybe you should first try to learn how to use a web browser :

About the fact that your account can be blocked after too many login failed attempts, that is the way every internet accounts work.