49% of workers, forced to change passwords, reuse same one with minor change
grahamcluley.com
grahamcluley.com
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!
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.
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.
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.
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.
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.
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.
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.
But almost nobody uses a good password manager, so... yeah.
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.
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.
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.)
You require new passwords every year, done Require symbols, done lower and uppercase, done numbers, done
At my previous role I added a number and kept increasing until it accepted the orginal password and I started the cycle again.
A-Z, then AA-ZZ, AB-ZA and so on.
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.
And I worked on my IT department, and then went over their heads, until they got smart about password expiration.
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...
Maybe some sort of simple USB dongle (like a yubikey) could be fed by the phone via bluetooth or nfc to do this?
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.
They initially rolled it out as a 2FA option, then as an optional for 1FA.
So while you are logged in, the attacker can do anything they want.
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.
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.
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.
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...
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.
EDIT: If you're on an untrusted device, should you really be putting secrets into it? Maybe not!
The kinds of things that people get put on watchlist for, like where to buy industrial quantities of hydrofluoric acid.
Unless they're using Excel functions to generate password{n++} . That'd be clever and yet horrid at the same time.
If that’s actually true, then most companies hands are tied until those payment agencies update their requirements.
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.
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.
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.
There is no incentive for change. Look what happened with Equifax.
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.
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....
Just come to the dark side and learn to program and privilege escalate. You'll learn all these practices and how to circumvent them.
Not counting the SSH key passphrases for a lot of stuff...
minutes minutes/month minutes/year(hours/year)
1 ~22 ~266(~4.4h)
2 ~44 ~530(~8.8h)
3 ~66 ~792(~13h)
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.
...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...
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.
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.
How many businesses do you know follow NIST's new password guidelines?
https://practical365.com/security/microsoft-recommending-non...
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.
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.
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.
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!
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.
You give it a master key and a short code, it derives a password from those two.
Doesn't work in organizations that don't let you bring your own custom hardware though :C
Of course, for my personal logins I use a manager and unique strong passwords, but they gave me no reason to care about password security and a bunch of reasons not to.
Honestly I'm surprised it's as low as 49%.
Because time is money, and the employees' time was all chargeable at about $250/hour, the IT guy was tasked with the job of changing everyone's password himself right before the 90 days were up. He just kept everyone's passwords in a password manager, and the "Notes" field contained the password change pattern the user wanted to follow.
Being the IT guy's manager I was able to exclude myself from these crazy shenanigans, but no one else was so lucky. In fact, many people asked for their passwords to be synced by the IT guy for other services they use at work!
I'm guessing this isn't what they had in mind.
The counter on my password is somewhere up in the 50s or 60s. (For those of us on linux, it's only used for wifi access - things like email and svn use a different, non-expiring password)
a) Passwords that are secure.
b) Passwords that can be remembered.
c) Passwords that must be rotated regularly.
You can pick two of the above, and it can be done. But you're not getting all three.
One day I turned on failed login pass capture on a couple of wordpress web sites. I did see some of what I expected, they tried many of the most common passwords,
what surprised me is that they also attempted all kinds of similar variations that included words that our sites might use, but were not in the most common used pass dictionaries.
So they were not just using dictionary and common pass attacks, they were also attempting ones and slight variations of ones that may or may not have included that common things, plus site specific things, then with slight variations.
That was kind of spooky, and had me change up how I set up some things for other people.
You can come up with a simple and easy-to-remember phrase for those. If it expresses your irritation with those rules and annoying mandatory logins, it's easier to remember. For example, FuckOff1234!
Someone in their IT department is the Grand High Idiot of Cargo Cult Security.
There's a lot to it, but it came down to running around the hospital getting mad with the new digital system for looking at X-ray pictures rather than having them in physical format. Given one of the admin's passwords to try (it was something quite rude like "fuckoff"), he still couldn't make it work, and was advised that they were forced to change passwords every 30 days and to try "fuckoff2". It turned out the actual password was something like "fuckoff4" due to the time that had passed since the password had been shared around the department.
Edit: Found another recollection of the tale here: https://www.theguardian.com/books/2014/mar/30/do-no-harm-sto...
So that means things like a screen (displaying important information) locking from X minutes of inactivity, on a computer that the surgical team is physically unable to "bump" periodically or type a password on, due to them being scrubbed and sterile.
It reaches a point where you basically have to tell these people "Someone could DIE if you don't change the fucking policy for our use case" to get things to change.
I've been involved in the design of hospital computer networks, and I tell you: meeting all the requirements at once is hard!
The system we designed used contactless smart cards and Citrix. The idea was that as the attending doctors moved from bed to bed and ward to ward, their desktop session would move with them.
The instant they logged on somewhere else, the previous terminal would lock and the session would transfer to the new terminal without a full Windows logon cycle. It was basically equivalent to disconnecting a monitor and connecting a different one. No passwords were needed, they just had to tap their id card once.
My challenge was that this has to occur in under a second, including the smart card cryptographic authentication step, which was limited by the throughput of the NFC chip on the card. From memory, it was woefully slow, and we had to use the smallest compatible elliptic curve cipher available to make it acceptable.
Similarly, it was difficult finding a thin terminal device that was both fast enough to do this, and fanless so that it could be sealed against dust. This was needed to prevent their warm insides becoming the perfect breeding ground for antibiotic resistant superbugs.
I kid you not, those of us subject to rolling our passwords do just that. Add one. One system had a restriction of not the same password within 32 changes so inventive users were simply do that in one try until changes got limited to once per 24 hours
> When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords.
My password is currently 35+ characters, using upper and lower case letters, numbers, and punctuation, and is not shared with any other account I have. Even if someone were to get a list of other passwords I've used they would need to correctly guess what passwords I'm using here, what modifications I've made to them, what the order was, and where in the last password I've used I am, since I append a single character at a time.
I also try to go out of my way to use the weakest passwords possible for non-critical websites (eg subject specific forums) so if those are compromised the only thing someone gets is my username plus a really weak password as opposed to my username plus a relatively strong/unique password.
With that said, as I'm writing this, I acknowledge I should really start from scratch. It's better to be safe than sorry.
(+ (CAR hn) 1)
And the variation:
(LET ((hn '(1 2 3))) (+ (CAR hn) 1)
This one works as well :)
STRCPY(str2, str1)
You might be able to even meet the length requirements by padding with some comment characters. You might even use the comment char from a different language than the one the statement is in teeheehee.
Some use chess moves, others poetry lines, why not use code ;)
If my bank did that, I'd be searching for a new bank. Just just reeks of passwords being stored in plain text.
"I really like sour grapes." is easy enough to remember and has plenty of complexity... of course, it gets much harder on a mobile device, this is where passphrase managers come into play though.
I'm skeptical about actual sentences. With an actual sentence more common words will be chosen (so a smaller set of symbols), it will have a structure (no need for an attacker to try, for instance 'noun noun noun noun noun'), and people will probably choose from more common patterns: "I really hate arbitrary requirements."
If your sentence has five nouns in it, it ends up with far more entropy than this, but easier to remember.
Is the password manager not a single point of failure in this model?
However, I'm inclined to believe this is virtually impossible, for all but a handful of exceptionally talented individuals.
So if realistic options are (A) access all services via one password which is only stored in your password manager, or (B) access all services via one password, which is also given out to every single service, I think it's clear which is safer.
Pen and paper works well for the more important stuff, while you can come up with passwords that are easier to remember for all the silly online services that demand a login but don't really matter if they get compromised.
I think that's what the previous commenter wanted to highlight.
In the end it's about managing risks, I would use different locations for storing passwords depending on value. Like really important ones go elsewhere and are not on the device I use everyday for browsing the Internet or reading email.
"Even though the malware has access to my email, which I presumably login to with frequency, and therefore can perform password resets for many services, I might notice it and reformat my machine before I login to some other important service" is not exactly a compelling threat model.
It would not be smart to store crypto currency private keys or recovery pass words on main computer for instance.
They were also required to pass a black-box “complexity” algorithm, and the vast majority of passwords generated by my password manager inexplicably failed this bar.
So every 6 weeks I would set aside about 20 minutes to generate new passwords of varying length in my password manager until one would be accepted as the new password.
What I'd like to know; why does this software require such stringent security. Who wants to hack into my time-sheet and see how many hours I worked on some boring project.
I also have one password to login to my laptop offline, one to login when it's online and another to login to work mail as these three passwords are always out of sync. Very annoying.
They make us change it every 30-90 days, tell us not to write it down anywhere, and don't want us to just add '1' on the end, but expect us to memorize it. I'm not going to pony up my own money for a password manager to use at work and try to make it work there. I pay for one for my own use and it stays for personal use.
Readme.txt:
http://www.dcmembers.com/f0dder/wp-content/uploads/sites/18/...
Homepage/Download:
Most employees have a sincere desire to their work with a minimum of fuss, and this does pretty well.
Some services it's easier to just bag their authentication and use the "forgot my password" method every time like a one-time code. Especially if it a rarely used service.
Within the password manager, there needs to be a way to automatically login to their email account to verify accounts and change lost passwords AND a standard way (Call it PWMAPI - the Password Management API) to change passwords non-interactively within every service. Then, with one button in the password manager, it can change all passwords at once, within a few seconds, while keeping backups of old passwords in case anything fails. Heck, make it an automatically scheduled periodic job the user can be notified to do.
This is how to make things easier.
I could have looked up the exact policy and adjusted the generator. But if the policy rejects passwords with more entropy than most people memorize then I am not particularly motivated to play along.
The same corporate policy also forbids bcrypt password hashing and suggests using SHA2 instead because bcrypt is not "industry standard". Offering to use scrypt or argon2 instead so far has been met with silence.
It makes me question the expertise behind any security the company has.
If you try to change it again during the 30-60 minutes propagation time, then you need to try even more passwords passwords. Too complex to deal with.
I can however install any Firefox extensions I chose. Enterprise architect is not security vetted. But archimate is.
Some of this is hard. A lot is theater.
I'm not afraid or ashamed to admit that this is what I do. However, with that being said, I never reuse passwords. If my password on any given service (including work) actually did get hacked, I would change it to something dramatically different and that would be that.
I'd try to integrate a second factor like physical token like a yubikey or some otp code.
But keep in mind, you can't use a password manager for logon. There are also some special accounts multiple people use. The password in this account is just something like "june.2019".
I guess the best solution would be a card (we anyway have one for the working hours and pay coffee and snacks) AND a password.
It has became a monthly ritual to reset them all when I got back from holiday as I have forgotten them after 2 weeks away.
I tried various password managers and they all suck to some degree.
Set up a CA and sign the public keys for machines you provision to employees. All the tools are there, most software supports it (not the iPhone of course, although I’m sure there’s a hackish workaround that involves periodically sending apple money to sign something.)
That’s the problem with a lot of security recommendations. Often they are very inconvenient.
Fingerprints are probably the least secure method of authentication possible. Picking up your fingerprint off of something you touched and fooling a fingerprint reader is pretty trivial. And worst, it's not something you can change, so once your fingerprint is copied, it's compromised permanently.
Fingerprints should never be considered a security feature. At most they're a convenience feature.
Our IT server team has been using Microsoft's best practices from the 90s or so, and never bothered to modernize.
Whats with the 32 char limit? Are you storing my password in plaintext? Why are passwords even limited in length?
Warm regards, Some guy who prefers passphrases and is sick of dinky little passowrds
No I don't want to memorize a unique string of random gibberish for every new thing I log in to
No I don't want to use your shitty password manager with its half-baked integrations that leave me hanging 30% of the time
No I don't want to come up with special variants of the passwords I know because you have some stupid complexity requirement
Nearly every attack short of actually knowing the password can be mitigated with 2FA, proper hashing+salting, thoughtful lockout policies, and rate limiting.
Why are there so many people who want security to suck so much?
We had a 30-day password reset policy enforced by Active Directory group policy. I couldn't have told you what rules were required to get the system to accept the password, but it well beyond the default/typical AD policy[0]. To "enhance security", ours included a requirement that none of the prior 10-or-so passwords could be used, had a 12-character minimum[1] which IIRC, required also setting the "Store passwords using reversible encryption[2]". We allowed 30 bad logins, but a good login had to occur before lock-out or it required tech staff intervention.
We would have been better off having a non-resetting password policy with a reasonable minimum length. For the first 9 months of my career, I was top-tier end-user support[3]. It took about 2-months before I stopped asking people for passwords. 95% of the time, the password was "MonthNameYearNumber!!!!" with bangs filling in the rest, i.e. "March19991!!!!!!!!", or some variation. However, the frequency with which it was exactly that pattern was amazing. So that gave me 12 tries to get a password. I rarely locked out an account.
As is usually the case ... there's a law of unintended consequences. People will seek to reduce the friction to getting their job done and aren't great at assessing risk. In addition, the risk to an individual password is low. Even the result of a successful breach of a user's password is often not devastating to the individual who was attacked when that password is a LAN login (chances are you're not storing your own personal financial information on your work PC).
One of the odder unintended consequences -- figuring out the appropritae incantation to generate an acceptable password for the system was ... way more difficult than it should have been. I'm fairly certain one of our security tools was just broken. We had something that applied far more strict rules about password history than what AD could enforce, looking specifically for people using patterns, along with some other odd ones, like "you cannot repeat the same character", so "umbreLLa" was rejected. They, literally, reduced the number of possible passwords that a brute-force attack would require.
There was an interesting bug there -- we discovered that after the account was created, if only one password was in the password history, it would pretty much refuse to allow any password that didn't contain half of the characters, in the same place, as the prior password. Then, future required password resets would refuse all passwords that were similar to the previously rejected ones which were used on that account. However, if you used one of those rejected passwords on an account that hadn't had them rejected on that first reset, they would be allowed for that user.
I'm guessing they reversed a boolean somewhere (no similar past passwords) and that the security software stored a history of rejected passwords for future validation (no idea why this would be done, but then, no idea why it'd be illegal to duplicate characters), but security ditched all of those products when AD was upgraded and the tools stopped working. I know one of the reasons for the odd password rules were that we synced passwords to the Mainframe accounts, and they had a set of nonsensical rules that were very similar.
[0] If memory serves, default was 10 bad passwords before 1 hour lock-out, password had to have at least one number, one lower-case and one upper-case letter with an 8-character maximum and 90-day reset.
[1] I believe there's a study or two that indicates somewhere around 7-10 is typical for what a person can memorize easily. I've always wondered why. In my childhood, memorizing a 7-digit or 10-digit phone number for several people was something everyone did, so it's arguable that people my age have that ability out of necessity. I wonder what would be found if that were re-done, today, with people who are too young to remember days before speed-dial. Maybe it has been: https://abcnews.go.com/Technology/brain-memory-magic-number/...
[2] This sounds horrifying when thinking about passwords in today's terms, but storing as a password hash resulted in storing a Lan Manager Password hash which is very low quality (fairly certain this is moderately improved in later versions of AD but is still able to be enabled).
[3] I remember joking that we were helpdesk staff without phones; our "ticket system" was voicemail/e-mail. Basically, if the helpdesk couldn't solve it over the phone, we arrived at a cubicle, often with a screw-driver.
edit: bumped tab and accidentally hit "enter" for a newline ... submitting before I was done :(
If the change isn't meaningful they can continue using credentials.
1% use a password manager[1]
[1]%100 of these stats are assumed
(Admittedly, the database is behind a very strong network firewall.)