I hate password rules
schneier.com
schneier.com
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.
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.
This is more of an NK/non-state-actor "burn it all down" move.
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.
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.
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.
Be inquisitive and aware. I think you have this covered by reading hacker news and having an interest in the subject. I've enjoyed reading Slashdot (while it was good) before switching to hacker news, but it's also been a vital ongoing education for me. Comments often having more value than the original article. Being knowledgeable of security risks and common exploits helps prevent falling victim to them.
https://hn.algolia.com/?q=identity+theft
https://www.newyorksecuritieslawyersblog.com/my-money-was-st... Good read on how someone lost their account.
Steps for securing accounts. Confirm that you are notified of email address changes. Confirm that you are notified of any transactions on the account. Setting up a canary if possible. I set up an email alert on a common event. So, I basically I get an email from the company daily, and this confirms that my email address has not been changed. If you are certain you will be contacted if your email address changes then this is not necessary as the email change notification acts as the warning. Have email and phone of account representative that you can contact if there is a problem with the account.
That should be all that is necessary. Now, the day comes, someone has changed your email address. Maybe they even did some transactions. Stay calm, stay professional. Contact your account representative and notify them of the problem. Be able to identify yourself, call from a phone number associated with the account (or previously associated). Be able to answer security questions. Account representative should be able to freeze the account and resolve any issues. If you're satisfied with the phone call, great. If you're in anyway nervous about the resolution, then create a paper trail, send a letter that documents the issue and your attempts to resolve it.
A quick disclaimer, I'm not an expert. Adjust anything to fit your own needs.
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.
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.
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).
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.
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.
>
> - Bunk
Sometimes being the nice guy full of good faith doesn't pay. Literally
It's high time for this thing to die. sudo supports this natively since forever:
$ sudo -iOne question, if I may, could there be any situation (that you can think of, off the top of your head) where using sudo -i would be worse then "sudo su -"
[0] - https://www.maketecheasier.com/differences-between-su-sudo-s...
'sudo -i' opens a root login shell.
I usually just do `sudo zsh` :-)
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.
(If I remember correctly just putting SSHd in the highest debug level, which logs every byte received, did work to intercept passwords)
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.
[1] - https://www.sans.org/blog/time-for-password-expiration-to-di...
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.
A diceware password of 6 words has an incredible amount of entropy. How would you ever brute force its hash?
> What matters is online guessing and that is severely limited in the amount of attempts.
Belt and suspenders.
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.
Ok, but that's a very Windows-specific issue. I don't know of any other widely-deployed system vulnerable to pass-the-hash.
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.
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.
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.
E.g. "correct battery horse staple" might become "Correct use of a battery supports the a horse in its staple diet".
Thereby keeping the same bits of randomness while making a memorable phrase.
"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.
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.
[0]: https://www.merriam-webster.com/help/faq-how-many-english-wo...
* Require more than 8 characters
* Don't require special characters
* Don't force the user to reset their password
* Do check for compromised passwords
* Require MFA
* ...
All very sensible.
https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
openssl rand -hex 8 | sed 's/..../&-/g;s/-$//'
openssl rand -hex 8 | sed 's/..../&-/g;s/-$//;y/abcdef/ABCDEF/It's either that or pick a random dictionary word.
grep --perl-regexp '^[a-z]{4,7}$' /usr/share/dict/words | \
shuf -n 5 | tr '\n' ' '
bless clench moraine shuf /nix/store/ny99jkpl3r9zgkkdv5apprzl18i8rb4m-scowl-2019.10.06/share/dict/wbritish.txt \
| grep '^[A-Za-z]\+$' \
| head -n 3 \
| sed -e 's|\(.\)\(.*\)|\u\1\2|g' \
| tr -d '\n' \
| sed -e 's|$|\n|g'
OmegasInsentientPantheons
Many people are, contrary to all pretense, mostly paid to not give any actual fucks.
But I was relieved to find my CC provider calling me to verify I was just up to shenanigans.
I was also curious how many thieves they had run across that signed for purchases as stolen in large cap letters.
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 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.
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.
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.
- authenticating using a 'client number' (different from your 'account number', sent to you once by a physical mail you lost long ago) combined with a 4-to-6 digit (numeric-only) passcode that you have to input on a virtual keyboard
- confirming web-initiated transactions via their app on your phone... but when it's app-initiated, well, you don't have to confirm anything other than just retype your passcode
- in the end, introducing some awfully long delays between some actions e.g. creating a new beneficiary and being able to send money to her... because 'it's for your own protection that we degrade your client experience'
This just bugs me.
> 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?
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.
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.)
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.
https://users.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwo...
Here's the direct link to NIST 800-63B - it's really a fantastic document with sensible recommendations on every authentication method: https://pages.nist.gov/800-63-3/sp800-63b.html
The tedious part of NIST's password requirements is "Do check for compromised passwords"
HaveIBeenPwned exists, but most open source tools don't leverage it and this requirement goes overlooked.
At Clerk, we follow NIST guidelines by default, including integration with HIBP. In a world with password reuse and "credential stuffing" attacks, this feature is critical to securing your user accounts (unless you go full passwordless, but that has its own tradeoffs).
A portion of our customers will ask us about NIST, but it's slimmer than I would have expected.
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.
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.
It's clueless, I know, but you'd be amazed at the percentage of people that think disclosing something is a disclaimer (sigh!)
Using some kind of OTP authenticator app or device and __NOT__ SMS!
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.
So no, SMS is not perfectly good. it's crap and needs to die in a fire.
I know that frequencies are different in some parts.
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.
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.
We desperately need to have better MFA options if we're going to require it from users.
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.
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.
Every service of course has the option to print backup keys. Maintaining those (in secure offsite location) over years takes some effort.
America is strange, any rando nutjob should have access to firearms but US corporations are terrified of being sued.
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.
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.
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!
But allow at least 2 hardware keys and not only SMS.
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.
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.
The word "idea" appears list of 850 common words:
https://en.wiktionary.org/wiki/Appendix:Basic_English_word_l...
"fish" is ranked #1453 in the list of lemmas linked from here:
https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#To...
We can arithmetically encode the choice of two words from dictionaries of 1000 and 1500, respectively, using 21 bits.
The two bits estimate is a somewhat pessimistic lower bound.
That was likely fixed a long time ago, but I'm still wary of increasing my Microsoft passwords past 12 characters.
Bingo. Super frustrating.
See also this comment: https://news.ycombinator.com/item?id=24827031
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 :@
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.
Worse than that must be the sudden realization that your bank probably saves your password in plain text somewhere.
hash($password) == $storedhash
hash(substr($password,0,20)) == $storedhash
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.
You answered your own question.
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.
For me, Fidelity is a non-starter, for reasons that are none of your business.
It's nice that you like Fidelity. But it's a good idea to recognize that your finances and life situation are unique to you.
Lots of people talk about finances online. See r/personalfinance or r/financialindependence. It’s a good way to learn.
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.
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)
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.
Apparently there is a limit of 20 characters for the password. The password I set was 21 characters (which was accepted without error).
When I tried to log in with this password, the login was rejected.
However if I log in with just the first 20 characters of the password, it works.
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.
(This isn't to excuse silent truncation.)
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.
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.
I very rarely have to manually type in a password.
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.
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.
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
https://github.com/redacted/XKCD-password-generator
Not sure how many bits a "good" password should be nowadays.
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.
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.
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.
Now, sites that treat email addresses as case sensitive - those are evil.
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.
(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.)
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.
Dicks.
Disk encryption (ie, BitLocker) is supposed to prevent that from working.
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.
IT shouldn't be able to tell anything about plaintext password similarity beyond equals or not-equals.
Of course, our company-wide email was down for 2-3 months a couple years ago due to a ransomware infection, so our IT isn't stellar. So who knows!
But at the time of the password change, no, assuming password changing requires you to enter your current password as well.
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.
(Which - in my limited understanding of infosec - would be only marginally better than plaintext, but I can be wrong.)
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
But yeah, frequent password rotation is still bad.
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.
I'm only half-joking sadly, people just don't understand why password exist in the first place, so they comply maliciously.
I suppose someone somewhere has a maximum length that is hard to brute force, but I've never seen it.
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.
This has been a greatly appreciated plugin for these scenarios (it's on Firefox as well)
Alternatively, my password manager does have a decent "autotype" tool when all else fails.
$0.value = "asd";
javascript:void(document.documentElement.addEventListener('keydown',e=>e.keyCode==9&&e.stopPropagation(),true),document.documentElement.addEventListener('copy',e=>e.stopPropagation(),true),document.documentElement.addEventListener('paste',e=>e.stopPropagation(),true))
You just improved my day.
Thanks!
…though not as annoying as sites that don’t let you copy / paste into their login fields.
Now I need to drag my tab to another window and type it out (twice) and then read and confirm it. If I'm on mobile - forget it.
I'm far more likely to get my account number _and_ confirmation wrong if I type them rather than copy/pasting them in from my bank's site.
about:config
dom.event.clipboardevents.enabled = falsehttps://utcc.utoronto.ca/~cks/space/blog/web/FirefoxClipboar...
; Type in the clipboard
^!v::
MyClip = %clipboard%
StringReplace, MyClip, MyClip, `r, , All
SendRaw %MyClip%
return
AHK has a v2 that attempts to clean up its scripting language, but it's been in beta for a long time.
Here's a gif of it in action: http://files.jjcm.org/password.gif
And an example webcomponent that implements this: https://github.com/jjcm/soci-frontend/blob/master/components...
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."
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.
if your password was qwerty123456, it might have allowed you in with qwerty1234999
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.
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.
With that and a well-known endpoint for changing passwords (not quite the same thing as what you’re describing; https://w3c.github.io/webappsec-change-password-url/) we are moving in that direction.
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.
[0]:https://haveibeenpwned.com/API/v3 [1]:https://en.wikipedia.org/wiki/Diceware?wprov=sfti1
> 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"
That would make a lot of people's life terrible. I reset my passwords very frequently (almost every time I log out of a website)
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.
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.
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.
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.
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 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.
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 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.
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.
What do you use for your plaintext anyway?
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...
For example:
Choose your password: A safe password contains many different characters, for example a sentence.
Something like: https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...
2. Shouldn't the only variable for password generation be entropy/information?
Here's a 256 bit password:
1NH8O3C3GH33FNQHM3B7VFKIQ95EMD-QLPOFPPYJ54NCFXMOB3
How could you know?
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.
https://convert.zamicol.com/?in=1NH8O3C3GH33FNQHM3B7VFKIQ95E...
3. Combined, I'd imagine a decent user experience.
4. I can't wait for public key authentication to kill passwords.
Then, if you have special password rules, the manager could generate a strong password that fits into the defined rules.
Of course, getting rid of passwords entirely, is the best option (ie: using a decentralized sso solution).
What if I am storing my passwords in clear text in a Qubes OS [0] virtual machine with no network?
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.
Hardware tokens have only managed to prove that hardware tokens won't ever take off due to their inherent limitations and liabilities.
Are you going to force people to use specific smartphones?
Even then, nothing keeps the vendors of alternative smartphone OSes from implementing a FIDO platform authenticator.
Those that fight the duopoly and allow user freedom: Librem 5 and Pinephone.
I really hope that it could use an open standard. Then, it's probably fine.
https://fidoalliance.org/fido2/
Nothing is preventing either OS from implementing it, either as a platform authenticator or via NFC, USB or Bluetooth support for external authenticators.
(not that a password manager is really any better in this case)
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.
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.
Another way to handle these rare events is to have an emergency-only 12-pack and then go with your regular a couple of rolls mode.
And how could this possibly be checked except by allowing any random website that wants to use passwords to pwn my computer?
But yeah it does not bode well for their security appearance.
That's 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.
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 ;)
Corporate level password security should not be enforced on individual users who don't have IT support to keep their systems working cleanly.
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.
You were heard: https://github.com/duffn/dumb-password-rules
$ openssl rand -base64 xx
The minimum character length was 50! That's a subtle way of essentially forcing you to use a password manager of some sort
I'm pretty sure this approach will eventually screw me over. I don't know how but it feels like it'll happen
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.
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.
I hope such people will go to very special hell after they die.
[1]: https://hh.ru
No one has ever agreed to this.
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.
"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.
I've created a CodeSandbox example of it being used.[2] 1Password does honour it.
[1] https://developer.apple.com/password-rules/ [2] https://codesandbox.io/s/password-rules-demo-029h5
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.
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).
Here's more info about KeePass: https://keepass.info/
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.
200 Get another dollar
300 Goto 100
Oh and of course I also have literally 4 different digit-based pins to do operations.
• https://github.com/whatwg/html/issues/3518
• https://developer.apple.com/documentation/security/password_...
Ideally we need AI to say "No! Not your wife's birthday!".
Character limits are a symptom that the company wants to store some form of the password that hasn't been correctly and securely hashed.
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.
"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."
Changed the algorithm a few times, to make it at least pass the password rules of common websites such as Facebook, Google, etc.
I think it’s just better if their system provides a little complexity indicator.
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.
I'm going to do some quick googling about this.
edit: oh goodness, this appears to be a holy war, https://security.stackexchange.com/questions/62832/is-the-of...
I'll just plant my flag and wish the rest of you luck, use a password manager.
Many users used this strategy to secure their cryptocurrency 'brain' wallets only to have the funds quickly stolen.
Anyway, enjoy my bank account xx
> 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?
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.
I hate passwords altogether.
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.
Why can I connect to a remote server without using any password, but still need one to read the mail?
Assuming for a moment that you live in the US, do you count Fifth Amendment issues into that experience?
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.