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.
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.
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 -"
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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 (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.
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.
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'
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.?
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!
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.)
"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"
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.
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)
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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".
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.
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.
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.
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.
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.
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.
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".
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.
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.
Worse than password rules, are when sites disable the ability to paste in the password in the 'confirm your password' field. Forces users to reduce the 50 chars crazy password they wanted to set using their preferred password manager with a less secure version.
I use the following bookmarklet to fix issues like this. It's similar to the browser addon discussed in sibling comments, but without installing a browser addon. Simply create a bookmark named e.g. "Don't mess with paste" with the following URL:
Or the site lets your password manager fill the fields, but for some reason their javascript doesn't recognize it and refuses to let you submit because it hasn't verified your password as matching, meeting strength rules, etc. At least in that case deleting and typing just the last character usually fixes it.
Probably some developer who isn’t fully up to speed with what event hooks to use in order to trigger their JavaScript validation rules. And yes it is super annoying.
…though not as annoying as sites that don’t let you copy / paste into their login fields.
Funny, since the problem of “typing stuff into a text field and submitting it to a web site” was solved over 20 years ago, and without JavaScript. Yet web developers today still manage to try and fail to solve it using code. I guess when your only tool is a hammer…
I've had this in my AutoHotkey file for a long time now:
; Type in the clipboard
^!v::
MyClip = %clipboard%
StringReplace, MyClip, MyClip, `r, , All
SendRaw %MyClip%
return
So I can hit Ctrl-Alt-V and have it type in whatever's in my clipboard. I use it to scrub the text and deal with stupid sites and forms that don't allow paste. I also have a variant that adds a Sleep so I can do the same thing when something like RDP takes control.
Besides the browser extensions/addons mentioned above (that sometimes either don't work for me or gets disabled on my machine) I also use/used to use xdotool (on Linux). You can do: `sleep 3 ; xdotool type "yourpassword here"` and then navigate to the field you want to have it typed into.
I once had to open up my developer console and manually set the field with JavaScript because they didn't want me pasting into the password field. Although the site was also all kinds of broken so it might have actually been an accident that pasting into the field didn't work.
I do this on quite a few sites. Most of the easy ones have an easy to find onpaste event wired in the DOM and it's a simple delete. I feel like there are so few legitimate uses of onpaste and the browser should have an easy override that if I ctrl+v three times in quick succession or something like that it ignores or disables onpaste events.
Alternatively, my password manager does have a decent "autotype" tool when all else fails.
When the onpaste is easy to spot it's one key (Delete) after selecting that attribute or event versus a minimum of around 14 give or take keys depending on how good your console autocompletion is. When it is not easy to find, yeah I next try just setting the DOM value.
No kidding. Govt websites seem to think this is a positive. Of course, these same folks do the 90 day rotation. Result - everyone writing down passwords on post-it notes next to screens.
The TreasuryDirect website requires login with a case-insensitive on-screen keyboard in the page itself. I have no idea why such an idiotic approach would be taken.
The ENTROPY_REQUIREMENT variable means you need a password that has at least 2^n possible combinations, given the character set and the length used. There's no restrictions other than that. If you want to only use lowercase letters, that's fine, as long as the length is long enough. If you include special characters, the length requirement drops.
I use a simple message to tell the user whether or not a password is acceptable, along with a radial progress bar to demonstrate success: "Not strong enough. Add complexity until the circle fills."
Which likely is fine. Adding length is a perfectly valid way to add entropy. If they happen to add a special character, it will just complete it faster.
I had a 16 character password which I used in an PC online-banking application.
After an update the password was unable to unlock the database.
So I started creating new databases with different passwords to see what was going on, and it turned out that all passwords longer than 10 characters were failing.
So I truncated my old password to 10 characters and then it worked. No hint, no nothing in the release notes.
Not neccersarily, if the previous version truncated the passed password to 10 characters, hashed, then stored, but the new version no longer truncated, the hash wouldn't match unless you used 10 characters
if your password was qwerty123456, it might have allowed you in with qwerty1234999
I assume it was like iso1631 commented, that before the upgrade they truncated it before hashing it. In any case, using a password (=encrypting database) was optional, so my reaction to this experience was to remove the password and move the entire application into a VeraCrypt container.
Most attacks on passwords these days are credential stuffing, not brute force.
This means that password rules REDUCE the amount of work an attacker has to do, as they can omit previously breached usernames/passwords which don't meet the password rules for the site being attacked. This means they can try more logins before getting rate-limited.
I’d really love the W3C to come out with some elements that provide:
1) Communication of complexity requirements
2) Explicit password manager fill targets
3) An endpoint for a password manager to rotate passwords automatically. (and the validity period)
All of these would be backwards compatible with grandmas that write passwords on post-its and mouldering IT policies that snub NIST recommendations. Sure, webauthn is wonderful and all, but it’s a whole lot easier to ask for some simple HTML changes rather than implementing a whole API.
W3C can come up with all the elements they like but websites won't use them because they don't match with company style and the latest trends in graphic design.
There does need to be some rules or else people would set their password to be blank or a few characters.
I would be happy with consistent password rules.
1. No password that was included in a breach a la the “haveibeenpwned” hash check system[0].
2. No password reuse.
3. A Minimum length. Something like 14-20 characters. And no maximum (or at least something set to at least 127 characters as the max allowed).
4. Reset no more than once a year.
And that’s it. All valid UTF-8 characters accepted. No requirements for special characters or not, just long well randomized passwords, or more aptly, passphrases.
Teaching everyone about password managers and diceware[1] passwords would go a long way too.
> just long well randomized passwords, or more aptly, passphrases.
Interesting idea. I could imagine a new password prompt with an algorithm to reject passwords that were not random enough. How infuriating would that be? What would the hint message look like: "your password must contain a statistically random arrangement of characters"
> 1. No password that was included in a breach a la the “haveibeenpwned” hash check system[0].
Now imagine that in some years every password below 20 characters has been in some breach on haveibeenpwned and now every user of every system needs a new password that is 21+ characters. Some period of time will occur wherein everyone will upgrade rinse and repeat.
> No requirements for special characters or not, just long well randomized passwords, or more aptly, passphrases.
I get your point, but these are incompatible thoughts: well-randomized requires certain levels of variation or it isn't well-randomized.
Well randomized as in not your daughter’s name and her birthday as a password. But I get what you mean. Diceware passwords can provide “sufficiently random” passphrases that, if the end user chooses, does not have to have any numbers or special characters.
For the first part, yes at some point in the future, any password n-1 will be in the database. Getting users to get used to generating 20+ character strong passwords is a challenge today. Once we can solve that, through education, we can then move beyond passwords and single factor authentication.
Wow, to each their own! For me this would be a nightmare and just lead to confusion as I would eventually find the distinction between the previous password and the latest one to be murky.
I mean do not require passwords to be reset every 30,60,90 days etc. Ideally you would only force a password reset if they fell for a phishing attack or there was a breach of the hashed password database/auth system.
It also doesn't help that the complexity rules are inversely proportional to the importance of the application.
My former mortgage company's password requirements were 8 characters max, no special characters.
The app for scheduling appointments at my barber (no payment info) requires a minimum 12 character password with 2 or more special characters, 2 or more uppercase characters and 2 or more numbers.
I hate MFA. I get the "need", but it's a) generally shittily implemented, and c) frequently manipulated/enforced not for the right reasons (notably to force you to surrender your phone number)
I actually kind of like TOTP, since I can choose the implementation I want to use, and make backups, and so on. I loathe having to use any kind of bespoke MFA app, and I just resent the use of SMS for MFA.
The worst is when some forms set rules but prevent the user from pasting a string into the duplicate field for verification. If this is meant to prevent user error in case of a typo in the first field, then it also thwarts many of us using password managers. Somehow my browser can auto-generate and enter a password, but I can’t. That’s a work-around, but it’s irksome anyway.
On another note, a more constructive metric for password security on a basic website account would be to set a complexity standard that allows multiple ways to get there. A haiku of approximately 60 plain characters, for example, should be as secure as a 30 character alphanumeric string, at least when it comes to brute forcing. It seems to me like plenty of weak passwords could be created to eke out the minimum requirements for a lot of sites, so this standard lends a false sense of security, especially when any password is recycled.
English has about 1 bit per character of entropy so if you type a normal expression it is going to give you ~60 bits of entropy. Random words will give you something like 2-3 bits per character so ~120-180 bits for a 60 character string. Random alphanumeric strings have about 5.95 bits of entropy so you get 178 bits from 30 of them.
So your comparison is somewhat right but only with an annoying definition of haiku and dictionary of words. However, a less good scheme should still be fine
I had a talk with the head of security at my credit union and told him I was within this much distance of ending my relationship with them over the fact that their password rules were so tough.
I pointed out that there were some banks that had let me keep the same (securely generated) password for 15 years.
American Express tried to sell me on a deposit account to go with my card but they told me I'd need to make a new account to log in. I told them that one reason I kept my AmEx was that they didn't make me change my password every time I wanted to log in and if I had to add a second login it wasn't worth it to me.
To verify, you're using a password manager? Because it's hard to imagine someone getting upset over having to just update an entry, and obviously the bank can't tell you not to use a password to unlock your own vault.
And I can't imagine someone memorizing a password for a bank login only, and never using that in other locations. The internet requires so many accounts to manage... If you did reuse your password then your bank login would be very vulnerable to credential stuffing.
I use securely generated passwords based on a cryptographic hash.
I don't use a "password manager". Someday 10^8 people who use a password manager are going to get their passwords stolen in one night and I'm not going to be one of them.
Most password manager ecosystems consider this vector. They're either zero knowledge (bitwarden, lastpass ...), local(keypass, pass, buttercup ...), or are vulnerable in the way you describe and suck.
Hashing is sure an interesting way to create passwords. I've considered it as well. I liked that it protects you from credential stuffing and it's stateless. But I found it hit practical roadblocks I couldn't route around:
* you need a plaintext that wont change at the site, but will change across sites. URL is most common, but URL's can change.
* if that site does have password requirements and your digest fails to meet those requirements, you have to either iterate or alter your plaintext (and remember) or alter your digest (changes everything), or alter for that specific site (and remember).
* sites often have password rotation requirements because users frequently use bad passwords across sites and that basically forces you to remember state.
* If you store any of this state, it's no longer stateless and you hit all the problems of syncing across devices and so on and so forth.
We used to ask our users 90% of the standard password requirements (min length 8, 1 special character, 1 digit, 1 capital etc). The result was a lot of people forgetting their password and having a really bad first impression. We were following "best practices" but the user didn't care.
In the end, we took out all the requirements except one: password must be 8 characters long. While we knew this wasn't recommended, especially for a private note taking app, it was a necessary choice because a lot of people either just modified their old passwords or used new ones which they forgot and got locked out. Good security but...if you also get locked out, what's the point? As for people who used password managers, it doesn't matter either way.
A lot of people sign up just to try out the app. Nothing serious. Nothing too critical. If they get locked out after their first usage, it's goodbye from them. I think there are a few things apps can do to improve security without annoying the user too much:
1. Show user a notice inside the app if the password is below a certain strength threshold, recommending them to change it.
2. If the password is reused or compromised, show a permanent warning either on startup or somewhere noticeable inside the app.
3. Promote use of password managers during sign up (and other places)
Ultimately, it should be up to the user to decide if they really want to change their password or risk having their account comprised.
None of these are tested though so I am not sure what the UX would be...
It would have been really nice if there had been an RFC or ISO standard for password composition. NIST 800-63B is probably the best advice available, but few people follow it and industry regulations (PCI) typically violate it.
1. Why don't passworded websites provide their own password generators? There's "secure" entropy generation available to JavaScript, e.g. `Crypto.getRandomValues(Uint8Array)`.
2. Shouldn't the only variable for password generation be entropy/information?
An easy way is to take the character set and convert the input string to binary. Once you reach a specified information level (say 256 bits), then the password could be considered sufficient.
I believe this doesn’t account for dictionary-based attacks. “qwerty secret 123456” may even have decent entropy in ascii space, but can be bruteforced in minutes because these words go first in the weighted list. (Not a security expert)
Personally, because I do not want a repeat of the great toilet paper escalation of 1984.
I used to buy toilet paper in individual rolls. I'd buy a couple rolls, and when I was on the last roll I'd make a mental not to myself to buy a couple more rolls next time I went grocery shopping.
One day, when I was on my last roll, I ate some bad fast food which left my digestive system in a state that one roll was not sufficient to handle. With much effort I was able to regain sufficient control for a very hasty trip to the convenience store.
From then on, I bought my TP in four packs, and put "get more TP" on my list whenever I had finished two rolls from the current pack.
Alas, another bad fast food experience managed to defeat even that, although I was again able to barely make an emergency trip to the store safely.
So I upped it to buying two 4 packs--but it was too late. I felt nervous even with 8 rolls on hand, so I started making sure I had 12 rolls all the time. Then as soon as I opened a pack I'd get an urge to buy more TP.
Every trip to the store I'd buy some TP.
It took some effort but I managed to realize I had gone off the deep end and bring myself back to more normal TP acquisition habits.
I'm afraid that the if I get a hardware token and a backup token, the first time something happens to the main token I'll end going down that same path I did with TP and end up with a couple dozen tokens.
Nothing is preventing either OS from implementing it, either as a platform authenticator or via NFC, USB or Bluetooth support for external authenticators.
Leave a small one connected to her computer (I assume she always uses the same one). The web browser prompts "Now touch your security key", and the light is flashing.
It's also a good defence againt phishing, as the key won't authenticate against a phishing site.
You haven't met her, she's an utterly horrid racist bigot terrible human. I stopped talking to her years ago. Hence why I wouldn't wish anyone to ever have to explain a hardware token to her.
Actually, it's not just paranoia, also convenience. Qubes allows very convenient separation of different parts of your digital life, like personal files/apps from working ones and from random internet surfing. Also, IMHO it's more convenient to copy-paste passwords without an actual password manager. More details: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
> Were you ever concerned about opening your online banking/entering your credit card in the same browser where you go to random websites?
Nope. This is from the late 90's when we started entering credit cards and people thought it would be unsafe. In reality, the credit card companies have covered these charges forever now. Otherwise, we wouldn't be using them today.
> Are you tired of remembering tens of complicated passwords?
Tens? I have hundreds and I don't know a single one, because I already use a password manger. What an odd thing to pitch.
I could keep going, but I really don't like how that pitch deck is just trying to cater to made up fears.
Bad sanitization, or fear thereof. You should not be inserting raw passwords into databases, nor should you be interpolating raw queries, but people used to, all the time, so these restrictions may have stuck.
But yeah it does not bode well for their security appearance.
I've simplified the rules I enforce because it was just getting out of hand. I enforce a reasonably long minimum length, and enforce a limit on number of repeated characters in a row (so someone can't set a password of "aaaaaaaaaaaaaaaa")
My fav is when it says "your password is too short" when it actually means "we didn't think anyone would try a password longer than 12 characters and your 48 character password messed up our code."
I use a password scrambler that generates a unique N-character string for every page. It's close to as much entropy as a one-time pad (technically, there is an underlying algorithm, so it could be reverse-engineered... But it'd require stealing my pass from several sites to start attacking it).
... except the sites that require a capital letter and an excalamation point. Those I sign into with "A<some random N-digits>!".
Good job, site designers. You've done nothing to improve security, but you have annoyed the hell out of me.
Can anyone explain to me why even new products have a maximum character limit? I frequently see 16 or 20 maximum characters. If you're hashing the password, why does it matter?
Although 16 or 20 characters is too less, I can't think of an efficient and user-friendly way to allow arbitrary lengths. What if a user inputs a password with 604462909807314587353087 characters?
If your client is doing the hashing, it will get stuck or seem to take too much time to submit. If your backend is doing the hashing then you would need to send too much data over the internet, again killing the user experience.
I think 256 or 512 characters should be a sensible limit.
PS: 604462909807314587353087 is a Mersenne prime ;)
If it's a bank, it's because the 40 year old database they first used to first digitize their 150-year-old accounts had a maximum character limit (which is why you sometimes see 8 character maximum passwords). Old accounts that generate money just by sitting around are also the reason they never need to upgrade anything and can make changes at a snail's pace.
Having spent the last weekend trying to explain the arcane rules of 1Password to my mother, I can completely relate to this post. When things are overly complicated people start to work around them ... store master passwords and other codes in local files because it is a giant pain to enter them.
Corporate level password security should not be enforced on individual users who don't have IT support to keep their systems working cleanly.
Every time I run into this, I remember meetings where a dumbass engineer would convince a clueless PM that something was necessary. It seems too specific to be thought up by a non-engineer.
I have no way of knowing this, but I do think companies with dumb password rules have poor talent.
I need to start a list of companies with dumb password rules, but I rarely create new accounts so by the time I get annoyed, I’m distracted onto something else.
I used to have those: 8-24 characters among which 1 uppercase/lowercase, 1 special character among a whitelist, and renew that every 2 months. At renewal, must be different from all your previous passwords and the new password must be at least 3 character different from last one. SSH keys can't be used per security policy and the same rule has been applied to the password manager.
A pain.
And yes the most annoying is that it's never the same rules, and I resort to using Keepass or worse, my browser password-remembering system (stores passwords to Google/Mozilla servers)
Is bruteforcing passwords still a thing nowadays? Once in a while I tend to forget my Wikipedia account password and after a couple of failed attempts I get shown a captcha.
On another day, I got locked out of my own account because I was trying to log in using another mobile device with another SIM in another country.
> and the new password must be at least 3 character different from last one.
Does this sort of rule imply that they are saving passwords whole (either plaintext or encrypted, as opposed to hashed)? I can understand "can't match your last N passwords" cause that's just saving old hash entries. But editdistance(old, new) < 3 implies you know the string value somewhere.
Not necessarily, I forgot to mention that when changing your password through their UI you still have to enter your old password. So it's safe to assume that the string comparison is made at form submission. For history rule I don't want to imagine it being implemented otherwise.
Not many places will try a brute force attack directly on a login interface, but if your database is leaked the definitely. Nothing to rate limit an attacker then
I also hate when they force you to change passwords from time to time and forbid you to set one of your previous passwords. One particular offender is russian website HeadHunter [1].
I hope such people will go to very special hell after they die.
Extra fun with organizations that use single sign on. Change your pc login and now your phone has the wrong wifi credentials. Let it attempt to connect too many times and your account is disabled.
I've asked IT people that set these policies to tell me their previous password -- after all, they changed it to something completely different, as per policy, right??
not a password rule but: i use a password length of > 40 characters because why not? signing up for paypal worked with that no problemo until i had to sign in again and the login input ignored everything north of 20 characters or so. It worked after removing the maxlength attribute :(
Once I was asked to implement a system that applied password rules with a few heuristics. If the password was under 12 characters, then it required numbers, special characters and so on. Over that, it required only a number in it. If you went over 16 (or 18, I don't remember exactly) characters, there were no rules.
The front-end explained how the whole system worked and gave the user tips on how they can make their password more secure, heavily promoting phrases as passwords.
My friend who is still involved in the project told me a few months ago that they send out satisfaction forms to users, and some users mentioned that thanks to the service they now know how to prepare passwords that are safer and easier to remember.
Is it password rules he hates or the UX around the password rules?
I just read the post and if the system response had been "You must have 2 numbers in your password", well then, okay, easy enough to do. An annoyance rather than a hatred.
Not that I think password rules are great. They can, if used poorly, unnecessarily constrain the space of passwords. But they are often required by certain compliance situations.
I love my password manager and think everyone should use one, myself.
Another alternative is the FIDO passwordless technologies that are being rolled out more and more. Though I saw a tweet the other day that said "Biometric identification is a username not a password" that made me think about that.
This is why current standards say password complexity rules are a terrible idea (or officially a SHOULD NOT), and have for a while. I’m baffled as to why these rules endure.
Password rules often happen because a customer who had a lot of money told somebody who wanted that money that they wanted these specific password rules.
"Oh, you require us to implement these stupid password rules you came up with, in order for us to get your 20 million dollars? We'll have it implemented by end of the week."
And this is also why those rules never seem to change, or only get worse. Nobody remembers when or why those rules were implemented, and nobody is going to risk potential business just to make passwords easier to use or more secure. Product security is always second to short-term gains and job security.
If I have an alphabet of size x and a password of length n there are x^n possibilities. What results in a larger set -- adding 1 more character to the alphabet or adding one to the length; i.e. which is bigger (x + 1)^n or x^(n+1)?
I like the rule that Nextcloud uses by default: rather than requiring character class minimums or anything like that, it makes sure that the password you picked isn't one of the top 1,000,000 most commonly used passwords.
An HTML input field can give your password generator a hint, right? Never looked at it closely but had the impression e.g. Safari's generator could adapt to certain rules and that they were somehow described in the HTML.
Interesting, that's different from what Safari supports (see sibling comment).
I wonder what the algorithm is to generate a good password that matches a given regex. Also there's a potential problem with patterns that are wrong or contain errors, that may result in simple and insecure passwords. I don't see how Mozilla's approach is better than Safari's.
The comments on this blog post make me cringe. Is there a correlation between Schneier followers and self-professed experts? Consider the clever fellow who has "logically" concluded that consistent password rules would constitute "putting all your eggs in one basket" and hence weaken security. Folks: a limited character set isn't a liability if you can just increase the number of characters correspondingly. If you're allowed a 64 character password, you can reduce the character set to [0-9A-F] and still have 2^256 possibilities.
Password rules that make me turn off options on my password generator frustrate me to no end. It just happened on a bank site. I had to turn off special characters so they would accept the password.
The worst one I've experienced recently is HSBC's online banking. It requires you to set up a 6-10 digit PIN number on the phone and tells you that you must memorise it, not write it down. Yeah right. Like I'm going to commit a 6 digit number to memory while on the phone. This is one where I bet at least half of logins are the "forgot my password" type (the other half probably wrote it down).
Sometimes banks don't even adhere to their own rules. I have no idea what the rules are for CitizensOne (which does financing for Apple). I enter a password that turns all of the checks green, but it's still not good enough.
I hate a lot of the new paradigms with passwords. This includes things like letting you sign up for an account and placing you in an in-between state until your email is verified (with no indication this is the case until you check your email). Or moving login password entry to a separate screen from entering the username.
For the vast majority of websites password rules are unnecessary.
I only care about icloud and gmail, amazon and paypal. I don’t care if my reddit account is “hacked”. Or HN. Or random webshops or whatever. I hate being forced to use strong passwords for accounts I don’t care about.
What cannot be ignored is the fact that many people will attempt to use the same password for multiple sites if given the chance.
Furthermore, some of those shops may contain identifiable information which could be problematic.
Personally, i take a slightly different approach: i don't care about almost any of my passwords... because they're randomly generated!
KeePass gives you very nice choices in regards to this, when i write down a new account into the password protected DB for a site that I'm about to use, it allows me to both generate a random password for it, as well as specify additional generation rules if needed (e.g. longer or shorter).
That way every password is unique and reasonably secure. In combination with Nextcloud and regular backups to another HDD (and manual ones to SD cards) the password safe is also persisted across my own devices and other mediums, whilst having an even longer password of its own, the only one that i need to memorize (and write down on a piece of paper that i could optionally give to someone I trust, since i once forgot my phone's lock screen pattern years ago).
This, when coupled with separate e-mail accounts (e.g. one for professional matters, a few for increasingly more spammy or throwaway purposes) and something like uBlock Origin and a VPN does make my online browsing experience a bit more tolerable and secure.
Well yes, that’s exactly my point. I _want_ to be able to reuse crappy passwords because just typing a password is still simpler than dealing with password managers.
A few weeks ago I signed up for a local credit union and received a membership packet in my email including a reminder of what my password is. I called them to tell them about this security flaw and received a single dollar as a bug bounty, but they still haven't changed it.
My internet-first bank’s passwords are limited to 8 characters. I'd take password rules over this idiocy any day. I reported it maybe 5 years ago and of course radio silence. I bet they plaintext it.
Oh and of course I also have literally 4 different digit-based pins to do operations.
I hate those requirements, but if at least they were enumerated in a programmatic manner, for example through a RegEx or password field parameters then a password manager could read those and offer a generated password that fits those requirements.
If you're going that far you might as well ask browser makers to make a non-awful UI for client certificates and avoid the whole password problem in the first place.
Well I suppose this is trying to avoid people using obvious passwords but I'm not ever sure it works. At least password rotation ( = xxx1, xxx2 etc) has gone out of favour.
Ideally we need AI to say "No! Not your wife's birthday!".
If your company accepts credit card transactions you have to comply with certification rules that require frequent password resets. That comes with a volume discount on post-its
> At least password rotation ( = xxx1, xxx2 etc) has gone out of favour.
Not everywhere. Some contracts our org is engaged with specifies yearly password rotations for our single sign on system. Now guess how many folks rotate their passwords.
A hashed (and for correctness, salted) password will always have the same number of characters output from the hash whether the input password has one, ten, sixteen, hundred, or million characters.
Character limits are a symptom that the company wants to store some form of the password that hasn't been correctly and securely hashed.
They can be a defense against DOS vectors, too. Though if that's the only reason, you can usually make the limit high enough that almost no actual person will ever hit it.
NIST 800-63B [1] has some good guidelines on password rules, one of them being low complexity:
"As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.
Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.
Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets."
I have seen sites where I can happily enter a 25 char long random string but then you can’t log in. A lot of trial end error and it turns out they simply truncate at 16 chars :s
I signed up on coinmarkercap and used bitwarden to set a 16 words passphrase as my password. Every time I log in I'm asked to change it because it's unsafe.
Complex password rules haven’t been shown to improve security in any way. They have been proven to torpedo security, e.g. they make people forget so they do blatantly-insecure things like writing passwords down or relying more frequently on things that reduce account security like having to reset the password entirely through simple E-mails or codes, etc.
And speaking of banks, I am livid that so many of my financial accounts essentially require absolutely terrible passwords. A lot of them don’t support E-mail for log-in either.
Meanwhile, your basic “correct horse battery staple” [1] works pretty well.
So... what's all this about XKCD's password scheme not being ok? I found the argument pretty compelling, in that even if you presumed the attacker knew how you generated your password, there would be too much entropy to work out what it was.
In another blog post, linked from this one, Bruce says that the XKCD scheme of stringing together a series of words is no longer safe:
> Modern password crackers combine different words from their dictionaries. This is why the oft-cited XKCD scheme for generating passwords — string together individual words like “correcthorsebatterystaple” — is no longer good advice. The password crackers are on to this trick.
Is that true? Or does it just mean we need more words in the password?
Yes, more words is ideal. The ideal authentication scheme is that the attacker knows absolutely the system you use but it is still secure within realistic time constraints. So using randomly generated words from a sufficiently long list (such as this one https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt ) and as long as the hashing algorithm is sufficiently complex, then you are mathematically protected with a minimum number of words.
For example using a 6 word pass phrase from the above 10000 word list would on average require 5e23 attempts to correctly guess it. For credential stuffing this is absolutely impractical. For cracking a leaked password hash we can figure out how secure it is.
We assume that the service properly salts the passwords, so a rainbow table can't be used. If salted bcrypt hashes are used, a benchmarked 4-gpu rig did ~160 hashes/s, so even assuming a nation-state with 1E9 times as much computing power, we get 1.6e11 hashes/s, so this gives us on average 3.1e12 seconds to crack, which is about 100,000 years. Which means that no-one (pre-quantum) can crack that password.
If I understand it correctly, a 4-word password like in XKCD would require about 100,000 rig-years to crack. Do you think that is too low of a safety margin? Or is the problem that most people's word list may be less than 10K words?
In this day and age, nearly all instances of password usage can be replaced by public key cryptography for a vastly improved user experience. And, of course, for a net gain in security.
There's a significant legal difference between keys and passwords in the US: you can't be legally compelled to divulge the latter. And I imagine that based on the principle of non-self-incrimination in other countries' laws, it may very well be very similar in other countries as well.
Today Brave browser launched a new version of their built-in crypto wallet.
There is an option to keep using the same password in the new version, when I select that option, an error message comes up saying my password is not secure[0], even though it is[1].
Basically the Brave devs can't even agree with their past selves about password security.
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.