Sites with dumb password rules - <AUTHOR> https://github.com/dumb-password-rules/dumb-password-rules <comment><USER2> My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York.

I signed up for EZPass using a relatively "long" password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I'd had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn't use OAuth but I figured it would be OK. I input my username and password using my password manager but it didn't work. Pretty strange, as I was able to log in to the "main" EZpass site using those same credentials. I tried logging in on the payment site again to no avail. Finally I realized that my password was being truncated by the password input field itself.

The solution was to inspect the page and change the maxlen attribute of the password field.

<comment><USER3> Mine is my workplace. They mandate changing the password every 3 months (so most people use post-its) and their password change utility accepts special characters for input but _mingles them_ when actually stores them (the backend uses AD for authentication, but the password change goes through a custom web form).

And of course then logging in doesn't work at all. It took me days to figure out what was going on.

I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).

<comment><USER4> Just use an ultra secure password schema such as September2019@$ . They obviously want you to use it considering that policy

<comment><USER5> I once tried Password1 scheme as a form of protestation for a client corp account I'd connect every 2 month or so but that had a 1 month rotation policy (so that I actually had to change my password every time I connected to them). It worked... Obviously I changed it to something else but regularly tried if still worked.

The big payout was when we had an on-site formation from a third party and the teacher needed to create a corp account. He miserably failed to validate various secure combinations against policy (like 16+ length 5 words xkdc style). Being the only consultant associated, I just yelled across the room full of in-house IT guys "Just try Password1 it's gonna make it!"

Obviously it worked out ¯\\_(ツ)_/¯

PS: Oh and nobody reported me for this "incident" I still don't know if it's out of shame, dumbness or because nobody wanted to actually get to work to change that policy.

<comment><USER6> Oh yeah. Yeeeears ago, I was contracting for a telecom provider, and as a contractor, the process for getting logins to all the stuff I needed access to was onerous in some cases, nonexistent in others. So the employee who was sponsoring my presence in the building just said I could share his login. "The password is Apr1999!, if you happen to be the first one to log in when it expires, just change it to May1999! and so on, alright?"

It satisfied the uppercase, lowercase, number, symbol, and non-reuse criteria perfectly, while having precisely zero security.

Come to find out, something like a dozen different contractors were all sharing this one guy's login. He was the only reason anything got done in the whole region. The "system", such as it was, worked, but it made a mockery of corporate IT.

A few months into the project, that employee gave his notice and quit. Went to work for the competitor across the street; we'd bump into each other at the diner and stuff. But they couldn't just turn off his login -- his manager understood that all the contractors were using it, so they just left it active, and whoever got the expiry prompt would dutifully update the password every month...

<comment><USER7> If you make the system secure but unusable, the users will find a way to make it usable but insecure.

<comment><USER8> But changing the password every month doesn't make it any more secure.

Passwords don't really have an expiration date if they are secure (as in long enough and not reused) in the first place.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Hi, I made this.

It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad.

It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.

So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.

<comment><USER10> > I've actually had one company reach out to me after making it on the list > and they made their password rules less dumb.

That's a huge win!

My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don't usually include "do not paste" in the listed requirements, so this doesn't really work with your screenshot approach. Ideas?

<comment><USER11> > My pet peeve is sites that block pasting

Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true).

Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.

<comment><USER12> so you can paste with the menu? Because I guess they would just catch the keyboard events?

<comment><USER13> I think they must block catching Ctrl+C/V/X, because those key combos work for me with that flag.

</comment></comment></comment></comment></comment><comment><USER14> There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for [https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html) and Sophos for their summary here [https://nakedsecurity.sophos.com/2016/08/18/nists-new- passwo...](https://nakedsecurity.sophos.com/2016/08/18/nists-new-password- rules-what-you-need-to-know/) (both of which make fine references when requested). As a side point, I'm now entirely unsurprised by the near-weekly big-corp breaches that get announced given the caliber of the compliance people we encounter.

<comment><USER15> Ironically, if you ever get an IT account on a NIST campus, they dont follow their own rules. It's "at least one capital letter, one digit and one symbol, and can't contain any English words of 3 letters or more" or similar. And they make you change it every 6 months. Pain in the neck.

</comment></comment><comment><USER16> I've been getting pretty annoyed by the "Security Questions" some sites have you setup.

A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.

<comment><USER17> The name of my childhood pet was "FVrE9msW9DLBAx". Makes for fun conversations on the phone.

<comment><USER18> It is better to pick names with actual words. An attacker can otherwise say that the answer is just a bunch of random characters, and there is a risk that a naïve customer support representative may accept it.

<comment><USER19> In order to deploy this successfully, the attacker would have to _know_ that you used a random string...how would they know this without having access to the string itself?

<comment><USER20> Not necessarily - they're given multiple "tries" so they can just pick "a bunch of random letters" as one of their first few choices in hopes that they guessed correctly.

</comment></comment></comment></comment></comment><comment><USER10> For a nice counterexample, check out login.gov, the unified authentication service that seems to be replacing individual approaches at many US government sites.

Their password requirements: "It must be at least 12 characters long and not be a commonly used password. That's it!" [1]

Oh, and login.gov allows pasting from a password manager.

[1]: [https://login.gov/help/creating-an-account/how-to-create- an-...](https://login.gov/help/creating-an-account/how-to-create-an-account/)

<comment><USER21> I don't like that at all. 12 chars is much too long. And what does "not be a commonly used password" mean?

<comment><USER22> It means it's shouldn't be on this list[1] for example, because it makes brute force guessing from a dictionary of common passwords easy.

\- Of all the password databases breached in 2016, "123456" made up 4% of them [1].

[1] [https://en.wikipedia.org/wiki/List_of_the_most_common_passwo...](https://en.wikipedia.org/wiki/List_of_the_most_common_passwords)

<comment><USER13> What a fascinating rabbit hole. Most of these obviously come from users not giving even a single fuck, but what about #9, "trustno1"? For some reason I suspect those guys are thinking they're really clever and no1 will ever guess that.

I'm also kind of surprised not to find some variation of "sesame" on here.

</comment></comment></comment></comment><comment><USER23> Chase Bank:

 _Must not include more than 2 identical characters (for example: 111 or aaa)

Must not include more than 2 consecutive characters (for example: 123 or abc)_

First, they apparently mean _repeating_ and not _identical_ characters.

But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords.

\</comment><comment>

Edit - Just simulated this for 10 million 12-character passwords randomly generated from the 90 characters Chase allows.

Turns out the repeating and consecutive rules would invalidate about 0.3% of purely random passwords.

A negligible reduction in entropy is certainly more than offset by preventing passwords like aBc123456789.

<comment><USER24> doesn't any rule decrease password entropy?

<comment><USER25> It's ironic that _allowing_ low-entropy passwords (for example, one-character) can actually increase the available entropy.

For example, if you set a minimum password length of six characters, an attacker doesn't even need to bother going through all of the 1 through 5 character combinations.

The flip side of the coin is that, obviously, _allowing_ low-entropy passwords will inevitably mean that some users will actually use them, which means that _their_ passwords actually have decreased entropy.

<comment><USER26> > can actually increase the available entropy

Well, the theoretical entropy, but not the empirical.

You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy" and makes things less secure (after all, your random password generator might just randomly have generated "12345678"), but in practice quite obviously it makes things more secure.

<comment><USER25> Agreed.

> Well, the theoretical entropy, but not the empirical.

Agreed.

There are profound implications of that statement of that statement when applied to other problems, because we mutually accept the theory as correct, but only _theoretically_ , when we know it has significant limitations in the real world.

> You could argue that ruling out "12345678" and "password" and "Password!" > reduces the "available entropy"

Obviously. And yet, equally obviously, removing those from the rounds because they're preemptively banned reduces the actual number of test hashes we have to run to brute force, and introducing a rule means that we can also eliminate huge swathes of potential keyspace.

So, the obvious is not necessarily so obvious after all. This gets more and more interesting the deeper the rabbit hole goes.

What if we have extremely random data -- perhaps even raw binary -- but it happens to have a sequence of three arbitrary integers, which is in violation of the rules, and therefore we can eliminate all such passwords from our test cases? That's a potentially huge chunk of entropy.

</comment></comment></comment></comment></comment><comment><USER27> Want to DDOS somebody? Try their password incorrectly three times.

Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.

<comment><USER28> I don't even think rate limiting after 3 mis-attempts makes sense. I regularly can't remember my password and might need 6 attempts. Nobody's going to guess your password after 300 attempts, so make the limit 30 and you're safe.

<comment><USER29> This is basically why I started using a password manager.

Screw up 1 too many times and you end up in a cycle where you never will remember your password and you'll try the last 3 or 4 you used, eventually locking yourself out again.

<comment><USER30> The primary reason you should use a password manager is that you should consider that password insecure at the place you use it. Any sysadmin at a company can grab your password and try it everywhere else you have accounts.

</comment></comment></comment></comment><comment><USER31> Honestly, I'm past caring about upper length limits, however stupid they are.

What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.

<comment><USER32> _Reasonable_ upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length.

Good security dictates a minimum length, and practical avoidance of your login form being a denial of service... well, that dictates a maximum length too. It can be quite long, but you generally should not allow bot makers to instruct your login handler to _actually_ hash the entire declaration of independence, repeatedly.

(Edit: I should clarify, by "reasonable" I'm talking like, 200 character or more reasonable. These sites with 20 character maximums make me cringe. Also the computational complexity can be mitigated in other ways, like sensible rate limiting.)

<comment><USER33> Why not have one round of hashing in the browser?

That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.

<comment><USER32> Wouldn't that just turn the attacker's problem into brute forcing the client- side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.

<comment><USER33> But the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack.

If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.

</comment></comment></comment></comment></comment><comment><USER34> > BMO Bank of Montreal

> Password must be exactly 6 characters long and no special character.

I had an account with these guys. Their security is just ridiculous. 6 _alphanumeric characters_ is all they'll accept! I mean, some of the entries on the list are bad, but this is a friggin _major national bank_ in Canada with a piss-poor password requirement.

This list needs to be segregated into different categories so we can laugh at the different ways sites are dumb.

EDIT: OK, they apparently updated their password rules to make them more sane (but didn't, like, tell any of their clients to go update their passwords?). Apparently their previous system was worse than I thought - it actually mapped your alphabetic password onto a number pad, so if you set the password AbcDEf then you could login with 111222. Guess this is what happens when you try to drag a telephone-banking system into the online banking era...

<comment><USER35> Tangerine still does this. I'm honestly surprised I don't hear stories about account compromises with them. Likely a ticking timebomb though.

</comment></comment><comment><USER36> United MileagePlus:

They ONLY offer multiple choice questions for the security questions!

Of course, for some questions none of the answers are correct (favourite artist etc). On the other hand it would be dumb to choose a correct answer that someone else could find out and then take over your account.

Some of the questions have as few as 12 valid answers - e.g. "in which month...". Also in the select box where you pick your answer the months are sorted in a nonsensical order.

I ended up picking questions with more possible answers and choosing a random answer and putting it into my password safe.

Infuriating!

<comment><USER37> Why does everyone (including the big tech companies) pretend that security questions are secure and should even be mandatory?

It's mind-boggling to me.

<comment><USER38> The other day I called my insurance to reset my online password and couldn't remember the answers to any of the security questions (I shop around every year so I never had to call them since I registered my account with them).

The person on the phone then just asked me a basic question about the policy, which I got right since I had the policy in front of me, and was then happy to change my password.

Fantastic... not.

<comment><USER39> I realise it's not ideal, but it's an open question West you'd like them to do instead? Do you want them to refuse you service completely, for example?

<comment><USER38> If they are happy to ignore my answers to the security questions and go with other questions instead then they should scrap the security questions altogether. Otherwise, yes, they should refuse me service because the point is to use the security questions to establish whether I am who I am claiming to be.

</comment></comment></comment></comment></comment><comment><USER40> The most annoying rule that Microsoft and Nintendo use everywhere: Your password cannot contain your email address

If you say it like that it may make sense, however the email address that I often use (especially if you have to use exotic text entering device) is firstname.lastname@example.com.

End result: I'm banned to use the letter a in my password... how smart! It drives me really crazy.

<comment><USER41> Does your email server automatically proxy email@example.com to you?

If it does, you can easily work around that limitation by signing up with firstname.lastname@example.com

I try to do that for any sites that let me, both for ease of indexing, and if my leaked email ever gets found in a data breach, I know which source it came from.

</comment></comment><comment><USER42> The most hilarious rules I've encountered were for a large, well known US hospital:

* Password must be EXACTLY 8 characters long

* Password must start with a letter

* You must use exactly 3/4 of the following: upper case, lower case, numbers, one of three special characters

* Password cannot "resemble" username or past password

<comment><USER43> Sounds like they were using z/OS or RACF [1] mainframe as a backend. Oof.

Unfortunately, it's not that uncommon. I've done security consulting work at a few major F500 companies that were using this and had those same password rules. At one of them, it got to the point where almost every security review meeting had to start with "yes yes we already know how bad the password are, don't bring it up, let's talk about something else".

1: [https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha100/pass.htm)

<comment><USER44> I suspect they want to be able to brute-force passwords if they really need to, in the event of a uncooperative or malicious employee, and these rules allow for that.

<comment><USER45> Nah, they tend to be systems whose original infrastructure was written pre- internet and had 3 or 4 (or more) decades of bolt-ons laid on top. Password security wasn't nearly as much of an issue, but now the same system that had been designed for employee use now is used by customers and is exposed to the web. Kind of like taking a lock on a diary meant to prevent casual perusal by a sibling and puting it on a bank vault because you put the diary in the vault.

</comment></comment></comment></comment><comment><USER46> The interesting thing about some of these is that you can instantly spot instances where they are storing the password in clear text.

For instance, case-insensitive passwords.

EDIT: I guess they could be converting to lowercase (or uppercase) every time before hashing, as multiple people pointed out. If that's the case though... fine, let's pick one of the first instances in that site (not mentioning by name).

Why can't it have spaces? Hashes don't care about this. Smells awfully like some string manipulation going on.

Why is it limited to 20 characters? Odds are that they are using VARCHAR(20) or variants. Hashes also don't care about this.

None of this is proof, but it smells really bad.

<comment><USER47> Not necessarily. They could run str.lower() on the password input before hashing and saving the hash. Then to verify the password, you just always run str.lower() on the input before calculating the hash.

<comment><USER48> I haven't checked lately, but I understood that Facebook passwords are case- insensitive.

<comment><USER29> They're not case insensitive, but they do allow for some casing mistakes.

Flipped case (caps lock) or first character case is wrong (mobile input field) were both allowed. Not sure about now. The article I found about it was from 2014.

<comment><USER45> That seems bad, like philosophically it feels like a password and only that exact password should work. But rationally I can't see too much of a problem with this.

</comment></comment></comment></comment></comment><comment><USER49> Most of these are dumb rules, but a few really makes you feel like something smelly is going on in the underlying code. Like the first one that specifically restrict %, my head started screaming "sql injection somewhere"

<comment><USER50> Or just an inability to deal with character encoding.

</comment></comment><comment><USER51> Where I work they use RSA 2fa keys. I have the app on my phone. You would receive a link in the work email, and by clicking it, it would add the token to the RSA app and give you the 2fa keys every 30 seconds.

After a few months, I bought a new phone so I had to get a new link (I thought). But even the IT guys are saying: Nah man that's too hard. Just use the same link you received months ago.

It worked. There is no time-out on those links!!!!. A link we receive in a plain-text email!!! Some of our inboxes are shared / have a PA attached.

But nooooo, this is not a security problem AT ALL... :-(

</comment><comment><USER52> Not surprised to see Sparkasse (German Bank) here, their password rules are horrible, they cap it with 5 chars which is insane.

I hope if someone gets hacked they will be able to sue the them because of their archaic security practices.

p.s. would like to use this opportunity to also complain about their non- english English dashboard, god I hate it.

<comment><USER53> If only they were the only ones! Consorsbank (BNP Paribas) also has a limit of 5 chars, and comdirect even has a limit of 5 decimal digits. The IT security incompetence in banks in .de is just insane.

<comment><USER54> > comdirect even has a limit of 5 decimal digits

Hm, sure? My comdirect account uses a 6 digits pin. Never tried to use more than that. But 6 were still horrible enough when looking at the fact, that SEPA transfers of up to 30 Euros don't require entry of a TAN. A feature, which can't be disabled. Hate comdirect for that move.

EDIT: feature, not option. :)

<comment><USER53> Oh, oops, yes, you are right, it's 6 digits ... not that that really makes a difference, though ;-) (And yes, I tried, you can't use longer or non-digits ...)

And, yes, the forced TAN-less transfers is why I am closing down my accounts. That is, they forcing thid disfeature on me, and their impertinent reaction when I rejected their bullshit justification (essentially they calling me rude and therefore refusing any further conversation because I pointed out that "many customers like this feature" is not a reason to force it and the risk that comes with it on customers who don't like it).

</comment></comment></comment></comment><comment><USER55> Westpac, one of the largest banks in Australia have a 6 letter password requirement. No more. No less. Requires at least one number and no symbols allowed.

Clearly not an IT focused organisation! The were also offered the .com version of their name for $1m AUD and turned it down which I found amazing for a $100bn organisation.

<comment><USER56> I remember this from when I was in Australia! I also remember that you couldn't type in your password, you had to use the website and click virtual keyboard keys.

I use westpac here in New Zealand and their website works really well, normal password, normal inputs, nice looking UI... but IIRC they are technically different companys.

</comment></comment><comment><USER57> My pet peeve: sites that require all-numeric PINs when logging in online. Numbers make sense when you're punching buttons on a phone or ATM, but elsewhere, why limit my entropy to 10 possible characters instead of at least 62?

And there's a special place in hell for sites that require entering numeric PINs by clicking on a "keypad" of randomly generated button locations.

</comment><comment><USER58> > Admiral: Restrict the inclusion of a % character.

I guess the password is being used in a query template? Seems like a very bad idea.

<comment><USER59> Or the password is used in sprintf() ... I know at least one organization where this happened. The % was being stripped from passwords for that reason.

</comment></comment><comment><USER60> TreasuryDirect, an official US government site for buying and selling Treasury securities, makes users enter their passwords via a clickable on-screen keyboard. The passwords are not case-sensitive either.

<comment><USER61> FYI, you can just open up the html inspector and delete the readonly = "readonly" on the input box and suddenly you can use a password manager to fill it in.

<comment><USER62> Which, I'm pretty sure is technically a felony.

</comment></comment></comment><comment><USER63> Strange to see a .gov.uk site on there ( [https://github.com/dumb-password- rules/dumb-password-rules#h...](https://github.com/dumb-password-rules/dumb- password-rules#her-majestys-revenue-customs-uk-tax) ) as they have excellent guidance on this [https://design- system.service.gov.uk/patterns/passwords/](https://design- system.service.gov.uk/patterns/passwords/)

<comment><USER56> Is this your first time encountering a government saying one thing then doing another? :D

</comment></comment><comment><USER64> You can always trust State Bank of India to pick the worst possible process and phrase. WTF is hacking characters ?

<comment><USER65> > WTF is hacking characters

Basically anything a scripting programming language might use as a comment or sigil. Putting 'we are probably calling exec() on your password' into writing though is a boneheaded move.

<comment><USER66> Maybe they run a password report and someone had <script>alert("lol");</script> as a password. Managment freaked out and demanded someone fix the hack.

<comment><USER25> Printing out people's unhashed passwords? Not cool.

<comment><USER67> How else will you make sure they're not entering their SSN? :)

</comment></comment></comment></comment></comment><comment><USER68> For a steady stream of these, check out [https://twitter.com/PWTooStrong](https://twitter.com/PWTooStrong)

</comment><comment><USER69> My fortune 100 company has the following internal account password rules:

-Must be 8 characters

-Must be all lowercase

-Must contain $ or !

-Must contain letters and numbers

I'm not joking.

</comment><comment><USER70> We need another repo for stupid 2FA rules. Looking at you United Airlines.

<comment><USER71> Add Chase to that list. They don't offer TOTP and are vulnerable to cellular account takeover attacks.

<comment><USER72> My credit union has the same issue (no TOTP, only options for second-factor are email and phone call, with no way to disallow one or the other).

<comment><USER73> I didn't even bother enabling online banking with my local bank because of this. None of the local banks have a damn clue so I just use them as if it's 1995; ATM and IRL. I only use them for cashing checks though so it's no big deal.

E-Trade has a decent security story though. 2FA w/hw token, and they refund all ATM fees on the checking account so it's decent for general banking in addition to trading.

</comment></comment></comment></comment><comment><USER74> Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be good for password security past experience has made me paranoid. Not all systems handle non-ASCII the same way, so when you change browsers or they upgrade their system your password might no longer work. Today Unicode is used a lot so it gets better, but it's still not universal. The worst I have seen is a system that silently removed all non-ASCII characters when entering passwords.

<comment><USER75> That might have been an excuse in 1999, but I'm not sure it's still a valid excuse in 2019. This is why you should use utf8.

<comment><USER76> I recently debugged through a case where this was a problem with non-ASCII usernames. Through an upgrade of an underlying docker image the default system encoding changed from UTF-8 to ISO-8859-1 and nobody noticed. This even passed QA since they always create new users in their test cases and the bug only occurred if you wanted to log in as a user with a non-ASCII character that was created with an old version of the service.

That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default.

Long story short, encoding problems can be tricky, even in 2019.

</comment></comment></comment><comment><USER77> The University of Notre Dame requires that your password be 16 characters long. But only if you are new or are changing your password. Evidently shorter passwords are just fine for the people who have been there for a while.

Of course, we have to use these passwords in quite a few circumstances where a password manager cannot be used (logging on to random terminals, etc.), and then there is the multiple random 2FA checks, in buildings that have no cell signal...

</comment><comment><USER78> Another 'dumb' feature with PayPal (at least a couple of years ago) is that it had a 30 character limit on password length. Except it won't tell you that when you create an account, instead it just truncates your password. So when you try to log in with your 32 character password (which it will happily let you enter) you'll just get a wrong password error.

</comment><comment><USER79> This is good work. It's amazing how the pressure has to come from outside to get any traction.

I just realized that I set up this Twitter account 10 years ago, this month: [https://twitter.com/passwordfail](https://twitter.com/passwordfail)

Most sites don't email passwords anymore, so I suppose that's something.

</comment><comment><USER80> It's also frustrating when they change password rules and invalidate existing passwords in the process.

Yesterday I had to go through an inconvenient password reset because my bank no longer allows spaces in passwords. The password input inconspicuously removes spaces after you type them. It took several failed attempts before I realized what was happening.

<comment><USER81> I've hit that, also. I finally gave up and did a password reset. In setting the new password I find the new rules precluded the password I was using. Apparently that was enforced by editing the input.

I've also set a password that wasn't accepted by the login box, it explicitly stated there was an invalid character.

</comment></comment><comment><USER82> I like the idea of such "shame list". The question is though, how would you prioritize and incentivize those websites to change?

My quick idea is that it would be good to have a way of reproducing those cases somehow; not sure how though, because registration is something that is difficult to automate, so we'd probably need some browser extension to do this research. Once we could automatically test (or semi-automatically, waiting for a user to verify) whether this is still an issue, we could create a website where one could sort by most popular / annoying / old flaws, maybe also arranged by communities so that changes would happen.

Either way, I appreciate kicking this off. It's definitely a good start. I just wish we could transition from this to actually changing this deliberately, as opposed to just shaming and hoping for organizations to eventually fix their things.

</comment><comment><USER83> I understand that you follow some misguided security guidelines that state that a password must contain special characters and have a length of at least X.

What I _don 't_ understand is why sites use a _maximum_ password length. They shouldn't save your password anyway, and only compare the hash, right?

<comment><USER84> Cost of calculating 10k character hash? IMO above 30 length serves no practical purpose.

<comment><USER83> To put this in perspective: The cost of calculating a 10k character hash is negligible compared to serving a modestly sized image.

Still, you have a point that allowing arbitrary sized passwords to denial-of- service attacks. Still, a more reasonable limit would be 100 or 256, for example.

<comment><USER85> and no way is 12 a good limit

</comment></comment></comment></comment><comment><USER45> I thought it was fairly well established in the tech community that something like a sentence you can easily remember is better than a weird sequence of 12-20 letters, special chars, etc. But I very, very rarely see any site ever mention or require it or anything. How come it hasn't taken hold?

<comment><USER86> I think it's established in the tech community that you use a password manager, then you don't have to care how the password looks like or how easy it is to remember.

<comment><USER87> Passphrases are still easier to transcribe between systems. Which, given password managers' brain-damagedness at archiving and migrating passwords, remains frustratingly necessary.

<comment><USER86> > Which, given password managers' brain-damagedness at archiving and migrating > passwords

What do you mean with that? I don't have a problem archiving passwords in 1Password. When I change it it's automatically stored in the entry as password history. If I retire a login because a site closed but I still want to keep my credentials / details I move it to an "Archive" vault in 1Password.

</comment></comment></comment></comment><comment><USER88> Hm there should be an example of a "right" password rule flow here

Many of these are so nitpicky that it loses credibility

"oh it doesnt let the user know the max character limit is 30 characters uwaaaah"

cases like these should be part of a checklist that shows this is a minor infractions instead of putting them all on the same level of shame

</comment><comment><USER89> This is slightly different but webex makes me change my password every 30 days... It's ridiculous...

<comment><USER90> Similarly misguided policy.

It makes sense to change credentials periodically, but the policy of 30 days for humans doesn't work because the humans aren't realistically going to remember new credentials every 30 days.

If you have Let's Encrypt, the default setup (Certbot) will change the key every time it renews, typically 60 days, but you aren't expected to remember the key it's just data for a machine to store somewhere, so there's no practical problem and it defuses some risks (e.g. bad guys get hold of old backups). So the idea of rotating credentials like this would make sense _if humans weren't expected to remember them_.

</comment></comment><comment><USER91> Passwords, on average, have around 40 bits of entropy (or 0 if they're in any existing list, and some lists are 500M strong) so don't us pass words.

Also, TLS is MITM-able (the CA system is one giant backdoor, CT doesn't prevent MITM attacks) so you're password and authenticated token can be captured and your account can be pwnd.

Don't use pass words. Use mnemonics to derive public/private keys and use authenticated encryption (see lib sodium) or separate signatures and encryption.

Some of my explorations here (work in progress)

[https://docs.google.com/presentation/d/1f2k6fsIkDmIS1WyJAT0l...](https://docs.google.com/presentation/d/1f2k6fsIkDmIS1WyJAT0lXQmDuHIPeo9GDKfP1FY2rVc/edit?usp=sharing)

<comment><USER90> These are ramblings by a Coiner. As is usual for a Coiner since you don't really understand what you're talking about we get pages of vaguely related stuff sort of thrown together in the hopes that it covers roughly whatever it is you're claiming this time.

Let's take the "insufficient serial entropy" as one very clear example. That was a Brown M&M and not an actual technical concern, but you haven't understood that at all and just linked it as part of a claim this is "Security Theater".

Several of your links supposedly about "HTTPS snooping by Governments, Employers and Hackers" aren't about HTTPS, or even TLS, or even the Web PKI, but instead unrelated "certificates" of one sort or another than you apparently didn't understand weren't the same thing. For example the Apple Insider article is about Apple's iPhone application signing.

And then your "solution" ends up relying on all the same infrastructure you've wasted slides decrying as subject to MITM, including both HTTPS itself and OS- specific code signing.

Get out of here with that Coiner nonsense.

</comment></comment><comment><USER92> From the GitHub issue about BMO:

      The original entry didn't even fully capture the stupidity of the BMO password system (which I recognize they have now fixed).

      The most egregious part was not that your password had to be only 6 characters. It was that whatever password you chose ended up getting mapped to where those characters were on a telephone keypad. So, for example if your password was passwo, you were also able to login with 727796 or rARsYo or anything else that mapped to the same characters.

      I really should have switched banks when I found this out.

That's so strange (and awful). I wonder how they discovered that this mapping was being done.

<comment><USER93> The horizontal scrolling makes the quoted part pretty hard to read. If it's still editable, please consider changing that to simple `> ` based quoting.

Edit: Link to the github issue comment mentioned - [https://github.com/dumb- password-rules/dumb-password-rules/i...](https://github.com/dumb-password- rules/dumb-password-rules/issues/133#issuecomment-528665304)

</comment></comment><comment> yoz-y Any French bank with a single exception: Only digits, maximum 6-8 characters. Can not copy paste or even type in the field, must use a stupid on screen keyboard with randomized sequence of buttons.

Allegedly this protects against key loggers.

</comment><comment><USER94> I once had to implement ridiculous password rules for the Intuit api. Rules that Intuit themselves didn't use.

My favorite was "Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries)." So I have to search every word that humanity has ever used??

\---

Letters [required 1]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z – AND

Numbers [optional 1]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 – OR

Symbols [optional 1]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ', ", ,, ., <, >, /, ?

Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries).

Verify password is not the same as, or a trivial variation of the username.

If Account ID is 'fred', then password cannot be 'fred' 'fred1' 1fred', 'fr3d', etc.

Password check should look for Account ID string in the password

Password system must support mixed case passwords (Password1 should yield a different result than password1)

Passwords will expire no later than one hundred twenty (120) consecutive days after issuance.

Products must accommodate Account ID lockout after 10 consecutive failed password login attempts.

The failed count (if currently under 10) should reset after a successful login

If the 10th consecutive failed attempt is reached, the Account must be locked out for a minimum of 24 hours

After a password expires, the user must select a new password

The password system must remember the previous 5 passwords for each user

The user may not select a new password that was one of the previous 5 passwords for that user

The user may not change their password more than 1 time per hour

\---

[https://developer.intuit.com/app/developer/qbo/docs/legal- ag...](https://developer.intuit.com/app/developer/qbo/docs/legal- agreements/password-policy-for-intuit-developer-services)

</comment><comment><USER95> I would include there ANY website that imposes a maximum limit on the password length ... And it's not like a reasonable 255 chars or something. I've seen limitations to 8 characters! Why would you do that ?

</comment><comment><USER96> If you want to have a good system of passwords, you have to let users put what they want? Not a big security risk for these? I understand that too many rules are stupid, but even if it is a minimum of characters and then freedom to choose the character composition that one wants is the best instead of forcing a rare combination.

The only thing I hate from passwords is lenght. Most of the websites don't allow me to do +40 char passwords. I generate everything with 1Password and I have to limit on most websites to under 20 characters.

<comment><USER97> I really hate it when a site will allow you create a password with more than 20 characters, but then silently truncates it on the server. I wish I could remember an example, but it slips my mind.

So if you ever find yourself having trouble logging in with your 1pwd auto- generated password, try again with the first 20 characters. You just might get in!

<comment><USER96> I never faced that, but that truncate would be silly: you kill all passwords and customers have to recover it and keeping creating new ones.

</comment></comment></comment><comment><USER98> This is great! Definitely therapeutic to be able to name-and-shame frustrating password experiences. Is the goal to actually get these sites to change their dumb rules?

If so, I wonder whether it's worth adding a (politely-worded) summary at the top of the page describing _why_ rules like these are dumb? Then the people responsible for these sites, most of whom are themselves probably not dumb but just mis- or uninformed, can learn from their mistakes.

</comment><comment><USER99> With Fidelity, to authenticate yourself when you call in on the phone, you enter your username and password on the keypad. (They've recently also introduced a "voiceprint" method which bypasses that though.) You use asterisk on the keypad for special characters. One hopes they've hashed your password for storage in both its original and DMTF compatible formats. This may or may not be related to their dumb password rules.

</comment><comment><USER72> The credit union I use has pretty standard password rules (that is: decent by bank standards, i.e. pretty abysmal), but what really takes the cake is that the "Forgot Password" mechanism is driven not by a button or link or what have you, but...

...a checkbox.

Worse, this checkbox is exactly where one would normally expect the "Remember me" checkbox, so if you check it out of habit, you'll end up getting shoved into the password reset flow instead.

</comment><comment><USER100> What bugs me more than anything are sites that refuse to accept the strong passwords generated by modern browsers.

Who does the usability testing on those sites?

</comment><comment><USER101> I wouldn't publicly shame companies that might be regulated by slowing moving policies. Anyone who collects payments (any start-up that wants to stay around for long) is required to follow some form of PCI which currently still has really bad rules.

You can disagree with the rules but if you don't want to get in trouble, you have to follow them until they fix them.

</comment><comment><USER6> See also, [https://plaintextoffenders.com/](https://plaintextoffenders.com/)

</comment><comment><USER102> Natwest has a really annoying password system where you have to enter certain characters of your password. LLoyd's Has another system where you can create a password you like, and then you have to create another second password that they ask you to take certain characters from (e.g. 1st, 3rd, 9th character), oh, and it's alphanumeric too.

<comment><USER103> Loads of places do that (both methods). What's wrong with that? It provides (some) protection against keyloggers and means you have to type in fewer characters.

</comment></comment><comment><USER104> fun fact: amex online banking wont let you use exclamation mark ! but allows question sign ? amex foreign exchange website does exactly the opposite. apple and amex is why my 1 password to rule them all routine got destroyed and now i just trust chrome to generate and remember passwords and rely on my Google account to carry them across devices

</comment><comment><USER105> It would be nice if there was a HTML standard for specifying password requirement data, like length ranges, valid/invalid characters, character type requirements(3 letters, 1 number, 1 special character), etc, so that password managers/generators could use it to always create a valid secure, valid password for you.

<comment><USER106> Useful idea, but I wouldn't it be exploitable by adversaries as well (eg. knowing those constraints would be helpful for generating dictionary attacks)?

<comment><USER107> No, because attackers can easily determine the constraints (assuming they are kept "secret") by signing up for an account on their own.

</comment></comment></comment><comment><USER108> I'm a proponent of only 1 simple rule: high min length. Most sites have min length of 8. Double that to 16-20. No max length, no other complicated restrictions regarding characters. This instantly takes care of brute-forcing as a reasonable possibility, and forces good pass _phrase_ discipline on the user.

<comment><USER109> > forces good passphrase discipline on the user.

I definitely don't think it does this. In fact it probably makes most people much more likely to use the same password on every site, since their passwords just became 3-4x harder to remember.

</comment></comment><comment><USER110> Practically all French banks which use a _fixed_ number of _digits_. Something insane like 6 digits is common. And of course they all insist on using a friggin' on-screen keyboard !

For some reason I feel that the upcoming European payment services directive is only going to make this worse.

</comment><comment><USER111> Amiami has a pretty dumb password system. It even tells you how passwords are "6 to 12 letters and numbers" on the login page.

[https://secure.amiami.com/top/member/asp/](https://secure.amiami.com/top/member/asp/)

</comment><comment><USER112> I encountered the MLB.tv one the other day. I think they are a no special characters site.

</comment><comment><USER113> Sites that go to lengths to block paste should burn. I use a password manager, and copying the pass manually feels so damn 1970s. Or I can try to diddle around in Developer Tools and try to unfoobar the paste.

<comment><USER114> unfoobaring the paste is usually what I do, in the end it might take longer, but at least I am beating the system.

</comment></comment><comment><USER115> Why is this even a thing? Is there any reason, historical or otherwise that limits password length? You just have to hash the password—then everything is the same length, right? Am I missing something?

<comment><USER85> well... unfortunately some sites don't hash. I remember that once I used the "forgot password" on one, and they emailed me the password. Not a new, random one. My actual password...

</comment></comment><comment><USER116> When I first created a Cingular account (before they bought and became AT&T), the maximum password length was four (4) characters, because the system had been adapted from one that used PIN codes.

</comment><comment><USER117> My current massive pita is Adobe Cloud. Why do I need to rotate my password every 6 months for a photo editing app that has no credit card information associated with it (corporate account).

<comment><USER67> "that's what the platform team gave us" :D

</comment></comment><comment><USER118> In other news, here's a list of password rules on various sites to save you haxxors the hassle.

Kidding, I hate silly password rules as much as anyone, and these places deserve the public shaming.

</comment><comment><USER73> I recently was forced to reset a password somewhere, I think it was AT&T prepaid/gophone, where the password rules required that the password _begin_ with a capital letter.

Brilliant.

</comment><comment><USER119> Add amazon to the list. They introduced two factor but they don't allow you to paste the one time code, you have to type it. Come on. Why???

</comment><comment><USER120> Can we have a similar list for sites that do not verify if the email adress is really owned by the user registering it?

</comment><comment><USER121> Would you allow ascii characters under 32? Or would you considere it a dumb rule to disallow them?

<comment><USER122> From a security perspective exclusively, it's completely pointless to disallow them.

From a usability perspective, if someone manages to accidentally enter some dodgy control codes, and then can't log in on other devices because they don't know how to enter their password, it may be problematic.

Personally I think if a user chooses to put control codes or emoji or the unicode symbol for 1/2 as a fraction in their password, they're entirely welcome to have that but they shouldn't be surprised that when they want to log in they have to enter the password with that in it.

Ultimately, it depends on the expense of the support request that arises when users screws up and needs to reset their password - if it's too expensive it may be worth excluding the really exotic characters.

</comment></comment><comment><USER123> Would love to have a chrome plugin that shows the requirements next to the site login.

</comment><comment><USER124> These rules would be perfect constraints for brute force attacks

</comment><comment><USER125> obligatory thread naming good open-source password entropy checkers. I'll start.

zxcvbn: [https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

</comment><comment><USER126> Dumb password is good because smart hackers can't get into the that unlogic mindset

</comment><comment><USER127> use an auth provider, like auth0

</comment><comment><USER104> 0</comment>


Ask HN: How do I improve marketing without being a domain expert? - <AUTHOR>

http://knottablenecklaces.com is my site.  I'm working with a company owner who distributes locally.
I've setup adwords and have been tweaking SEO over time.  Between the SEO improvements, the site being live for a few months and the adwords our sales have been slowly but steadily increasing.  I've tried contacting blogs and magazines that I think would be interested in this product but haven't received a response from anyone.  I've tried social media based giveaways but haven't reaped any benefits from it.
I know the normal answer here is "engage".  Start a blog, get into the social pieces, start talking to customers.  The problem is that I'm not knowledgable at all about jewelry and I don't use the product other than for a desk toy (I'm male).
My question is, what other marketing should I be looking into?
Past month stats:
415 visits. 350 uniques. 1276 pageviews. <comment><AUTHOR> Thank you HN, I may have an answer: [http://blog.imranghory.org/facebook-ads- the-cheapest-traffic...](http://blog.imranghory.org/facebook-ads-the-cheapest- traffic-youll-ever)

<comment><USER2> If traffic is the only thing that interests you, then it's fine. But if you are looking for a smaller Bounce Rate, a longer time spent on site, bigger sales, and so on, that is definitely not the answer.</comment></comment>


Show HN: BetterLeap – Interview Once, Apply Everywhere - <AUTHOR> https://betterleap.com <comment><AUTHOR> We've designed BetterLeap to simplify and enhance the most painful and complicated part of career development — job search. So whether you're just beginning your journey, or are actively looking to transition, I hope that you find your experience with BetterLeap to be refreshing.

Today we're launching One Interview, a tool that helps you unlock new opportunities with one comprehensive interview. Essentially, you can now interview once, apply everywhere.

Getting started is easy:

\- You schedule a time with us.

\- You go through an adaptive and personalized interview.

\- You get matched with companies that are ready to hire you.

One interview allows you to connect to many companies at once and, ultimately, to put your job search on autopilot.

We currently only support frontend, backend, and full-stack engineering roles but we're onboarding new roles regularly. So if you're looking for other roles, stay tuned for more updates soon.

We're excited to help you with your job search. In the meantime, we hope you and your loved ones are staying safe.

 _NOTE_ If you're a company that's hiring and growing your team, apply to join our one interview program.

<comment><USER2> So, let's say your super success at this and I interview with you and it doesn't go well. Does that mean I'm locked out of every job in town?

<comment><AUTHOR> Nope. You can easily refresh/retake the interview.</comment></comment></comment>