Hacker News new | past | comments | ask | show | jobs | submit login
I hate password rules (schneier.com)
564 points by CapitalistCartr 72 days ago | hide | past | favorite | 435 comments



A few years back, not too long ago, I started working on a new contract assignment at a medium size aerospace manufacturer.

I show up and check in with IT department. The system administrator shows me to my desk, and hands me a post it note with my password. Well pass phrase is more like it. It was something like “sliding down the tall building”.

I was quite impressed that they encouraged the use of long pass phrases instead of short cryptic passwords that are hard to remember (think “correct horse battery staple”). This place really is serious about security, I thought.

I thanked the system admin and causally said “I’ll be sure to change this to an equally secure pass phrase”.

“Oh no,” he said, “we don’t allow people to change their passwords here. You see, we need to be able to log into anyone’s computer if they go on vacation or are out of the office, so we keep an Excel worksheet with everyone’s username and password. So please don’t change your password.”

He turns and walks away, and I just sit there stunned, wondering if this was some kind of practical joke.

Sadly he was completely serious. I kept the password they gave me for the 3 months I was there, as I was asked to do, knowing that at any time someone could log in as me and do something illegal or unethical. It really did give me a bit of anxiety.


A few years back, on day 1 of my new job I was given root access to one of the development boxes.

So I ask: "Okay, how do I log in?"

The IT guy: "What do you mean, you just log in using your personal domain account and then sudo su -. You know what sudo is?" (followed by loud sigh)

Me: "You mean like production domain, same that we use for our desktop?"

IT guy: "Of course! What do you mean, what other domain would you like?"

Me: "Can I at least change my password to something else just for the dev environment? Can I log in with SSH key?"

IT guy: "No, no, no. Per our SECURITY policy, SSH keys are disabled and you have to use our domain login and password". (another sigh... of course)

Me: "Are you aware that when somebody has root access to the box they can do whatever they want including intercepting passwords of all users that log in to that box? In this case, every single developer that ever needs access to dev environment?"

IT guy: "That's not true. SSH is encrypted protocol and it is not possible to access passwords".

Me: after many tries to explain this to various people from IT, I gave up and set out to intercept all passwords of all IT employees. After I had passwords of almost everybody, I put them all in an excel and sent to IT for "verification".

There were a lot of angry people that day wanting me fired... fortunately they came to their senses.

Unfortunately, my development box access privileges were revoked.


I think even if you were fired, you'd have dodged not a bullet but a cannonball there.

Sometimes being the nice guy full of good faith doesn't pay. Literally


Nah, I worked there for a long time and I was sad when I needed to leave. I had best boss and best project ever and I learned and grew a lot.


That's good to hear! Although I would have been frustrated and made anxious by their security practice. Did they change their security practices after that 'event'? And did you manage to regain access to your development box?


I once decided to show the vulnerability of SMTP protocol by sending an email as a higher-up. (Too young, too naive, don't ask why I did that.) Created a massive firestorm. I did successfully convert them to use SPF and DKIM and showed everyone the need to never trust an email. Some even adopted PGP signatures after that.


I like to imagine you sent an email as a CEO saying “please read this ASAP” and then it links to a Rick Roll


> There you go, giving a fuck when it wasn't your turn to give a fuck.

>

> - Bunk


"The standard you walk past is the standard you accept."


>sudo su -

It's high time for this thing to die. sudo supports this natively since forever:

  $ sudo -i


Curious, whats the difference and why is sudo -i better? I was unaware of sudo -i (I might as well be a noob though), so I had a quick search to find out more and found this [0]

One question, if I may, could there be any situation (that you can think of, off the top of your head) where using sudo -i would be worse then "sudo su -"

[0] - https://www.maketecheasier.com/differences-between-su-sudo-s...


'sudo su -' uses root to run 'su -' to open a root login shell.

'sudo -i' opens a root login shell.


su is old fashioned but it works fine. I don't even have sudo installed on my PC.


Huh. TIL.

I usually just do `sudo zsh` :-)


Why


Wait, seriously? How would you do that? And why doesn't it work for ssh keys?

I was under the impression password auth worked very similarly to key auth, as in, the actual bytes of the password or private key are never sent over the wire.


No, password auth transfers the password and (usually) hands it to PAM on the server to verify - the server sees your password. Key auth happens in SSH and the private key never leaves your machine.

(If I remember correctly just putting SSHd in the highest debug level, which logs every byte received, did work to intercept passwords)


On the plus side, it also gave you plausible deniability it really was you if you wanted to do something illegal or unethical.


Like jeez, GP. Should’ve sold those aerospace secrets to China while you had the chance.


chaotic hysterical


Pro tip: When you're seeing something really unethical that could eventually rebound on you - write it down. Write down contemporaneously what happened and sign and date it. Much more reliable evidence.


Send it in an email too. "Hi IT guy and Boss, I'm concerned about blah, but understand people need access to everyone else's computer and account. Yada yada." Don't be difficult, but get an email out there with a time stamp on it and forward all that to your personal account if you can.


Any UPS store or FedEx should be able to notarize it, in the unlikely event there isn't a registered notary among your coworkers.


Bonus points for writing it digitally and using your favourite proper or janky method of timestamping - dates on paper are meaningless, even with a signature (which is also meaningless itself).

Emailing it to someone seems to be the go-to recommendation online, but you might not want to expose the information at the time. Some alternatives, in descending order of jank: a Google Doc, unlisted Pastebin, either of those but only post the hash and keep the file offline, a proper TSP timestamp - the latter is actually near-trivial these days with something like freeTSA.org.


The funnier thing about that story is that the passphrase they gave you is not necessarily secure in the first place if we're talking about a scenario where a hash is found. While length is a factor when brute forcing randomness, any words or phrases that commonly appear together in written text are likely to come up in various types of dictionaries that can be used in more sophisticated brute forcing algorithms.

"sliding down the" and "tall building" are two parts of that password that contain words very commonly found together.

It's not the worst password but it's better to introduce randomness.

One strategy to create strong passwords that you can remember is to pick 3 or 4 truly random words from the dictionary that have no logical connection to each other, and to "glue" them together with some numbers that you can remember. I've heard that phone numbers are 7 digits because people can remember up to 7 pieces of information. If that's true then most people should be able to remember a password in the form of: <word1><number1><word2><number2><word3><number3><word4>

It does start to break down when you have to remember multiple passwords. So using that format as the master password to a password manager and then letting your password manager generate truly random passwords for everything else is the way to go.


The nice thing with the lists of multiple randomized words is that there are so many more combinations possible. The numbers, which will be individual digits for most people, add relatively little here.

Using EFF's dice-ware page (https://www.eff.org/dice) as an example, the long word-list has 7776 entries, with a nicely random way to select them. Four of those words is already a sixteen-digit number in the combinations available. Even their short list of 1296 words would provide pretty reasonable odds. The key is to use something like the dice that takes away our own biases when selecting words.


Really the key is using words that aren't in a dictionary, or at least not the same dictionary. It's pretty trivial for a brute force attack to just take a list of English words and try them in a large number of combinations. But if you have some non-english words, as far as that attacker is concerned its random gibberish. Of course the attacker might use a few languages so just mixing say english and spanish won't do that much better, but if you got some navajo or some quenya you're likely immune to any attack that isn't specifically targeted at you. And it doesn't even have to be a foreign language, even many proper nouns won't show up in a dictionary. For a password like "PoggleExclaimsGeonosianBarahunde" or "Seanbeanfearsburzum-ishikrimpatul" it would take trillions of years to guess a password without very specific pop culture knowledge.


Here is a small back of the envelope calculation. Websters dictionary includes 470.000 words [0]. 52 lower and uppercase letters + 10 digits + ~20 special chars = 82 possibilities. There are are 82^20 = 1.89 * 10^38 possible combinations for passwords consisting of 20 random characters. Picking 7 random words from Websters dictionary has 470.000^7 = 5.07 * 10^39 possible combinations. I'd argue that remembering 7 words is easier for most people, than remembering 20 random characters.

[0]: https://www.merriam-webster.com/help/faq-how-many-english-wo...


Yeah, for a given level of entropy words are a better choice, but the fact is that dictionary attacks greatly reduce the efficacy of what could be an incredibly strong password if they can safely assume it is formed exclusively from concoctenated standard words. However if you break the validity of that assumption by using a word that's not on a list, then the dictionary attack must be combined with a brute force attack with the same string length. If we assume an average word length of 5 letters, that 7 word password jumps to 1.22x10^79 possible combinations if you randomly substitute one letter.


My work is also big on pass phrases but I kinda hate them. It's a lot of extra work to type it every time I unlock my PC. And more characters means there's more chance to make a typo meaning I have to do the whole thing again.

And the weird way my brain works I have no issue remembering "G6bH,vIz#amV" so I still do it like that :)

Also, if an attacker has a hash of my password the damage is already done anyway. They can do a pass-the-hash attack, they don't even need to brute force it for the plaintext. So there's no real benefit there. What matters is online guessing and that is severely limited in the amount of attempts.

I can't wait for passwordless though. I use only smart cards/yubikeys at home and love them.


> Also, if an attacker has a hash of my password the damage is already done anyway. They can do a pass-the-hash attack, they don't even need to brute force it for the plaintext. So there's no real benefit there.

A diceware password of 6 words has an incredible amount of entropy. How would you ever brute force its hash?

> What matters is online guessing and that is severely limited in the amount of attempts.

Belt and suspenders.


In pass-the-hash, the password doesn't matter. If you don't know the hash, it's equivalent to online brute-forcing a password of a fixed length, but since that length is usually more than the password itself, it's usually better breaking that. An NTML hash for example has >3× the entropy of a 6-word diceware password, but in an insane situation like 10-word diceware vs md5, brute-forcing the hash would be faster.


> They can do a pass-the-hash attack, they don't even need to brute force it for the plaintext.

Ok, but that's a very Windows-specific issue. I don't know of any other widely-deployed system vulnerable to pass-the-hash.


That's true but we're a Windows shop, sadly :)

I'm a bit appalled at the security of AD with PTH, Kerberoast etc. In some cases you can even continue to use a nabbed ticket after the compromised account has been locked! That should never be possible IMO.

I'd love to move on from AD personally. But you know... Legacy galore.


What's stopping you from using a random password like 'G6bH,vIz#amV'?


Well they wanted to set the minimum length at 16 characters, for one :)

But in the end they settled on 10 so it's ok. They even made it mandatory to have special chars and numbers if you have less than 16. So in the end it worked out fine for me but it did take some convincing (I was involved with the team that was making the choices).

Tbh even if you do have to brute-force, if you know the company is using passphrases, it tends to be similar in terms of difficulty as a complex shorter password to brute force it. Because you can do a combined dictionary attack. And it's more susceptible to targeted attacks e.g. gathering a person's interests on facebook.


Wow I know that password expiration is on its way out [1] but this is crazy.

[1] - https://www.sans.org/blog/time-for-password-expiration-to-di...


Makes you wonder if you could use a tool like GPT-3 to generate grammatically correct passphrases from randomly generated sets of words.

E.g. "correct battery horse staple" might become "Correct use of a battery supports the a horse in its staple diet".

Thereby keeping the same bits of randomness while making a memorable phrase.


It also gave you plausible deniability which would have stood up in any court.


Well, was the Excel spreadsheet accessible to everyone? If not, this model could work in some strange way - if someone needs access to your computer, they are provided the password, then it is changed and you and password custodian now have a password not known by everyone else.

One side effect of this is that if you know someone else has the password, you're probably very unlikely to do any personal business on that machine.


There has got to be a better way, namely, not an excel spreadsheet (maybe vault or LastPass) and not the individual employee's account (e.g. have an IT super user account).


I think OS miss the ability for an admin to log into a user context. I am very hardline defender of privacy and in principle I support privacy advocates already preparing my pyre for even suggesting that of course.

But if we are honest an admin can already access relevant data anyway and you do indeed need to use a user context to access certain settings of some applications. This is especially true for less digitally affine users.

There are workarounds (Windows->Run as...), but that is sometimes insufficient.

About an admin using your user account to start the nukes? That is mostly possible anyway in the usual corporate Windows configuration. He could just change your AD password and log in as you. I would recommend that approach anyway and then force the user to set a new password and informing him why you sabotaged his workstation would also be nice. Far more secure than having the holy grail Excel file.


The first place I worked was like this, with the exception of the long complicated passwords. We told people to call the helpdesk to reset their password and would save their password to an Excel sheet. This was improved slightly by rolling out a self-service password change tool that logged the passwords to a database.

One day someone that had legitimate access to the password list was fired/quit and the VP decided we needed to have everyone (~800 users, 700 remote) call the helpdesk to reset their password. All the helpdesk calls waiting for a password reset clogged the voice T1 (23 lines) for the office, preventing most calls in or out. Oops.

Thankfully when the company came in-scope for sarbanes-oxley the external consultant we hired to help with the audit said there was no way we could continue logging user passwords and stay compliant.


This level of negligence should be criminal.


The software industry is full of should-be-criminal forms of negligence.

Things are already horrendously bad. Basically every American's identity could stolen at this point. If any nation state or other actor decided to operationalize any of the big leaks -- eg OPM or EquiFax -- the ramifications would be catastrophic. Imagine millions of people losing their retirement accounts and all their savings. Even if you could correct everything -- and that's a big if -- the process might take years and the intervening panic would be deafening. The amount of anger might even elicit a hot response.

To say nothing of more serious vulnerabilities. We really dodged a bullet on the pipeline ransomware.

I'm morbidly curious how bad of a "Cyber 9/11" we'll need before software starts being taken seriously as an engineering field in which practitioners have professional responsibility.


I would assume that a few nation state actors have already hoovered up all that leaked information and have it implemented in a system that is ready to steal identities, drain accounts, and otherwise wreak havoc on a large scale. They are just waiting for the higher ups to pull the trigger if and when they decide to deploy it.


Yes. I'd be astounded if multiple such attacks aren't ready to deploy. At least 6? Maybe as many as 12. What it's waiting for is a desperate enough actor or a weak enough moment. Russia and China learned from Japan and ISIS et al learned from bin Laden -- divide, don't unite.

But eventually there will be a sufficiently naive actor and/or a sufficiently weak moment.

The tragedy, of course, is that all we have to do is address the totally and completely obvious problem. It wouldn't even be that hard. But we won't. Last 4 of SSN is still enough to transfer a SIM even with explicit direction otherwise, and transferring a SIM is still enough to drain a bank account even with explicit direction otherwise.


Prepare for failure. A good rule, but painful is: The more income tied to an account the greater the difficulty to move the income. I'm too tired to list best practices but for example: Set up canaries, daily emails from your account just for the peace of mind that your email is the primary communication for the account. Biggest assets should take time and multiple steps to transfer or cashout. Know your account managers and be able to contact them directly.


Hi, I hope this doesn't come across as me not respecting your tiredness but could you link or anything to best practices if you don't have the energy to write it out yourself?


Well, I will try. First, I was commenting on my interpretation of the parent comment. Identify theft, and protecting savings and retirement accounts.

Be inquisitive and aware. I think you have this covered by reading hacker news and having an interest in the subject. I've enjoyed reading Slashdot (while it was good) before switching to hacker news, but it's also been a vital ongoing education for me. Comments often having more value than the original article. Being knowledgeable of security risks and common exploits helps prevent falling victim to them.

https://hn.algolia.com/?q=identity+theft

https://www.newyorksecuritieslawyersblog.com/my-money-was-st... Good read on how someone lost their account.

Steps for securing accounts. Confirm that you are notified of email address changes. Confirm that you are notified of any transactions on the account. Setting up a canary if possible. I set up an email alert on a common event. So, I basically I get an email from the company daily, and this confirms that my email address has not been changed. If you are certain you will be contacted if your email address changes then this is not necessary as the email change notification acts as the warning. Have email and phone of account representative that you can contact if there is a problem with the account.

That should be all that is necessary. Now, the day comes, someone has changed your email address. Maybe they even did some transactions. Stay calm, stay professional. Contact your account representative and notify them of the problem. Be able to identify yourself, call from a phone number associated with the account (or previously associated). Be able to answer security questions. Account representative should be able to freeze the account and resolve any issues. If you're satisfied with the phone call, great. If you're in anyway nervous about the resolution, then create a paper trail, send a letter that documents the issue and your attempts to resolve it.

A quick disclaimer, I'm not an expert. Adjust anything to fit your own needs.


Would you mind clarifying what a canary is? I understand it is referencing the idea of a canary in a coal mine but what does that look like in this context? Other than having a separate account to which you transfer most of your funds so you can't get robbed at gunpoint and be forced to transfer someone your money I'm drawing a blank here - sorry.


A canary is a safeguard against dangers. In my example, my daily emails from my investment account is my canary. When I stop getting emails, I know there's a problem.

I cannot remember the details, but one of my favorite canarys was a website that had a paragraph that basically stated we have not been compromised in the past 24 hours. It had a timer that had to be rest daily or the paragraph whould disappear from the website.


I really like that term “Cyber 9/11”. Is that something you made up or is that a term people use describing a bad attack?


Thanks, but I can't take credit :) I think I first came across this term in a foreign affairs article, and from then on used it often in presentations to various brain-dead military officers who all seemed to have degrees in Biblical Studies from colleges whose boards are full of Domionionism types.

In any case, the term has been around for a while. Unfortunately, our officer corps is populated by weak-minded fools who have more allegiance for their quasi-Baptist cults and podcast hosts than their country. They all seemed to have a multi-year education in how to use Hebrew language factoids for isogesis, but had no god-damned clue what a "heap" was, and were effectively mid-level managers of "Cyber Operations"...

Our current state of affairs in the civilian sector isn't too surprising and I have infinitely more confidence in random banks and credit "borough" companies than I do in our military.

All of that to say: a cyber 9/11 attacking civilian infrastructure is a best-case scenario because that's where all the good people are. An actual 9/11 will probably attack the defense sector where all the incompetents work and will be way worse than actual 9/11. You have officers with theology degrees from shit-tier southern bible colleges to thank for it. After we're done bombing whatever rural town the hacker happened to live in, our next two steps should be professionalizing software engineering and writing history books about how christian fundamentalists destroyed the integrity of the US officer corps.


I didn’t realize there was so much religion in the military. Gun in one hand bible in the other is the dumbest thing I can think of. Do they actually think if heaven and god was real they would be invited? Ha! I would love to hear how a military man justifies going to war and then preaching the bible surely the two go against each other.


So you’re saying that is a gigantic target for China and Russia to go after lol. It would mean some change for the which might not be bad but that’s kinda like arguing for terrorism, which would be illegal and actually have enforcement behind it.


No, it's far too large and undivisive a target for China or Russia. They're both too smart for that. They fuck shit up in ways that are partisan and divisive.

This is more of an NK/non-state-actor "burn it all down" move.


if that were to happen it would be a "to big to fail" event. the gov would bail everyone out and mandate a reset to what ever it was believed to be before. bank accounts, retirement accounts etc would be reimbursed up to the FDIC limit. credit reports would be rolled back to the last known good value. it would probably fuck things up short term but long term it would lead to better security of consumer data


Completed agreed. But the short term fall-out would be incredible, and I think the backlash against tech unprofessionalism would be merciless.


Eh I think you went into hyperbolic assertations here. Might want to walk it back. It's bad but it's not as bad as you say.


Suppose NK or some non-state actor has access to EquiFax or OPM data. Or just a conglomeration of various other data leaks, some of which are probably still unknown or at least unannounced. Suppose that actor launched a plan with trivial lead-time and resources -- say, 1-3 years with 10-50 trusted primaries and however many in-the-dark "contractors".

Do you really think the result wouldn't be turmoil for at least weeks, if not months, and take a year+ to unwind? Serious question. If so: please explain.


The slow guy that still kept paper records would win this.


I don’t see why. I think it’s generally silly to think of your work computer/account as a place for anything private. Even if they won’t normally look at it, it’s all fair game if e.g. someone subpoenas them. My employer had a team which did a similar thing to the GP (had a spreadsheet with everyone’s password) in case someone was out and had some crucial file on their computer. And while they have since stopped doing that, it is because they improved processes such that it wasn’t needed and not because it became acceptable for the team to fail to carry out a large portion of their business activities or obligations because someone important was sick.

The problem is that the spreadsheet meant that exploiting one user meant exploiting the whole team but you can have this kind of privilege escalation in plenty of other ways. An easy way is to give people lots of permissions so that they can get their work done, or to just be bad at revoking permissions once they are no longer needed. Plenty of companies deliberately give people wide read permissions as a part of a culture of openness.


It's not about it being private - clearly the business can have root/admin/domainadmin/whatever access.

However your username and password identifies you. If user "johnsmith" does something, then that's because johnsmith has logged in. Now IT may have changed the password to allow them to log in as johnsmith (either following some odd policy, or a rogue IT worker), but that would be in the audit log.

If a company needs more than one person accessing an account for some reason, they should create a generic account (e.g. "z_reception" for a generic reception machine).


Yeah, it's the similar in the company i work for. Except that we have a mixed bag of passwords. There are some old ones that are like "mouse" and then there are others like "Gt4x;JlK". We have that list for "maintenance reasons". Doing things, that could easily be done by some GPOs and other cool tricks.


NIST best practice recommendations state:

* Require more than 8 characters

* Don't require special characters

* Don't force the user to reset their password

* Do check for compromised passwords

* Require MFA

* ...

All very sensible.

https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...


Disclosure: I am the cofounder https://www.clerk.dev

Here's the direct link to NIST 800-63B - it's really a fantastic document with sensible recommendations on every authentication method: https://pages.nist.gov/800-63-3/sp800-63b.html

The tedious part of NIST's password requirements is "Do check for compromised passwords"

HaveIBeenPwned exists, but most open source tools don't leverage it and this requirement goes overlooked.

At Clerk, we follow NIST guidelines by default, including integration with HIBP. In a world with password reuse and "credential stuffing" attacks, this feature is critical to securing your user accounts (unless you go full passwordless, but that has its own tradeoffs).


The important part is that the NIST password advice is meant to be read as a whole. Often I see people quote snippets out of the advice, but unless you read and understand the whole document, you run the risk of reducing your security posture.


But even if you didn't read all of it, and just required longer passwords instead of special characters, you'd be improving things.


That's true, but I've also seen people say that NIST no longer recommend expiring passwords periodically, so we should just let passwords never expire (source: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)").

While that's technically true, the advice is meant to be taken in the context of the rest of the advice (e.g. longer passwords, checking against compromised passwords, etc...).

If all you did was to change all your passwords to never expire, you'd be reducing security.


> If all you did was to change all your passwords to never expire, you'd be reducing security.

Not necessarily. Except in cases of gross negligence, such as storing passwords in plain text, the human is always the weak point in a security system. If you make people less likely to leave their passwords on sticky notes, perhaps by removing password rotation, then you have improved the weakest link of the system, and improved the security of the system as a whole.


What's crazy to me is that NIST compliance isn't part of SOC-2 certifications or similar.

A portion of our customers will ask us about NIST, but it's slimmer than I would have expected.


Off-topic, but this is the second time in two days that I've seem someone on HN correctly use "disclosure" when disclosing something, rather than "disclaimer". A sea change?!

It's clueless, I know, but you'd be amazed at the percentage of people that think disclosing something is a disclaimer (sigh!)


I have multiple financial accounts that still insist on using public-knowledge security questions (which of course I've given fake answers saved in my password manager) instead of just letting me set up proper 2FA. It's infuriating.


Treating security questions like passwords and saving them in your password manager is correct, but make sure that your fake answers aren't autogenerated nonsense like ":s^Twd.J;3hzg=Q~". Many password reset flows involve communicating a security question over the phone, and it's easy enough for an attacker to guess "oh, it's just a bunch of random characters lol" and for the phone rep to just laugh and shrug their shoulders and let the person in. Make sure it's a sentence that makes sense (I would even avoid non-sequitur passphrases such as those generated by diceware), while also making sure that it has no relationship whatsoever to the question.


Maybe “:s^Twd.J;3hzg=Q~ if I don’t spell it, it’s not me”?


Will probably work about as well as that time when I was young and decided to spend about a week signing all receipts with a signature that looks nothing like my usual one, just to see if it would ever be challenged.

Many people are, contrary to all pretense, mostly paid to not give any actual fucks.


I once signed STOLEN on a pad at the grocery checkout. They let it ride and ran the charge.

But I was relieved to find my CC provider calling me to verify I was just up to shenanigans.

I was also curious how many thieves they had run across that signed for purchases as stolen in large cap letters.


What do you think the signature is for? If a store can provide a signed receipt, the bank eats a chargeback. If they can't, the business pays. No one verifies that it is your signature. It is just an anachronism of how contracts work.


My password generator can make pronounceable nonsense words. It has worked ok so far. Some of them are embarrassing though.


My password generator (or just do it manually) can generate word passwords like correct-horse-battery-staple using real words, which is probably a bit easier to read over the phone.


  grep --perl-regexp '^[a-z]{4,7}$' /usr/share/dict/words | \
    shuf -n 5 | tr '\n' ' '
Although maybe just 2 or 3 words would be best for avoiding a support agent skipping the question.

  bless clench moraine


Nice one there, much simpler than my nearly POSIX one (I think I rely on a GNU sed extension, but it was years since I wrote this):

  shuf /nix/store/ny99jkpl3r9zgkkdv5apprzl18i8rb4m-scowl-2019.10.06/share/dict/wbritish.txt \
    | grep '^[A-Za-z]\+$' \
    | head -n 3 \
    | sed -e 's|\(.\)\(.*\)|\u\1\2|g' \
    | tr -d '\n' \
    | sed -e 's|$|\n|g'
Which gives you for example:

  OmegasInsentientPantheons
I only use this for “secret” questions though, not passwords.


  openssl rand -hex 8 | sed 's/..../&-/g;s/-$//'
Or if you like upper-case letters:

  openssl rand -hex 8 | sed 's/..../&-/g;s/-$//;y/abcdef/ABCDEF/


This would still parse as "random letters and numbers" to your typical support agent, no?


Maybe, but it's close to what I use. It's a limited character set and more or less looks like a credit-card which people are used to seeing.

It's either that or pick a random dictionary word.


Citibank is particularly egregious. 8 character MAXIMUM length, lots of special characters not permitted while requiring numbers and letters, forced password changing every few months, I absolutely hate it.


Are you speaking as an employee or a customer? I just checked my password db for a few Citibank accounts and all of them were far longer than 8 characters.


For my CitiBusiness account, not my personal accounts


Yeah, my bank does that too. Asks for my birthday for "security" reasons. They also kill their website's usability by forbidding physical keyboards and forcing users to use a virtual keyboard with randomized key layouts in order to type passwords in a feeble attempt to defeat keyloggers. Some banks even make it extra annoying by generating ambiguous keys like "1 or 7" or "2 or 3".

The saddest thing is banks can't be too secure. If they were, then they would be too hard for normal people to use and they would get locked out of their funds.


I imagine it also disables autofill from password managers (since it's not actually a form field)?

I would literally close out my account in that very moment if my bank did that. Not only because that's horribly inconvenient and I would never put up with it, but it also shows they have no idea what are sane security measures or not.


> I imagine it also disables autofill from password managers (since it's not actually a form field)?

Yes.

They also force users to install literal malware into their computers masquerading as a "security module". Not only is it invasive, it slows down everything to a crawl. I tried to reverse engineer one such module and caught it intercepting every single network connection. It also used to force install itself into browsers as an extension, no doubt in order to intercept data.

> I would literally close out my account in that very moment if my bank did that.

That's exactly what I did. Chose a smaller bank that somehow didn't use this malware. The least bad option.


My bank used to have a virtual keypad, they now have a normal password field. So they actually saw reason. I think there is reason to be optimistic about bank password security getting better; what is known to be good password policies and interfaces are getting more widespread. It may take some time, but it should get better because it is accidental or ignorant password policies from the past, not deliberate attempts to make their customers trip up (unless someone knows better).

As for the asking birthday for security reasons, relic from the past, getting more useless as time goes by. With so many websites asking for that information, and then they get hacked, sold or leaked. Yes, this said the completely obvious, but it still amazes me that any organisation that I have a financial relationship with asks that for identification over the phone, usually my address as well, but that is almost as public.


Don't get me started on online bank security. Here in France, most banks have decided that security is best achieved by:

- authenticating using a 'client number' (different from your 'account number', sent to you once by a physical mail you lost long ago) combined with a 4-to-6 digit (numeric-only) passcode that you have to input on a virtual keyboard

- confirming web-initiated transactions via their app on your phone... but when it's app-initiated, well, you don't have to confirm anything other than just retype your passcode

- in the end, introducing some awfully long delays between some actions e.g. creating a new beneficiary and being able to send money to her... because 'it's for your own protection that we degrade your client experience'

This just bugs me.


Yeah my bank does this. I've been meaning to call around and find a credit union that has 2FA and doesn't require this garbage. I changed my questions to a randomly generated password and put it in my password manager.


Why do basically zero companies seem to follow this?

Banks and airlines are of course some of the most egregious offenders, but even tech companies like Apple and FB have complexity requirements on capital letters and numbers. Surely the login security teams at these companies are aware of the NIST recommendations.

Yet a tiny 3 person startup launching a simple crud app is more likely to google the NIST requirements and follow them than any of the biggest billion and trillion dollar market cap companies in the world. Are these companies acting irrationally here? Or is NIST not taking into account the factors that big companies actually care about, like support costs of dealing with account takeovers, etc.?


Inertia and other standards are a big force here.

The NIST standards recommending this (SP 800-63B I believe, under "memorized secrets") came out in around 2017, many years after large companies had settled on prior standards. Prior standards were closer to what banks / other biggies were doing and they just kept on doing it. In addition you may have other non US govt policies (UK for example likes to publish policy docs, see: https://www.ncsc.gov.uk/collection/passwords/updating-your-a... for their slightly different modern take) which the company prefers to use because of either their own HQ location or large customer pull.

Better yet many different countries requirements and a couple industry docs are cobbled together into a frankenstein set of requirements. That requirements docs is then treated as though it came from Mount Sinai and should not be altered without getting the approval of 3 senior VPs, a professor of cryptography, and the head of IT.


I’ve actually raised with a security executive in my large consulting firm - the biggest blocker is apparently that requirements like frequent forced password changes are written in to many contracts signed with clients as boilerplate ‘we promise to do x/y/z practises to keep your data secure’. Newer contracts have much better language and there have been some improvements that way (our reset period duration tripled recently), but it takes time to trickle through.


NIST standards are technical guidance. The issue is downstream where different authorities make policy based on whatever NIST said at one time.

If you need to interact with taxpayer data and interact with the IRS, for example, you’re required to comply with fairly prescriptive controls for a variety of things that conflict with current NIST guidance.

The other thing is that changing anything identity is a pain in the ass. If there’s a business process and outsourced support model in place to deal with account issues, it’s actually easier to just deal with the shitshow than to fix stuff. Big dumb organizations make decisions differently!


I'd imagine that for at least some of them it has to do with appearance. "Facebook is so secure! It's got ten whole password requirements!"


Big companies have big bureaucracies and third-party auditors that define stuff like this. Getting them to change their requirements is a herculean task.


Interestingly, one of the studies they cite finds that blocking common passwords is one of the most frustrating experiences for users. Even though it's more secure, the user has no idea what's wrong with their password or how to correct it.


I can't say how common this is, but many (most?) online accounts I personally interact with are disposable, represent no sensitive information, and I couldn't care less if they're compromised. They're one-time sign-ups, junk accounts, free trials, free tiers, etc.

> one of the most frustrating experiences

I understand this frustration as a mismatch between the user's non-expectation of security and the service's obeyance to industry security best practices.

Placing a cognitive burden of memorizing a new password just to try out your product strikes me as cruel.

Maybe only enforce password rules as progressive enhancement once sensitive information comes into play? After all, what's the point of protecting junk?


Passwords often protect things like random niche forum boards from grief more than they protect the user's sensitive information in such cases. 3rd party auth is a great solution but a lot of people don't want to tie their "real" accounts to the low tier sites. MFA is of even greater help for low tier site's pains but if you can't get someone to use a decent password or link their identity how likely are you to set up 2FA for it? In the case of "free" services type signups they want you to onboard your information or link your identity and an account workflow is the easiest way to do that as it's a small percentage that will go through the trouble of burner or temp emails and fake info yet at least you have an easy way to rate limit such users from hijacking your "free" offerings.

Also you're not supposed to be memorizing anything for logins. At the very least you should be letting your browser use the randomly generated password and save it to the browser password store if you're not using a full blown password manager.


Yes every service considers itself critical. But users don't give a shit if some forum they signed up for 3 years ago gets hacked.

For me I just see it as a sign of pretentiousness when you expect me to come up with a 20 character password. Luckily Firefox has a built in password generator now.


> But users don't give a shit if some forum they signed up for 3 years ago gets hacked.

It depends on the forum and the hacker. Most hacks won't have a practical implication, but a targeted attack by somebody unhappy with your comments might abuse your identity or information the account reveals.

Or a forum can reveal information you don't want to have revealed (medical help forums, sexual stuff, ...)

And sometimes you are really to leave "child times" behind you, which might reach surface again later. (Say when you get into a political career ten years later and somebody finds your mail address and searches through dumps of leaked data etc.)


Link? That sounds like an interesting study.


"These results reflect the fact that dictionary checks appear to contribute heavily to reducing usability by making password creation difficult. To some extent, this may be a result of our harsh check that uses a cracking dictionary and matches words of any length, rather than ignoring words of less than three or four letters, as may be more typical. We believe, however, that what makes any dictionary check valuable - preventing the use of common or predictable letter strings in passwords—also makes it inherently more difficult for users to think of a valid password. An interface that more clearly explains to users why their passwords are being rejected and provides suggestions for avoiding future rejections might help to reduce frustration"

https://users.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwo...


> * Require MFA

Using some kind of OTP authenticator app or device and __NOT__ SMS!


SMS is perfectly good as an additional authentication factor. i.e. When you log in on a new device using your user name and password, you also need to type in the text message code you were sent. It is a convenient way to strictly increase the security of an account.

What SMS is terrible for is as a single point of account recovery. This is unfortunately how it is often used. "Multi factor authentication" in practice has become "Use any one of multiple available factors for authentication", which is awful.


I guess you don't travel much. it's very common to have internet but not cell service (so no SMS). it's also common to buy a local sim so effectively no SMS or at least not the one you have registered.

So no, SMS is not perfectly good. it's crap and needs to die in a fire.


I used to travel a lot and the exact combination of no signal and internet was not frequent at all.


That heavily depends on where you travel. Even here in Southern California there are populated areas with little to no mobile internet service (like Big Bear Lake, Anza Borrego, or Joshua Tree areas for example)


And they still have internet available to travelers?


I've had wifi at the hotel/motel/lodge but no cell service before.


Depends


The other part was under another mobile system, say in another country. Can calls/texts find your phone today overseas at a reasonable price?

I know that frequencies are different in some parts.


No it isn't. If you lose your phone you are in for a world of hurt, let alone all the various ways there are to intercept/redirect SMS messages and/or entire mobile accounts. To say nothing of the fact that internet access is not yet globally ubiquitous, or if you forget to pay your bill, or all these other possibilities.

A proper OTP app works offline, and more than one of them can exist for any given authentication, so you can have backups if your phone is stolen.


The reason companies like Microsoft are basically calling for companies to stop relying on SMS is that it is just way too easy to compromise a phone number or a sim card and there are way too many people that get subjected to identity theft this way. Compared to other second factor options in the market, SMS is probably one of the worst ones precisely because operator security is so flawed.

It's better than just having "secret" as your password, but not by nearly enough that you should feel particularly secure with it.

The issue with with all multi factor authentication is dealing with the likely situation that one of your users locks themselves out of their account and needs to have the factors reset so they can get back in. The secure way to deal with that would be to go, "Sorry, we don't know you and you've lost all your data. Goodbye!". But of course with important accounts that usually escalates pretty quickly with upset users hogging your helpdesk employees and not giving up that easily. So, most companies have help desks that are easily talked into "helping you". That's what they are incentivized to do. Companies with tight margins are the worst. Like most operators for example.


I think people also worry about the SIM card swap attack. Even if you have multiple ways to authenticate, RSA token, MFA app, and sms auth, the SIM card swap makes it way easier for someone else to have the thing only you should have.


You absolutely should lock your SIM always. SIM duplication is a thing.


Anything requiring my phone number or a binary that runs on my phone is a deal breaker for me. It has massive privacy implications.

We desperately need to have better MFA options if we're going to require it from users.


> or a binary that runs on my phone is a deal breaker

Phone numbers, fair enough, but TOTP is an open standard and there are plenty of open source implementations for the client side. It’s also available in most password managers (I use 1passwords implementation).

“MFA can’t require me to run a binary on my phone” is a bit extreme. TOTP is fine.


MFA can't require me to run your specific app is a good guideline, though. It still leaves TOTP as fine, as long as I can choose my implementation.



TOTP doesn’t meet the security requirements of higher trust level auth. You’re demonstrating why - storing your MFA with your first factor is pretty dumb.

Where I work a bunch of people had a cow about having to put a MFA app on their phones, but refused to take a work phone. Our remedy was to issue them PINs to allow after hours access to the building.


For average person there’s also the problem of recovering access in case the phone with OTP app is lost.

Every service of course has the option to print backup keys. Maintaining those (in secure offsite location) over years takes some effort.


> * Require more than 8 characters

If I'm reading this right, it's more than 7 characters. And more than 5 if you don't let users pick the password, which seems surprising.

> Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric.


You’ve read it correctly.

The idea is to mitigate against brute force by account lockout/disable following N failed attempts rather than enforcing greater password length or complexity requirements.


Yup. So many people mess this up, it's infuriating. U.S. banks are the worst.


Even outside of the U.S.


If you require as few as 9 characters, without requiring special characters, the security is poor. The reason is that users do not choose random strings of letters, so the entropy per character is low.

If we assume an entropy of 2 bits per characters (which is generous if the user uses dictionary words), then 9 characters gives us 18 bits.

A 9 character password could easily be as poor as a random 18 bit integer.

If we permit the user to use nothing but lower case characters from the set a to z, we should probably require a password phrase length of at least 30 characters.

Not forcing the user to reset their password means you need a really strong one, in case the user is using the same password. You're giving attackers all the time in the world to crack a leaked hash, so it better require something resembling all the time in the world.

These recommendations are basically relying on the MFA recommendation to make up for all the others. Like, oh, it's okay for the user to have 18 bits of entropy for a password, because we can trust that the attacker won't have the user's phone.


So "fishyidea" has less or equal entropy to "262119"?


Neither fishyidea nor 262119 show up in haveibeenpwned's database, so they're at least uncommon. Neither of them look to have much entropy, though.

2x211y doesn't look very random to me. 2 and 1 are consecutive, and there are only 4 distinct digits here. Even if it was randomly generated, a good password generator would probably discard it for being akin to passwords that humans tend to generate. (This is especially true when you impose minimum lengths to passwords. "26219 isn't long enough? Fine. 262119.")

Fish and idea are both among the top few thousand most common words. Searching adjective+noun pairs is going to be much more fruitful than searching arbitrary word pairs, and ideas can in fact be fishy, so it makes sense to guess that particular adjective+noun pair before trying metamorphicidea.


I would say it has better entropy, but not by much.

The word "idea" appears list of 850 common words:

https://en.wiktionary.org/wiki/Appendix:Basic_English_word_l...

"fish" is ranked #1453 in the list of lemmas linked from here:

https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#To...

We can arithmetically encode the choice of two words from dictionaries of 1000 and 1500, respectively, using 21 bits.

The two bits estimate is a somewhat pessimistic lower bound.


How to practically check for common passwords? Ideal would be to have like the most common 1/1000th of the hibp so that it's not too big for deployment in some clever structure (compressed trie? bloom filter?). I don't trust 3rd party services.


Have you heard about https://haveibeenpwned.com/Passwords ?


Sorry I reread and you said hibp so you know! Why not use the entire set?


Because it's 12.6GB compressed! That's just too large to deploy. I want a much smaller part. And I would prefer the actual passwords because I think they could be compressed much better than the (essentially random) hashes.


I got new worse policy in this November: at least 14 chars, must have all UPPER,lower,number,symbol chars, change every 3 months. Of course no MFA.


It's also interesting because NIST doesn't generally follow these rules, since they don't use passwords (at least for most things).


Ironically, most of the government doesn't adhere to these recommendations


> Require MFA

But allow at least 2 hardware keys and not only SMS.


Eight or more.


I believe in personal responsibility. If someone wants to use 1234 they should be allowed to.

America is strange, any rando nutjob should have access to firearms but US corporations are terrified of being sued.


My frustration isn't just the sites that make the password rules clear after I submit the form. The worst sites are the ones that truncate my generated password to fit their maximum password length and then don't tell me (which seems to happen in more places than it should).


The worst sites are the ones that truncate my generated password to fit their maximum password length and then don't tell me

Or worse, they truncate your password after you've already used it for years and years.

I had a 30-character password with Bank of America. Somewhere along the line, it changed its password requirements to only allow a maximum of 20 or 25 characters (I forget), which automatically invalidated my password.

The password was stored in my password manager, so I knew I wasn't entering it wrong.

BoA support said I should use the "change password" feature to update my password, but I couldn't because it requires me to enter the old password, which it would not accept. For some reason I can't remember, I couldn't use the "forgot password" feature. Maybe it also didn't work right.

I spent an entire day on the phone getting bounced from person to person before finally someone was able to take a new password over the phone.

Since Bank of America can't figure out how to build a web site login, I no longer trust it with my money. I emptied that savings account and paid off the credit card as quickly as I could. I no longer use BoA.


>Or worse, they truncate your password after you've already used it for years and years.

Worse than that must be the sudden realization that your bank probably saves your password in plain text somewhere.


As it's a bank that's probably the case, but you could have a change on the server side from

  hash($password) == $storedhash
to

  hash(substr($password,0,20)) == $storedhash
And you wouldn't get in, with any password (including just putting in the first 20 characters)


More likely they just updated the password during a successful login.


I'm not sure why anyone uses banks like BoA, Wells Fargo, First Niagara, etc.

Fidelity is a superior experience in nearly every way - just categorically. I'm not sure if people just don't know that you can use Fidelity this way?

The only downsides are no local branches, but that's hardly an issue unless you need a cashiers check. In those rare cases you can spin up an account at shitty bank, get the check, then close the account. I've had to do that maybe once ever.


In what way? I'd be curious to understand what it is you value about them, but your post reads more like marketing than a satisfied customer story.


No fees, also a brokerage, free checks, free atm, free wires, can trivially spin up IRA, move money between accounts, etc.

Phone call support has been surprisingly good whenever I’ve needed it.

When I used standard banks they often forced me to go in at difficult hours to do basic things and it took forever. They also had lots of fees (and as suggested in the parent comment, bad software)


I fully agree. The difference is the value exchange. At a normal bank they just want to charge you fees because you cost them money. Fidelity lets you keep your money with them in the hopes that as you grow your money, you'll spend it on their investment products, which I imagine everybody does.

Most brokers have some kind of cash account and they're always better than banks and almost always better than credit unions.

I recommend keeping a credit union account open too so you have a local branch if you need something in person.


You state that you don't understand why people use large, complex banks. Then state that you have a very simple, financially uninteresting life.

You answered your own question.


I have a pretty complex financial situation, but Fidelity can just do all of it more easily than retail banks.

Is there something banks like BoA do better that I'm missing? When I've asked people I know this I haven't gotten any good answers. I'm genuinely asking.

My impression is that BoA, Wells Fargo, etc. mostly take advantage of customers that don't know better options exist.


Your impression may come from the fact that many people don't talk openly about their finances to random people on the internet.

For me, Fidelity is a non-starter, for reasons that are none of your business.

It's nice that you like Fidelity. But it's a good idea to recognize that your finances and life situation are unique to you.


Cool - so a non-answer and condescending dismissal of genuine questions.

Lots of people talk about finances online. See r/personalfinance or r/financialindependence. It’s a good way to learn.


I am not "lots of people." I have no interest in being "lots of people," or in proving myself to strangers on the internet.

I cannot convey 50 years of my financial life, experience, and history into what fits in an internet post. Anyone who can probably has a very narrow view of finance. I can say that I know how to manage my finances, and my accountant agrees with my methods and track record.

But if you think Reddit is the route to financial literacy, I can understand why you don't understand.


I don't necessarily think Reddit is a good route to financial literacy. Nor do I know of a better route. Despite (or because?) of all that, I still think the question was reasonable. If you don't want to answer the question, that's fine. But you don't have to be so antagonistic about it.


That response is awfully unconstructive and dismissive. Perhaps you're able to articulate why you believe Reddit, specifically r/personalfinance and other reasonable boards, are bad, no?


So, for a bank the maximum is to allow NSA to crack it if they wish, right?


They kept insisting that a 20-character password is safer than one with 30 characters. I couldn't get them to understand otherwise.


On nsa.gov for a long time the max password length was 12 characters. Last checked in 2016.


Supermicro BMC passwords do that. Recently (i.e. this year) I set up a bunch of servers and was setting the BMC password to a known value.

Apparently there is a limit of 20 characters for the password. The password I set was 21 characters (which was accepted without error).

When I tried to log in with this password, the login was rejected.

However if I log in with just the first 20 characters of the password, it works.


They should at least make their sign-up and login password fields have the same max length attributes...


It's even worse than that the BMC is a preconfigured part of the server not something you go to a sign up page for. It's literally the _change password functionality_ that does not warn/error on the password being too long!


I had seen the same thing on a (much older) switch, which is the only reason I thought to try truncating my password. Worked after dropping only one character, I was sort of expecting it to be 16 or maybe even 8.


> However if I log in with just the first 20 characters of the password, it works.

Even worse is when the password change form accepts more characters and processes them correctly, only to have the login form not allow you to enter all characters. If I'm not mistaken, the business remote deposit portal my bank uses does this.


Could that mean that the password is stored unhashed?


Since the number of characters is the same in the case of hashes, yes, the password is saved as-is.


I've also had fun experiences where the "special characters" differ in the description than in the implementation in a few ways.

Once I had a password accepted with non-alpha numeric characters which were considered invalid as input on the login screen and so even though my password was correct it would not let me log in because it was validated with different logic after creation.

Another issue I've seen is that the password was required to have only a certain subset of non-alphanumeric characters, but it did not explain or validate this client side so I had a password for which all the boxes turned green, but was still invalid.

In both cases only trial and error worked to find a valid password.


I spent half a year being charged monthly by Microsoft because Google considers my email address the same whether or not it has a period in it but Microsoft had somehow split my account into two based on that difference.


that's.. really on you I think, and not at all similar to one site having differing validation rules in different places for the same data. What gmail does there isn't some kind of standard, it's a unique special feature google does. You don't want other sites getting clever about this sort of thing, because if the rules change much worse things will happen.

Now, sites that treat email addresses as case sensitive - those are evil.


I'm missing something, why would they charge you monthly for that?


Xbox Live Gold. I'd call, give them my account details, and the rep would tell me it was canceled. Three months later, another bill. Called my bank and had my card replaced, three months later somehow again another bill on my new card. After that I figured out what was going on and managed to cancel the account. I was a teenager at the time.


Extra user fee on some kind of SAAS?


For a while, Discord had few password restrictions so 5 characters were fine. Then they changed their app to only allow 6+ character passwords.


Worse: I once set my E*Trade password to something it accepted but wouldn't recognize when I tried to log in… because it was too long.

After changing it I got locked out of my account and had to call support to resolve the issue. The worst part was that after verifying my identity over the phone they kept sending me reset links and I kept using long passwords generated by 1Password (30 characters IIRC) and it always accepted them when resetting but still would never let me log in.

It took many attempts and new reset links until they suggested trying a shorter password, which was eventually accepted both during reset AND login. Of course the reset page didn't mention a maximum length.


It gets worse: if you use 2fa the security code generated by the symantec thing is just appended to the password, so if your password is still a valid length, but then the 2fa takes it over 30 chars, it fails. It is the worst.


And then their sign-in page doesn't truncate it and it just fails to login... Absolutely love it!

One of my favorites was Nintendo's user account. The web allows decent passwords when created, but then the actual game console only has room for inputting 15 characters or so for the password :@


I've even seen it backwards (I assume) where creating the account with the longer password worked but then I couldn't sign in with it or any prefix of it.


Exactly. Indian Retirement Fund, PF, National Pension System, has a rule of max 16 chara in password. They don't tell this at password reset or set. They simply accept anything 16+ length; & silently truncate & use the first 16 chars. But user is never told. When I try to login later, it says password wrong. I had to reset it multiple times, because my password manager was generating longer ones.


Yeah you'd be surprised where it happens. I used to work on the help desk for a company that operated nuclear power plants, and their password system would only accept 8 character passwords, alphanumeric only. However, the length checking would randomly fail and users would be able to set a longer password and the system would silently truncate it without throwing an error or alerting the user in any way.


My favorite one was a site that capped the password length in the creation form in a way you couldn't tell it was being truncated, but then let you enter any length when you logged in. And being a finance thing, it blocked your password after three attempts.


Wait, what? That never happened to me. How do you go and find out your password then? Trial and error?


They might just truncate the password during login as well. I was able to login to my online banking using only the first five digits of my password not more than 3 years ago.. They fixed it in the meantime but I'm still worried.


You should still be worried, since any bank storing an unhashed password clearly has security fail.


> Trial and error?

Bingo. Super frustrating.

See also this comment: https://news.ycombinator.com/item?id=24827031


I once had a bank that used substr(tolower(input_password), 0, 8) as the actual password.


Heh. Late 1990's, I was an admin on a >1,000 user system - which was rooted because it had that feature, and another admin figured that 'meatball2&balloons' was a secure-enough password.


That happened to me many years ago with Microsoft logins. They were truncating passwords to 12 characters and my generated 16-character passwords never worked. I kept resetting them over and over until I did a Google search for Microsoft password requirements and found out that they were being truncated.

That was likely fixed a long time ago, but I'm still wary of increasing my Microsoft passwords past 12 characters.


FWIW I use 30 character password with recently created skype account, and relogins work.


I had it happen a few times. Usually I would reset it a few times until realizing that it's obviously not saving the password I'm entering, at which point I would try a setting a shorter one.


T-Mobile did this to me a few years ago. Don't know if they still do, but I couldn't believe anyone thought that was ok.


Can I ask what length your passwords are (roughly)? I don't understand the motivation for anything long in the context of randomly generated passwords for websites. 8-10 characters should be plenty.

(This isn't to excuse silent truncation.)


My passwords are long because I don't actually use a password manager. I generate my passwords with a help of my algorithm that makes them easier to type in wherever I might need them (resemble real words) like in a terminal.


All my passwords are passphrases, randomly generated and stored in my password manager. Usually 10 words, for about 130 bits of entropy. EG PledgeRoutineSuitableBunkhouseExceptionCremeReassureChildishPhrasingNuclear, which is 76 ASCII characters but only 10 symbols.

They're stored in a password manager, but they're typeable if needed. My "security question" answers (mother's maiden name, etc) are generated the same way, unique per use, and also stored in my password manager.

Most sites don't need 128 bits of entropy. But things like banking or subscriptions should have at least 112 bits of entropy. And it's easy to just set the generator to 10 words by default.


Outside of things that need to be extremely secure like my AWS account password I usually prefer readable random words passwords over random text. Even random 2 word passwords usually surpass 20 characters especially after adding in numbers and special characters most sites require.

It's a lot nicer being able to check if I typed in my Peacock login at my parents home at a glance versus a string of random characters.


I usually generate passwords in the ~32 character range, using A-Za-z0-9, specifically to catch sites with dumb security policies (maximum number of characters, or considering `aceg1234!` a stronger password than `MgHm7MC8kEuXWKEzD7CvDgxCtWssz964`).

In most cases I just comply with their dumb policy and put a snarky comment for my future self in the Notes field of my password manager and it makes me feel better.


"correct horse battery staple" is 28 characters. And it really should be two words longer than that these days.


20 characters is fine. Even using only lowercase letters, in a worst-case scenario it'll take millions of years to guess by choosing characters, and a dictionary attack won't fare any better if you use four words that are moderately rare. Even if they're only in the top 1000, four words means the search space is 1 trillion guesses. Increase the search space to 10,000, by including such obscure words as "villager" and "conserve" and "missionary" (9950, 9973, and 9991, respectively) the search space increases to the quadrillions, equivalent of a 12-character random password with symbols, 53 bits.

Is correct-horse-battery-staple guaranteed secure to the heat death of the universe? No, but good enough that it'll take a targeted attack several months to guess.


If you're using a random password, c29b90b0e25ece3f2dabcef496d22103 is fine for a password, 2^128 bits. It's a right pain to type in on a console though.

On the other hand, "rundown skyline pluck shawl pastrami radar refueling poach prankster durable" is far easier to type and is about the same entropy


The entropy is far greater than 2^128. Pastrami, refueling, and shawl don't appear in the top 30,000 English words list, so even knowing your password generation strategy, every word adds at least 15 bits of entropy, you're up to 150 bits, probably more.


My word list contains 7227 words apparently, so 12.82 bits per word

https://github.com/redacted/XKCD-password-generator

Not sure how many bits a "good" password should be nowadays.


I use a password manager and randomly generated ones for most everything, but I use diceware pass phrases I memorized for specific cases so that in an emergency, e.g. when traveling I can get access to some things even without any of my devices.


My passwords are all 20+ characters long


For websites, you're just making your own life harder for no real gain. Even with purely alphanumeric 10 chars, it's not like anyone can exhaust the 36^10 password space over a network with no one noticing. Yet whenever you run into issues with the website or the password manager (or some other non-routine thing... like you're on your phone and need to enter this on a different computer) and have to enter it manually, it'll be much more painful than it has to be.


I guess you assume that everyone protects their stored hashes.


Not really. Even if you're worried about that, (36 alphanumeric + 10 symbols)^10 is roughly 4E16. Even at 2B checks/second/CPU (which is incredibly generous if the web developer has any competence) that's around 10M CPU-seconds, i.e. 115 CPU-days. For cracking one single password. An ASIC will speed it up, but again, remember this is one single password, and it can be an overestimate by like a factor of > 1 million if the developer actually used a KDF (and I'm not sure why they wouldn't, if they're already hashing). How paranoid do you have to be (and how big of a target do you have to have made of yourself? and exactly how valuable are your credentials?) to worry about a threat like this for most websites? Maybe it makes sense for your primary email, but do average accounts really benefit? Compared to the inconvenience of when something goes wrong and you have to type a long password manually.


If you don't let users use their preferred password structure, they'll have to use a shitty password like hunter2, letmein or dragon. Those can be recovered with a few attempts, even online. If you really want a 10 character password, you can hash the user's password, then imagine the first 10 bytes of the hash are the user's password, then do whatever you want with them.


How does one more iteration help? Your hash algorithm is already hashing multiple times. Seems it would be easier to increase the work input to PBKDF2 by 1 than to implement your own multi-hash. Even better increment it by 2000.

But the point is that you don't control the website's hashing algorithm, or whether they hash at all, or whether they store their hashes in a public s3 bucket. They may tell you what they do, they may not. But you have to trust them either way.

A long random password using a variety of characters is the only control I have when setting my password. If they have a good hashing system and protect their hashes, my long random password will not hurt anything. If they truncate my password before hashing, it will still be the best password I can make for that app.

If I use 5 5 letter words as my password and they truncate after the first 10, how would I know? My password might be "horseapple" instead of "horseapplehappygreennymph".

If I give them 10 alphanumerics and they leak their md5 hashes, I'm pwned in a few days, assuming they even salt it.

If I give them 20 random alphanumeric+symbol then I can't imagine what exotic thing they could do wrong to make it less safe than any other password I choose.

I might make an exception for some streaming service that I have to enter by hand on a tv remote control, but otherwise i am going to generate it with max entropy because I am never going to look at it anyway.


So long as passwords are unique, offline cracking isn't an issue. If they have that site's hashes presumably the site is compromised already.


Not true. Offline hacking is not only a concern for passwords used on multiple sites.

There are many scenarios where an attacker might be able to grab the hashes, but still need to crack them in order to get access to other data from your account. If there is a sql injection vulnerability in the authentication service, for example, it does not mean they can necessarily overwrite the hash or access data in other parts of the application.

I once found a bug in a payment processor that let me download the user record including password hash for all users in that payment processor. But I couldn't use that to get their stored credit card numbers directly. However, if I had brute forced those hashes, I would have been able to log in as them and access their other account data and make transfers, etc. I am sure a large majority of those password would have been very easy to crack. If I was an attacker, those would have been my first targets.


It's trivial to choose a smaller pw for sites that are difficult, but for the ones where I'm only ever using a pw manager to access, there's no reason not to use a 20 char unique random string.


For me I have long 20+ character passwords because my password manager remembers them for me, and I can copy/paste or autotype or copy them into the in-browser password manager.

I very rarely have to manually type in a password.


Websites are not the only system that can enjoy a password, and there's no excuse for their egocentrism.


EE does this on their website but not on their mobile app. Took me ages of debugging to figure out why my password manager worked on one platform but not the other. I was so annoyed when I realised what it was.


I'm not super knowledgeable about these kinds of things, but aren't hashes usually a fixed length? Why would it matter how long your password is?


If they truncate on password set but don't truncate on password validation, that's the worst.


This has happened to me on one site. As far as I'm concerned, this is just a bug.


Due to the nature of my job and the age of some of my coworkers, I am sometimes casually given passwords on a piece of paper. Out of a sample size of conservatively 20, I have never even once (!) seen a special character other than !. It just doesn't happen. Password rules and a requirement to change your password every X months are pure security mirage and just create frustration in people who often struggle to generate even one secure password in their entire lifetime.

(Yes I evangelize password managers around here. So far I've converted 2-3 people. They are the important people with shit people might want to steal on their computers/accounts, so I'm happy with this.)


> Password rules and a requirement to change your password every X months are pure security mirage and just create frustration in people who often struggle to generate even one secure password in their entire lifetime.

Every place I've ever seen or heard about with a "change every X months" system, everyone just uses a (often shared!) formula to come up with variations that satisfy the is-this-too-close-to-your-last-X-passwords checker, based on the date or whatever.


I got up to P@ssW0rd12 at one job.


I was working my way to it, when IT rolled out a new policy of "cannot share more than 2 consecutive characters with a previous password" or something like it, included in an email along the lines of "an audit has found this new policy applies to you".

Dicks.


Doesn't that imply that the are saving your previous passwords in plain text somewhere instead of saving hashes of them? How is this more secure?


Usually, when you change your password, you have to enter your old password. With both plaintexts, the check is trivial.

It also means it should be possible to bypass that by changing the password twice or by "forgetting" your old password.

Another possibility is that they simply lie to you and the rule that is actually checked is much more permissive. I've often seen requirements that are not actually checked


This would be my guess too. Alternatively, maybe they save hashes of all substrings of length > 2 and check all hashed substrings of the new password against them.

(Which - in my limited understanding of infosec - would be only marginally better than plaintext, but I can be wrong.)


Yeah, having hashes of substrings of a password would help a LOT when brute forcing. If I have a 10 char pass, and I'm storing 1 hash of the full pass + 9 hashes of the 2-char substrings, I can now brute force all those 2-char hashes and then fit them together in the few valid ways they could go together (assuming there is more than 1) until I find the final hash. Salts wouldn't matter.


And that's how you ensure everyone writes their password on a sticky note.


Eh, a sticky note is pretty darn secure for the kinds of attacks you care about. If your attack vector is someone breaking into your office the security game changes completely.


> If your attack vector is someone breaking into your office the security game changes completely.

There are at least two other important attack vectors against "sticky notes": accidental sharing through photographs and/or online meeting cameras, and visitors memorizing visible passwords. Both are defeated by hiding the sticky note below the keyboard, but my guess is that most people leave it visible on the monitor bezel.


I leave a post it on my monitor with a wrong password as a decoy.


Yeah they either need a keycard or some tailgating to get to the bottom of my keyboard at which point they could just take the damn laptop and shuck the drive into an external enclosure and get everything that way, so nbd in my opinion.


> shuck the drive into an external enclosure and get everything that way

Disk encryption (ie, BitLocker) is supposed to prevent that from working.


If that policy is enforceable, someone would have to be storing passwords in plaintext, or the hashing algorithm is too weak.

IT shouldn't be able to tell anything about plaintext password similarity beyond equals or not-equals.


Ad-hoc, this is correct.

But at the time of the password change, no, assuming password changing requires you to enter your current password as well.


If just with previous password, then yeah, that's fine, but more then likely they are saying with the previous N passwords, which would require storing the previous N passwords in some kind of plain text or easily reversible form. Even if those old passwords are useless at that point (which might not be the case for something like a laptop that hasn't talked to the domain controller and learned that the password has been updated or something), it's still dangerous (what if they used that password on a vendor's site, or on their own banking login...)


The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.

If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.

Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.


The check is done server-side.

At the time of a password change, the server still has your old password hash stored, and in the process of changing it, you are sending both your old password and new password. The server can verify both that your new password and old password differ enough while also verifying that the old password you sent it is valid.


I had a similar concern. Or maybe it was a company wide email and that language was in there just because.

Of course, our company-wide email was down for 2-3 months a couple years ago due to a ransomware infection, so our IT isn't stellar. So who knows!


Sounds like we have similar roles. I've never gotten them on paper, but multiple times a month I get emails along the lines of "My account doesn't work. My password is Banana1. Please fix". Every time I reset every single password they have (at least 4 hours of work for them) and inform them not to share passwords. Still, I've had users do it multiple times.

I finally got all of our admin/root passwords into a password manager with sharing among job functions and our CTO as backup to ensure some level of continuity. After losing passwords to multiple production systems after someone leaving the company it was still a battle.


Congrats on getting them to use a password manager, now everyone can see all of their password by typing in the master password they stuck to the side of the screen.

I'm only half-joking sadly, people just don't understand why password exist in the first place, so they comply maliciously.


I'm sure people do that, but the fact that they only have one password to remember, and (hopefully) don't have to rotate it would hopefully deter them


Requirements for uppercase letters, numbers, and special characters mean I stick an "A1!" at the end of my otherwise strong and memorable password. I'm sure I'm not the only one.


Yeah, at least there's a good work-around for the numbers/symbols requirement. What's more annoying is when sites have a low maximum length so you _have_ to use special characters to get good entropy, or when they have other bizarre requirements like "can't contain more than 3 of the same character".


Todays computers can brute force passwords of their maximum length in a few hours.

I suppose someone somewhere has a maximum length that is hard to brute force, but I've never seen it.


What max length? Once a password reaches 128 bits of entropy the key space is unfathomably large. You could have a password of length 1 with 10^100 possible values, and it could take a VERY long time to crack. In short, it has nothing to do with length, it has to do with bits of entropy, and there are still very real limits to what even the most powerful computers can brute force. Several years back, it was stated by Peerio that an 81-bit password would cost a billion dollars to crack. It becomes less feasible and more expensive from there.


8 character, upper lower case, ten numbers, and about fifteen special symbols. About 6 bits per character. Most limits are 8 characters, so around 40 bits. More or less depending on the exact rules used.

That assumes true random passwords, most attackers can make some educated guesses and cut the problem space, but that isn't a true brute force.


You would be correct. Mine is "#1". I use compound english words whose meaning is non-sensical in a conversation but easy to remember.


Frequent password rotation causes increases of passwords on post-its stuck to the monitor.


In most cases I would take a strong password stuck to the monitor than a dictionary password on an internet exposed system.

But yeah, frequent password rotation is still bad.


Fair point. If your passwords are compromised because they were stuck to the monitor, that means physical security was breached and the copied passwords are now the least of your concerns.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: