1. Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don't help that much. It's better to allow people to use pass phrases.
2. Stop it with password expiration. That was an old idea for an old way we used computers. Today, don't make people change their passwords unless there's indication of compromise.
3. Let people use password managers. This is how we deal with all the passwords we need.
[0]: https://www.schneier.com/blog/archives/2017/10/changes_in_pa...
If that’s actually true, then most companies hands are tied until those payment agencies update their requirements.
There is no incentive for change. Look what happened with Equifax.
The trick is figuring out the boundary of the systems that are subject to PCI.
We’ve been using a compensating control of “our password policy is exactly NIST SP 800-63B (2017) plus two more characters in Min length” for our PCI audits since the revision was published in 2017.
It’s been accepted three times so far.
If you spend an hour a month on something that's required by policy and in your opinion shouldn't be, then six hours invested finding the person who sets that policy and explaining why it's a terrible idea may free up net six extra hours of your life within a year.
That story where the guy comes down a mountain with a stone tablet with Ten Commandments carved into it is (a) a myth and (b) no kind of a way to set effective policy. People can't even agree on what his Ten Commandments were, let alone on following them.
I hope forced expiry will be gone from next PCI revision anyway.
My startup is implementing most of the NIST rec’s with the help of projects like zxcvbn but we would like to also start doing breach list comparisons so figured I’d ask.
Maybe some sort of simple USB dongle (like a yubikey) could be fed by the phone via bluetooth or nfc to do this?
Login would be:
* scan QR code, sees https:/ /megacorp.com/login?session=hexhexhex
* Password manager asks that you want to log in with account X.
* Negotiates with auth service
* Website recieves your confirmed token via websocket
* You're logged in.
And, of course, if you don't have an account, the password manager can get you started creating one.
Instead, the better solution would be, you point your phone to a QR code on the computer screen, press “confirm”, the computer is magically logged in, until you then press “log out” on your phone and the computer is logged out.
So while you are logged in, the attacker can do anything they want.
They initially rolled it out as a 2FA option, then as an optional for 1FA.
Unfortunately I don't see the need to actually fill and type passwords going away any time soon.
I'm mostly complaining about having to either:
1) Install the password manager on a computer to fill in passwords. You end up typing the password manager's password into the computer which could compromise the entire database as well as give the computer other information about your accounts and website usage.
2) Otherwise you have a password manager on your phone. You have to view the password and type it into a keyboard. Typing complex passwords is a pain in the butt. It would be nice if the password manager on my phone could just somehow type it for me. Then the only thing that goes into the computer is the exact password I'm trying to use.
That would require each site to implement server-side components to talk to Clef, and most sites have been ice age slow to implement basic TOTP never mind yet another method.
Now, if the big existing OAuth sites, your Google, Facebook, Okta, etc implemented a QR code method like Clef then it might work.
Whoever logged in first would invalidate the hexhexhex token and the second person would need to start another browser session.
It wouldn't be hard to add encrypted password storage to the EspUSB firmware. The difficulty is that you need to know the keyboard layout of the destination computer.
Keyboards don't send a letter "A", they send "shift" + "a". If your computer's language setting is French, or German, or Chinese, etc - things get complicated fast.
To make it worse, passwords need to use special characters (not just a-z). Sure, it's not unreasonable to ask you to change the keyboard layout, because you're on Hacker News and are therefore pretty good with computers. But this would limit an average user.
The other problem is that it types the password as plain text, which is a bit insecure. If I have to carry a dongle and change settings on the client, why not make the dongle do some sophisticated key pair exchange with the client app?
It's a good idea for another EspUSB demo app, but I worry that it couldn't find mass market adoption as a product. Without sales of over 10,000 devices, it's not possible to pay off the FCC certification lab, and I haven't got a solution for that.
I kinda prefer simplicity. What if the dongle breaks, gets lost, or some change in the environment makes it impossible to run the client or perform this sophisticated key pair exchange? Locked out, fun.
My keyboard can generate passwords, but I could generate the same passwords on paper (or, more likely, using a piece of software running on some other device) without ever connecting to the device where I'm going to enter that password.
I also tried kicking the android driver and just using (iirc) usbfs or what is was called so you could implement HID in userspace and repurpose old phones while kicking android. But the vendor kernel stopped compiling :/
This woul imo be a really interesting application to repurpose old android phones.
Or patch the android stuff to add HID support: https://github.com/pelya/android-keyboard-gadget
Your grandpa could use it to secure his crypto wallet.
For a certain sense of "secure". Because fingerprints aren't. Not just because you leave them everywhere, but because the way we examine fingerprints doesn't have a result that is particularly unique.
Not even at the criminal case-law level [0][1].
That fingerprints are unique is an assumption, but it doesn't match our reality. They're useful for eliminating from a known small pool, not matching against a large group.
Many of the elements we match against run in families.
[0] https://mccoll-law.com/attorney-profile/37-general/38-finger...
[1] https://www.telegraph.co.uk/science/2016/03/14/why-your-fing...
The kinds of things that people get put on watchlist for, like where to buy industrial quantities of hydrofluoric acid.
EDIT: If you're on an untrusted device, should you really be putting secrets into it? Maybe not!
Unless they're using Excel functions to generate password{n++} . That'd be clever and yet horrid at the same time.
So my advice is to advise people that they will get resets. To run them through a couple with increasing complexity requirements. Then increase the period between resets dramatically without telling anyone, so 30 days (Still a novelty), 90 days (less fun), 120 days, 360 days.
I suppose it is a password re-education exercise really. I always remind people that they are welcome to change their password whenever they want (then they will never see a forced reset). I also tell them that my single biggest requirement is that they don't use their Facebook password for work!
I will keep password resets, but nothing like the 90 days PCI DSS still insists on.
In legacy systems shared admin credentials are very common, and while working towards individual logins I tend to rotate these often, since a password manager can be used. It is hard to have individual accounts for everyone at an external support company for instance....
My response is that not everyone uses a PM, so the other two points are not moot.
Also, FWIW, I find myself rather uneasy about using a PM, so the other two points aren't moot, at least for me. "One password to rule them all" means that you've created one nice big juicy target that needs to be breached once, versus a bunch of little targets that have to each be breached individually. To take one real-life example, if the TSA wants to rifle through your digital life, it will be much, much harder for them if you don't have a PM.
Newer Windows AD builds have FIDO2 support, so on shiny new computers you _could_ unlock "your" computer (one you've logged into recently) with a FIDO2 USB key, or a fingerprint reader. That's a much nicer way to unlock a computer you use all the time, while not discouraging you from using a nice long password that bad guys would need to guess or steal to get in from a different machine.
It's useless, but not worth my energy to fight.
Just come to the dark side and learn to program and privilege escalate. You'll learn all these practices and how to circumvent them.
Do the other 51% sincerely try to change their passwords? Or maybe they were too scared to report the truth :P
It might be interesting to see how many actually try to sincerely pick that new, secure, password.
Not counting the SSH key passphrases for a lot of stuff...
The other used the name of the company as the root password for all hosts, accessible from anywhere within the offices.
Horses for courses, I guess.
minutes minutes/month minutes/year(hours/year)
1 ~22 ~266(~4.4h)
2 ~44 ~530(~8.8h)
3 ~66 ~792(~13h)
Depends on the password manager. I use Keepass on my phone with the InputStick[0] plugin, for example, and that works great for Windows logins. Even have a macro set up so I can sign in to Windows with one tap.
If I have some previous passwords of yours in hashed form, and you give me a new password, what I can do is try to crack your previous passwords by generating nearby passwords based on the new one.
For instance, if you give me something that ends in a digit, I can substitute the other nine digits into that and try all those passwords against your prior hashes.
...are there any desktop OS's which do integrate well with password managers, for your login password?
By definition, you can't open the password manager until you've logged into the machine. So you'd need to open the password manager on a separate device.
The one exception I can think of is if you're using the password manager built into the system, like Apple's keychain, in which case your login password is basically also your master password. Unfortunately, you then lose the ability to access your passwords on any other company's platform...
This is what the article is talking about, but completely misses in its involved complaints. The best password manager in the world will NOT help you actually login to the computer you're running it on. So everyone at work basically has to have at least two passwords that need to be memorized: The main password to login to the machine, and the unlock password for the password manager.
Forcing these passwords to be impossible to remember is going to be a huge impediment, given how often you end up actually having to type them.
THIS. 10 Times This.
Would somebody be so kind to tell this to the eRA Commons website maintainer of the NIH?
And when you are one it, please tell eBay I don't want to change my PW if they think someone else tried to log into my account based on their shitty Tracking metrics. I mostly switched from Amazon to eBay but the constant PW change request really annoy me. I have one plain vanilla browser with no anti track plug-ins only for eBay.
I once send them a message, that I consider their security guy an idiot, told them to forward him my cell phone number and ask him to give me a call to discuss this PW policy. He never called. :-)
I toyed around with the idea of a password risk score.
Password reuse across accounts (with known breach) = 100% Password reuse across account = 90% Unique external password = 30% Unique internal password = 20%
Divided by password complexity... or something similar.
In this way user is encouraged to maintain good passwords by not being penalised (changing every few months, etc).
Of course, this would require something between service and user, such as a password manager.
CFO no longer has anything to do with IT, MSP was fired... not for this, for leaving admin credentials in JSON file accessible to everyone on a shared drive.
Ah, good times!
But that's because you forced the choice on me, and I'm only willing to work so hard for a Hacker News post. Ideally, you turn it into one coherent story. If I can choose my password, and I usually can after all:
Zaphod Beeblebrox wears 3 hats. He gives 1 to Ford. Why did he do that? He only has 2 heads. Xavier can't read Zaphod's mind now. (Does he even want to?)
ZBw3hHg1tFWdhdt?Hoh2hXcrZmn(Dhewt?)
That's 35. I could have that mostly memorized in a day's relatively normal usage, and definitely have it by a week. I have some rules I apply, like numbers -> their digits, periods are "free" but the other punctuation goes in, etc. Doesn't much matter what your rules are, as long as you're consistent.
Technically, this is less random that a truly random password, because rather than drawing uniformly from the space of possible symbols, you're tilted in the direction of what words can start with and some other things like that. I tend to just make up for that by swinging more entropy at the problem, and trying to work in some Xs and Zs and unusual symbols, and figure that it gets me close enough.
One trick to this: If you find in the first day that you're consistently remembering the phrase differently than you first laid it out, just take the hint and change the password.
Stop using passwords, just use a "pass sentence."
My last few passwords at my previous employer:
"Tim, bring me chicken #15" "Mary, stop looking at me!" "Nothing you can do about 2!" "The coffee here is gross."
Seriously.
That's 68 bits. It's somewhere between 11 and 12 random alphanumeric characters. It's unimaginably weaker than 32 random characters.
A random word is generally worth about 2 to 2.5 random characters. Sometimes that's easier to remember, sometimes it isn't.
And your example passwords are not that strong. A simple algorithm picking words just by rarity could hit "The coffee here is gross." within about 2^50 iterations, and a single consumer GPU can test about 2^48 - 2^52 hashes per day. "the", "here", and "is" are way too common. You only have two moderately random words.
That assumes the attacker knows it's a five word password, and that there are no misspellings, and that these are specifically English dictionary words in dictionary form, how you're capitalizing it, and whether or not you snuck a number or an exclamation mark in the middle. Might as well know your password at this point..
raivoissaankoha NOKANMURIT vejatti 42 cerviidoo fjelleil??
:--)
Not a single dictionary form, and not a single word spelled "correctly", but this sort of phrase is really easy for me to memorize. If you had dictionaries for all four languages involved, you still probably wouldn't get very close unless you also know to inflect these words like spoken/slangish Finnish sans umlauts. Say what, fellow Finns?
The attacker doesn't need to know how many words. They would try 1, then 2, then 3, etc.
Capitalization and tiny modifications are only worth a few bits. They can't get you anywhere near the quality of 32 random alphanumerics.
Your password example is a lot stronger. But even then I don't know if it's better than a full 32 random characters. That would mean every two characters in your password have more randomness than a completely random character with no patterns. That might be true.
I'm not sure I agree with that. There's an infinite number of simple patterns that one could construct, and guessing the right one from the space of all possible patterns could alone exhaust any bruteforce capability. The characters of a random password could be taken as constants that define a simple pattern according to some rule, so you can have as much entropy in the space of such patterns as you have in a randomly generated alphanumeric password; in a manner of speaking, the pattern is part of a password and by itself contributes to entropy (as long as we're talking about patterns with long enough outputs that different patterns don't have much overlap in what they spit out).
If the attacker doesn't have a huge library or eof simple patterns, then making an unbreachable passwords is very simple: just make up a new pattern, they probably won't guess it.
(Dang, now I'm tempted to make a game out of this: write a pattern generator, post a set of parameters in the public along with the md5 of the resulting pattern, and award some monies to the first person to figure it out.)
> The attacker doesn't need to know how many words. They would try 1, then 2, then 3, etc.
Sure. At what point would they exhaust their bruteforce capability or decide that they've probably got the wrong pattern and go for another one?
I hope the next pattern they choose isn't one to four random English dictionary words followed by the number of letters in the resulting phrase, expressed in binary using X for 1 and Y for 0!
> Capitalization and tiny modifications are only worth a few bits.
Five times a few bits quickly adds up though.
> Your password example is a lot stronger. But even then I don't know if it's better than a full 32 random characters. That would mean every two characters in your password have more randomness than a completely random character with no patterns. That might be true.
It's pretty hard to say since I made it up on the spot instead of randomly generating it after specifying a pattern, yeah.
But if you had just five words in different languages and you had to guess the language for each, that is quite a bit of entropy. Not enough to prevent any sort of brute force attack, but we're talking a few dozen bits at least. A quick google search shows that there are around 4000 human languages with at least 1000 speakers (https://www.infoplease.com/askeds/how-many-spoken-languages), that'd be 12 bits per word. You could guess it's got to be one of the most common 100 languages and you'd miss three languages that I used (Norwegian, Finnish, Esperanto), according to this list of top languages by native speakers: https://en.wikipedia.org/wiki/List_of_languages_by_number_of....
Of course not all words are unique across all languages, so a dictionary attack against my pattern could pick the wrong language for some word and still score the right dictionary entry.
Inflection, in the case of Finnish, proves interesting because there are ways to stack different endings and thus you can have hundreds or thousands of variations of a word, by the book. Slang and regional dialects only add to it.
Go in increasing order of difficulty. Or estimated rarity based off of password dumps.
Something like: One character, two characters, one word, one word plus a character, one character plus a word, one modified word, three characters, etc.
"word" being a list of most common words in the united states, or something. Like you said, using many languages screws up dictionary attacks. But most passwords don't do that.
> I hope the next pattern they choose isn't one to four random English dictionary words followed by the number of letters in the resulting phrase, expressed in binary using X for 1 and Y for 0!
That would just be "four words plus five random characters".
Aye.. if you were going to pick the simplest (most bruteforceable) pattern first, you wouldn't want five random characters now, would you? I thought that's the whole point of this exercise :-) Of course I could decide to repeat that bit pattern four times and that adds no entropy if the pattern is assumed to be fixed, but then we get back to having the attacker try guess the right pattern.
Very often in these discussion people don't consider the pattern space at all as part of entropy and they only look at the entropy within the alphabet/words/variations after the pattern is fixed. I'm not sure that's right.
Don't try to outsmart the person cracking the password. Assume whatever clever scheme you come up with is relatively common. If only 0.05% of passwords use it, that's still less entropy than adding two more characters. And it's a lot safer to underestimate than overestimate.
Surely that depends on the hashing function. Moreover, these passwords are usually used for authentication rather than encryption, making the speed of the GPU irrelevant.
Even for encryption, you should probably store a strong key on a hardware TPM and only using the weaker key to authenticate towards the TPM.
You can use a bad password if the hash is good enough, or if you assume the hash can never be leaked. But you can't usually assume the hash will be good. It's safer to store a high quality password than to memorize a low quality password.
Otherwise to get access to my PC? Let's just say that if that ever happens, having a more randomized password (and one that I can actually use) that takes a bit longer to crack won't make much of a difference, considering they already have my PC.
If they get the drive from your PC, the difference between a medium password and a good password is not "takes a bit longer to crack". A better password is impossible to crack using current or near-future technology. The difference between 12 and 20 characters is that it takes ten million billion times longer to crack.
(Assuming you encrypt your data. If you don't then all your effort on making a half-secure password is wasted from the start.)
If you want real convenience for logging in to your PC, without compromising your security, then use a PIN that unlocks a key stored in the TPM.
Not everyone has a memory works that way. I've tried mind palace style and mnemonic techniques, and I will always remember the general gist, but typically not the exact order and specific words used. Same issue with reciting quotes. I can just about remember the 7 word phrase that I use to unlock my password manager, and I still sometimes mess it up.
Similarly I can never remember the plot of films more than a few days after I watch them - though one great thing about that is you can always re-watch films like they're new. Yet simultaneously, I maintain a working memory of several programming languages/frameworks, and otherwise generally have a good semantic memory.
I don't do passwords this way at work anymore, because they make us change it every 90 days. I just use keyboard patterns, and shift the pattern to the right for each successive password. Seriously people, expiring passwords is an idiotic idea.
It's fairly fast, actually. One of the things I've decided to do is trade some entropy for having only lower case letters and the minimum symbol count, because what tended to screw me up most was synchronizing the shift key with the rest of the password... which I suppose also gives a clue about the speed. It's at least no slower than a passphrase of equivalent strength, and it fits my brain.
But if passphrases work better for you, by all means, please do.
Also, I have a password manager. I only have about 4 of these at any given time, and I can afford the cognitive burden of ensuring they are all very strong. It'd be a different problem otherwise.
But almost nobody uses a good password manager, so... yeah.
How many businesses do you know follow NIST's new password guidelines?
Our industry partners, who are mostly large banks, have idiotic make-work policies. Some are just plain made up without justification by an internal auditor who thinks they’re smart. More than one even consider usernames to be secrets and one threatened to bail on a contract when our apps began displaying the username on-screen and in audit reports.
https://practical365.com/security/microsoft-recommending-non...
At my previous role I added a number and kept increasing until it accepted the orginal password and I started the cycle again.
One of the reasons I don't do IT security any more is the attachment to old dogma like these kinds of password rules by auditors - they are the real barrier to making policies more effective.
A-Z, then AA-ZZ, AB-ZA and so on.
And I worked on my IT department, and then went over their heads, until they got smart about password expiration.
I see harvested passwords as a larger threat than bruteforcing, so some kind of expiry is important. Some users might use good, unique passwords, but most will not.
I make the assumption that the longer a password exists, the more likely it's reused and compromised. I don't have insight into every password dump, but I know my users reuse passwords a lot. I think a long expiry is the best balance in my environment.
If if you did a 1-year password expiration, and last year's passwords were compromised, then if the attacker figures out that someone's password last year was "uwethskjv9j29#18", then there's a good chance that the attacker is going to try logging in with the password "uwethskjv9j29#19" this year and "uwethskjv9j29#20" next year, and will probably succeed.
You gain nothing from password expiration, other than annoyed users and and even more annoyed IT team who has to deal with lockouts from people that changed their password to something secure.
More significantly, if changes are required or weird composition rules used, people are more likely to store their password in a convenient unprotected form (historically, often paper kept next to their main computer, which is a risk, but these days the convenient form may itself by subject to remote compromise, making an even bigger risk.)
I often hear that attackers will simply increment the number at the end of your password, but users apply many different "simple" changes and it's likely that you'd need to try a fair few tries to guess correctly. That might be feasible if you have the new password hash or you're targeting an individual victim, but if you don't, then the password expiry policy offers some defence in depth.
You require new passwords every year, done Require symbols, done lower and uppercase, done numbers, done
Furthermore, many corporate systems do not integrate well with password managers, such as when first logging in to your system in the morning. This means that the password is likely to be one of the few that must actually be memorized. If you ask me to memorize a 32-character random string, I will, but I won't memorize a different 32-character string every 6 months!
[0]: https://pages.nist.gov/800-63-FAQ/#q-b05