This should not be a surprise, as this supports the NIST's revised recommendations (from June 2017!) that passwords should not expire [0], because it actually leads to less-secure passwords for this exact reason.
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!
Bruce Schneier's summarization [0] of NIST's revised recommendations:
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.
> This is true, PCI DSS still requires password expiry.
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.
Yes. When a policy is crazy, the Right Thing is to find out how to either alter that policy or obtain an authorised deviation from it as tatersolid describes.
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.
Using NIST password guidelines as a compensating control has been accepted by every assessor I’ve dealt with (even the really bad ones). A compensating control must exceed the requirements of the control its compensating for, and the NIST rules clearly do. I’d say it has much more to do with how you write your compensating control worksheet rather than anything else. If you assessor is refusing to accept compensating controls, you should report them to the SSC, and then find a new assessor.
Do you happen to have a library/tool you could recommend that helps with this or did you develop something in-house?
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.
The ISO 27xxx standards in Information Security don't tell you how to do it, they tell you how to formalise what you decided to do (and how it can be monitored, audited, etc.). So the reason your ISO compliance forces you to do password rotation is that some twit added "password rotation" to the policies you decided you were going to implement. New task: Find the relevant policy and revise it citing the modern NIST guidance. Extra credit: Go through other policies that get in your way, figure out why they're in there and either you'll be reconciled to this annoyance in your life or you can revise the policy to not be a problem.
I would love to know my companies reasoning. I work for a huge health care provider and everyone from care workers to the nurses in our office have to change our passwords each 6 weeks. Myself and others just keep the same passwords and increase the number at the end. Currently we keep getting these emails from IT telling us security threat level is high and don’t click links from unknown locations. The system is buggy to add to is all so people are constantly getting locked out and they call IT who helps change to another password. After having to do it so often so many times most of us just don’t care anymore. My password is kind of complex and in the middle I have a number that I just increase each time.
I agree with all of this except password managers. If you use a lot of different public computers or temporary work laptops they don’t always let you install LastPass, so I frequently ended up being unable to access my accounts.
It would be really cool if you could plug your phone in and it appeared as a USB keyboard device and you could "type" the password from the password manager that way without ever giving the computer access to anything except that password.
Maybe some sort of simple USB dongle (like a yubikey) could be fed by the phone via bluetooth or nfc to do this?
All the QR code needs to encode is a URL pointing to their authentication endpoint. If it's reasonably standardized, any password manager could implement it.
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.
Which, to be fair, is close to how it works inside Apple's walled garden. Logging into iCloud on a new computer will cause the iPhone attached to that account to pop-up a "confirm login" dialog, so the second factor for login is as unobtrusive as possible.
No you still need a password, which also makes it insecure on a public computer (where keyloggers might be installed).
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.
The signature of the QR code would need to be accepted by your mobile, not the public computer. I don’t think mitm the QR code process is possible if they sign it. But if the public computer is compromised, anything you log into from that computer is accessible by the attacker anyway, as long as the session is valid.
That’s true regardless of the login method. The benefit of the method I described is that you can 100% log out without any MITM, as you initiate the logout from a trusted device
No idea. Presumably a push notification. Within less than a second providing your email (on fast US data) you get a prompt on your phone that shows the browser model and approx location and asks you to approve or disapprove the login.
They initially rolled it out as a 2FA option, then as an optional for 1FA.
Exactly. Google already asked for email alone and then password on the next page so that they could support sending enterprise emails to custom login systems.
Yeah, I actually like the way Microsoft and Google do it when it just displays notification or number on my phone. Recently I logged in to a new Windows 10 computer and I didn't even have to type a password anywhere.
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.
Oh hell that would be amazeballs if it's open source and worked on Windows, OSX, Linux, and could work with a 2FA device like Yubikey. I'd put $20 down for that in a heartbeat.
This seems to be the default for web apps here in China, such as Taobao or JD. Either the home page or the login page presents a QR code, and the mobile app has a scan icon.
I had high hopes for Clef, but unfortunately, it never got the traction it needed.
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.
The QR code would only contain a login challenge, the phone would complete the challenge. Of course that would mean the auth server must be publicly reachable or the phone must be in the same network.
The EspUSB Tiny can pretend to be a USB keyboard and mouse, and it fits inside a USB socket. I've built prototypes already, and I've found a manufacturer for scaling up, but it's stalled since August because of certification issues.
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.
> 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?
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.
Very doable. I also want(ed) this. There are some old kernel patches on github that extend the android USB driver to also be able to register as an HID device.
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.
I also looked into this but was disappointed when I found that android support for USB HID only goes in one direction. You can attach a keyboard to your phone, but your phone cannot act like one. There are so many useful usecases for a phone like a keyboard it is too bad...
Yeah, this is why you either need to disable the android usb driver and use default linux ones (enabling which, broke the compile for the vendor kernel on my device)
> 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.
I guess what I wonder about there is how do you deal with various password "rules" when generating the passwords? I really have no idea what that thing is doing. How does it know which password goes to which website? How do you create multiple passwords from your fingerprint?
you can use a teensy. i have a prototype that communicates to a teensy over serial connection and types in a pw from an app. could use wifi or bluetooth too.
Pardon my ignorance but if you're worried about the computer being compromised so that they could somehow access your LastPass, why would you even use it for any authenticated work in the first place?
They used to have a mobile page you could login to. It was really plain but it did what it did best: provide an easy and clean way to access your passwords when you are somewhere.
It was something like https://lastpass.com/mobile ...
I have a hard enough time typing 4mfkD.Q.27cC8,'@eG}a4{\* , I am very much not worried about a "shoulder surfer" either seeing the cleartext password on my tiny phone screen, or watching all of those keystrokes without me noticing them.
What if you store passwords for non-ssl sites in your password manager? I have passwords for some really old mailing lists that don't use SSL and had a big warning that they're completely insecure on the page. I especially don't want to use a shared password if it has a decent chance of being compromised, but if I cared if that account got compromised I wouldn't have set it up.
For scenarios like this, where the hardware is untrusted, Yubikey type devices are really the only solution (where the device can present as a user input device, and provide the necessary string secret). Everyone else can use a password manager.
EDIT: If you're on an untrusted device, should you really be putting secrets into it? Maybe not!
I had an employer that blocked access to lastpass.com to discourage that sort of thing. I guess the idea is you shouldn't be using a work computer for personal stuff and you shouldn't put work passwords on a 3rd part site. In reality, things aren't split that cleanly, so the block was annoying.
That actually sounds pretty secure, if the computer had a reasonable password and FDE you've just implemented a hacky password manager. Even without FDE you're better than anyone who writes it down on a sticky or uses something trivial.
Unless they're using Excel functions to generate password{n++} . That'd be clever and yet horrid at the same time.
Although at most workplaces your documents are just a folder on a shared drive somewhere, which may not be secured well and in some cases not secured at all.
If the script is accessible to other people I suppose you have to worry about it being hacked, especially if you let php get out of date or take input in say password length?
I totally agree that password expiry is a problem, however I have twice taken over AD based systems where there was widespread password sharing, and I found IT knew a lot of passwords of users. I found that a one off change didn't help, they all just updated each other.
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....
While decreasing rotation frequency is definitely good, I'm not quite sure how is this supposed to help reuse? People will do what they need to to get their job done, exactly the finding of the article. Would be better to tackle the root cause by e.g. having shared, federated accounts or roles. Of course, it's easy to say, but should be worth it in the long run.
Surely the whole point of a password manager is to have a different long complex password for each system you login to without needing to remember any of them but your master password?
I think he means that a password manager (PM) renders the other two points moot. Password expiry? No problem - my PM generates a new one easily. Complex rules? No problem - my PM will follow any rules you like.
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.
Sorry but I don’t understand how I’d use a password manager to unlock my computer. This password is for my active directory account and I hate that it expires every three months.
Try to get the AD policy revised. Because there is (since 2017) clear NIST guidance saying not to do this, chances are that somewhere in your organisation a document can be updated to cite that NIST guidance and then the AD controls can be relaxed to let passwords have the same lifetime as the account they're for. Finding who owns this policy and getting them to fix it may take a bit longer than one of those 90 day password changes, but it'll feel like you made the world better and it may only take a phone call or an email to the right person.
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.
My login/AD password expires every month, and you can't reuse one from the last year. But in the end it's not too bad, because you just append a number to your password and that's it. Most people have a post-it on their screen with the last number they used.
I am forced to type 2 to 3 passwords every morning. The IT rules says I can't leave my laptop in my table overnight, so I have to every day type at least the disk encryption password + my login password. And sometimes I also have to type the VPN password. That's already 2 to 3 passwords every single time.
Not counting the SSH key passphrases for a lot of stuff...
This is not only about time wasted. It's about my feelings. It is about the mental effort to memorize them, update them every 90 days (by incrementing the last digit, of course) the frustration of having to type them, and the fact that maybe this is not really the best solution to the problem, yet we're still using it in 2020. I could keep increasing this list forever. Having a strictly technical view over problems always limits what you can see.
> corporate systems do not integrate well with password managers, such as when first logging in to your system in the morning
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.
The funny thing when they don't allow you to do that. They throw an error something like "Your password is too similar to the previous password". Then I know they store it in plain text.
You could imagine a scheme where they just store N salted hashes of your N-character previous password with 1 character deleted. Then at password changes, they do the same iteration with the candidate password and see if any digests match. This tells them if you made a 1 character change to your password, without storing your old password in plaintext.
Yeah... they could be doing that. But these are the same people that implemented the forced password change in the first place. The overwhelming likelihood is that they're storing them in plain text, and the jury might still be out on whether that plain text is world-readable or not.
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.
> Furthermore, many corporate systems do not integrate well with password managers, such as when first logging in to your system in the morning.
...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...
I think it's possible to use your FDE key to decrypt the filesystem, autologin to the desktop, unlock GNOME Keyring or a similar keychain application, and use that as a GPG and SSH agent to further encrypt your passwords using pass [1]. Since it's just Git and PGP, there are pass implementations for most OSes. I'm not sure if that counts as "integrating well;" it certainly doesn't work out of the box. I'm using all these components individually, but still typing my password 100 times a day for now.
> such as when first logging in to your system in the morning
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 should not be a surprise, as this supports the NIST's revised recommendations (from June 2017!) that passwords should not expire [0], because it actually leads to less-secure passwords for this exact reason."
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. :-)
People should remember that the recommendations are part of a large security program and assume the implementation of others that are not so straightforward. Multi-factor auth and resistance to offline attacks on a stolen database or MITM'd creds in an outdated Windows environment tend to be big technical pain points. Most companies, especially outside of tech, aren't in a position to remove password expiration yet.
I think anyone can memorize 32 character passwords every 6 months if one uses some scheme. I usually use long phrases from books: a phrase that means something to me is easy to remember and even if I forget it, it's easy to look it up. Such passwords can be arbitrarily long.
When this came out I wasn’t directing IT... I had to (fucking) fight tooth and nail to get our MSP and CFO to accept it.
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.
Zaphod Beeblebrox's kite harasses Tuscon. Great, one more collapsing home. Why? 7 termites risk 5 bad days. Knight's queen kills narcs; Good Game queen. Fighting inside futons upends Greater Detroit in 7.
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.
To me, there's an irony in that "Zaphod Beeblebrox's kite harasses Tuscon." is not only _more_ memorable on it's own, but is probably a _better_ password than "ZBw3hHg1tFWdhdt?Hoh2hXcrZmn"
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."
There's absolutely no way a five word password is better than 32 random characters. Two plain old random words, the entropy of that is less than 16 bits each, but we'll round up. One of the biggest cities in the US is probably even less useful, but let's credit it for 16 bits. And let's rate Zaphod Beeblebrox as one-in-a-million for entropy purposes.
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.
> There's absolutely no way a five word password is better than 32 random characters.
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..
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?
Guessing that it's English words is no harder than guessing that it's random uppercase/lowercase/numbers. So that part cancels out. Realistically you'd try all simple patterns in order of complexity. This makes cracking slower than knowing the pattern up front, but the password is already getting exponentially harder to crack every time it gets longer. The small factor of trying different simple patterns pales in comparison.
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.
> The small factor of trying different simple patterns pales in comparison.
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.
> At what point would they exhaust their bruteforce capability or decide that they've probably got the wrong pattern and go for another one?
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".
> 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.
The pattern entropy matters, but it's much smaller than the entropy from the actual words and characters.
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.
> a single consumer GPU can test about 2^48 - 2^52 hashes per day
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.
It matters for authentication. Databases are regularly leaked with password hashes in them.
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.
Realistically, which of my passwords are accessible by such? The vast majority of my passwords are on the web. I don't think any web server is capable of receiving that many password requests to brute force the creds there.
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 you're only worried about people trying to log in via the web, you can get away with a really bad password and you don't need any fancy tricks.
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.
I ran a few tests with zxcvbn using five words (only nouns and verbs) and it estimates the complexity at roughly the same as that of a 32 random alphanumeric character password with capitals. Is zxcvbn wrong?
Even knowing nothing, any sane password cracker would attempt five letter sentences long long before they even reached 30 character alphanumerics. And 30 characters is itself more than a thousand times easier to crack than 32.
That technique works if you're good at remembering long phrases/stories/quotes verbatim.
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 do passwords this way. At first, it's pretty slow, but after a while it's muscle memory: my fingers know my passwords better than my brain does.
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.
I don't actually use 35-char passwords. That was just to answer the challenge. Mine are more on the order of 20.
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.
It's not just memorizing it, it's typing it every single time for every transaction that you want to do, if the administrators require it. The recommendation on one system I use is to force ssh and auth with username/pw for every git transaction. Because Security!
If I had a good reason to memorize this, I would have it down within a couple weeks. I'm pretty certain of this, as I do have private keys committed to memory. That's not even impressive, folks who have good memory palace practices could recite that string for you a few minutes after seeing it. I wouldn't expect it of the average user, but it is totally doable for a human of average intelligence -- it's just not something people care about. For long term storage (rather than a repeatedly entered password) it's even easier if you convert[0] it to an equally random yet more humanly memorable line of text: "duck fade ink love reality possible shown screw thing win invisible realize child suffocate somehow petal army nervous"
In fairness, if you have a good password manager on that phone, that password will be protected by not just the device's unlock PIN but the password vault's master password as well, along with potentially other layers of added protection as well (a second factor to unlock the password vault, biometric authentication to unlock the vault or the device, etc.)
But almost nobody uses a good password manager, so... yeah.
My dayjob in the banking industry is strictly NIST SP 800-63B compliant for all systems we control.
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.
Because of minimum age rules, I just spell out the number if I can't recycle the old password yet.
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.
I never wrote my password on a post-it on my screen. The post-it had tallies of the number of times I'd incremented the number at the start, and the number at the end.
And I worked on my IT department, and then went over their heads, until they got smart about password expiration.
Nothing stops them from using a unique passphrase. I am subjected to the same password requirements and use a unique passphrase every time.
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 frequently have perfectly adequate strong passwords rejected because it doesn't have the anointed mix of special characters, or more infuriating, has ASCII printable characters that aren't accepted, like caps, digits, or symbols. The latter systems are 100% guaranteed to be storing unhashed passwords.
Schneier says "don't make people change their passwords unless there's indication of compromise"
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.
The point though is that if password changes are required, even with a long expiration time, people are only going to make minor and probably predictable changes to their password.
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.
> The point though is that if password changes are required, even with a long expiration time, people are only going to make minor and probably predictable changes to their password.
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.)
Surely you gain more than nothing, even if it's not enough to justify the costs imposed on your users?
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.
That’s not an indication of compromise: just you increasing the odds of people creating predictable passwords. If you’re concerned about dumps, setup one of the services which checks against HIBP for known-leaked passwords and then put all of your effort into MFA (especially FIDO) because that will stop the kind of attacks which are common in this century: immediate use of compromised credentials, high-skill phishing, etc.
Honestly that’s what I do at work. I have five passwords that all expire every 90 days and I made sure to get them expiring on the same date and in sync with the same password that matches the various policies and I just make minor iterations on that same theme every 90 days for all 5 passwords.
Of course we do. My password manager does not work for the Windows login and I need to change it every 3 months. I can remember 1 large complicate pass-sentence, but not a different one every three months.
For cases like these I semi-seriously suggest using a keyboard with programmable macros. Usually people laugh it off but I think it's not the worst idea. Almost no one I know would know how to find and execute a macro on my keyboard, if they even considered looking for a password there.
I may have done this at an employer. You don't need a keyboard with programmable macros, though, just a way in the OS to setup a keyboard shortcut to run a command. In Linux it's super easy to make "super + x", or other modifiers + key, execute a bash program. That bash program can then use xdotools to type a password, generated and type a 2FA token, type a ¯\_(ツ)_/¯ string (because slack imagified the emoji version making it unreadable), whatever...
Same. I'm currently on the 15th permutation of the same password. But we implemented 2Fa this year so now I still have to change my password regularly, and pull a code from my phone that's generated on demand (as opposed to temporal rollover) so it needs to be connected, AND I have to enter in my password about 75 times a day because it goes part and parcel with the 2Fa prompts.
Same here. I have a fairly complex (secure) password I use at work and they make me change it every 90 days so I just appended an "01" to it which I increment on every change.
I did this at my old job where they forced regular PW changes. The thing that changed was the string of digits at the end, which was always the year and month I was last forced to change it.
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.
We had a password change rule at a company I worked at because QuickBooks required it. Because QuickBooks required it upper-management decided that ALL other passwords were required to be changed as well (email and desktop passwords, for most employees).
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!
There's actually no need to really change the password. The check for used passwords has its limits, so after going through [password]1 to, let's say, [password]20, it lets you use [password]1 again. A script (for loop with smbpasswd, for example) can do this in a few seconds.
My first job out of college had a policy like this, and I did something similar. Biggest problem was that we had multiple password systems, all with their own policies, so my passwords slowly got out of sync.
Mine is somewhere between 30 and 50 days (been keeping track and it seems to shift around). For a while a bunch of us were able to get them to stop expiring our passwords, until upper management found out and put a stop to it.
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)
I used to have to deal with an enterprise system that required quarterly password changes. The interesting thing about this system was it would refuse to let you set a new password that wasn't sufficiently different from the previous several passwords... Which almost certainly means they were implementing this security measure by storing the passwords in plaintext on the server.
There are locality-preserving hash functions. The typical case is rather non-cryptographic, but there are ways to trade optimal locality parameters against cryptographic security. Also one could use a bloom filter to keep track of the passwords that were used, and have it alert if the to-be-set password can be permutated with some given rules into a password the bloom filter matches. As soon as it matches, you can then do an expensive check against the old salted password to weed out false-positives.
You could take the first N characters of the password and store that as a secure hash. That would catch people choosing password1, password2, etc (but wouldn't help much with 1password, 2password...)
Not necessarily. You could try simple variations of every single character of the password (lower/uppercase, previous/next character) and try to hash that and compare to the previous passwords. That's just ~30 hashes for a 10 letter password.
I used to set many passwords with slight variations.
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.
The thing I hate the most is random websites forcing you to use a password with "at least 8 characters, capital letters, numbers, .."
I only care about my email account and a couple of other important websites.
I want to be able to use the same simple password on other websites.
So what if my account on pinterest or my local news website or some random forum is compromised... I don't care. I will either reset my password or make a new account.
If you want to feel better about those websites, Provident CU makes you pick a username with the same rules, including capitals and numbers when you register for online banking.
Someone in their IT department is the Grand High Idiot of Cargo Cult Security.
> The thing I hate the most is random websites forcing you to use a password with "at least 8 characters, capital letters, numbers, .."
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!
same here
I have good passwords on my password manager for things that I care about
a password for things I don't care that much enough to use the manager
and a password for throwaway stuff
There was an entertaining tale about this in Henry Marsh's Do No Harm: Stories of Life, Death and Brain Surgery (he's a very significant figure in brain surgery in the UK).
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.
Somehow this reminds me of a problem my father (who is a doctor) has often complained about. Basically IT shitheads enforcing their policies on ALL computers in the hospital, including those used in operating rooms.
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.
Conversely, computers outside the surgery are all on one big network in a public space with random unsupervised people walking around at all hours. It's very easy for someone to utilise this in a way that violates the privacy of a patient in the worst possible way. Think nosy reporter looking for HIV status of a celebrity, or abusive parents looking for their kids to stop them having an abortion, that kind of thing.
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.
This sounds like EXACTLY what Sun's SunRay thin clients used to do, back when the rest of the *nix world seemed completely oblivious to this whole "hot-desking" concept.
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.
I do this at my current job, character by character, as I'm asked to update it. I think I have a mix of four different slightly modified semi-unique passwords I've used in the past so far, so it's not great, but not terrible.
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.
I'm not on mobile often anymore, but if I was it would be terrible and I would probably switch to something smaller or just use a keyboard (otg/usb? I'm not sure how secure bluetooth is).
The password requirements at my job are, in my opinion, insane. It has to be a specified length (an exact number of characters, no more, no less), can't contain any 3+ character words found in a dictionary, and a few other requirements like at least one capital letter and at least one number. And it has to change every three months. So yes, when I have to change my password I end up changing a single character or digit and calling it a day.
4-digit PIN with probably lots of protection/detection against bruteforcing (e.g. you only get 3 tries before you're locked out, then you have to go physically verify your identity and change the PIN again) and it's a bank so naturally everything is already being monitored.
To bad it needs to be a specific length, these would work otherwise:
(+ (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 ;)
When a place requires a specific number of characters, that sets off all kinds of alarms in my head. It makes me think they are storing the password rather than a hash derived from the password.
My single biggest issue is weird complexity requirements... let me simply use a relatively short sentence (15+ characters). If they limited requirement to length only + a breach check, that would be enough and encourage a sentence.
"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.
Random words, yes. With random words, you've turned your set of 40 or so symbols into a set of 150K or so symbols, so it's fine that you've got fewer of them in your password.
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."
I was just giving an example... there are a nearly infinite number of sentences out there, even if they share a common structure. That said, it doesn't have to make sense and I'd be okay with "noun noun noun noun noun" for that matter. The point is, you hit a point where it's good enough and even then if you really need more security that's where MFA strategies come into place.
More important then length: you shouldn't reuse that password anywhere else. Breaches happen when attackers compromise a password from one source and try it on a bunch of other systems.
yes but if you get keylogged while using a pw manager, you lose everything, as compared to losing one (or a few, depending on how egregious your passowrd reuse is)
This is not true. If malware runs on your machine and there is no password manager storing 1400 passwords, the malware cannot pivot to 1400 destinations. However, if there is a password manager on the device that the malware gains access to and it would indeed store 1400 passwords in one place, then all 1400 assets are compromised at once.
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.
You'll presumably access those services eventually. And for the huge majority of people if they are memorizing a password for a infrequently used service means using a shitty password.
"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.
I guess the point is that the 1400-strong pw manager is the antithesis of defence in depth. If you get malware'd, better that they nab a few passwords than /all/ of the passwords.
Having unique passwords for every service, all of which are stored entirely in your brain, is almost certainly more secure than a password manager.
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.
My most memorable policy as an end user was as a consulting client for a huge bank. On top of the usual length, character type, and password changing requirements, the password could not use substrings of 3+ characters from any of your prior passwords.
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.
I use this time management software at work that forces me to reset my password pretty much every time I open it.
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.
Companies should provide a password manager solution for their employees, if they care.
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.
Since our company req a password change every 90 days, it's as easy as appending the season and year to the end of your password. So right now it would be [password]winter2020. Since seasons are ~90 days long it's easy to remember and isn't just adding a "1" at the end.
Most policies don't let you reuse the last N passords (N is often 5 or 10). So standard practice is to start or end the password with a digit and increment it when you are forced to. Better yet, digits are on the top row with the symbols, so you can knock off 2+ categories without moving your fingers.
Most employees have a sincere desire to their work with a minimum of fuss, and this does pretty well.
Nothing like asinine password requirements, with frequent rotations. Especially if it has absurdly low login failure counts before the account is locked and requires manual intervention.
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.
I'd say require using one of a list of 2-3 password managers. Then, the user has a master password that they can change if they want to, and can change individual passwords with less effort. Allow writing master password on a slip of paper kept in their wallet for a couple of weeks until they memorize it.
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.
The surprising thing is that is's only 49%. I kind of think that at least another 40% are lying, and another 10% only think their new password is substantially different ("I used uppercase instead and I incremented my trailing counter from 10 to 11!")
I use a password generator (30 characters, numbers, upper/lower case, special chars, ...) and upon being forced to generate a new one it somehow ran afoul of $corporate-policy, probably not exactly the right mix of special characters. After several tries I gave up and just incremented the old one.
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.
The company I work for requires a password change every 60 days and a history of 9 passwords. Every other password I have in my 1Password so its ultra strong and secure (I use a 5 word passphrase). For my login password I just change the last digit in a loop between 0 and 9.
Pro tip: With a history of 9 passwords, change your password 10 times every time you change it until you loop back to the original. That way you can use the same password indefinitely.
I thought of that, but we have a really bad AD/Mac setup where changing your password takes 30-60 minutes to propagate. During the time you try both your old and new passwords until they work.
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.
Same here. I have a few numbers in my password which I increment every three months. I would have a problem if their history had more than 9 passwords :)
Wonder how many % use the password reset as an effective one-time password (unless cached) as they can't be arsed to remember the password complexity rules for every single site thwarting their simple password variations scheme.
For systems with automated password resets sent to email, what even is the point of a password at all? It literally accomplishes nothing. Just get rid of the password entirely and make checking email officially a part of the login.
I systematically do that. I make a strong point of not remembering passwords, as a matter of personal hygiene. Every time that I need to login somewhere, I just reset the password, which often involves clicking on an email link. This is a much better user interface than remembering a password.
I would be shocked if it was actually that low. Doesn't everyone who's forced to change passwords every few months simply increment a number or change a single character?
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.
The other fun requirements that tend to go hand in hand with forced rotation are max one change every day, and not repeating a previous password. But the repeating password buffer is usually small. When I still cared I would have [complexPassword], change it to [complexPassword]0, then for the next 10 days I'd change it [complexPassword]1..9, and on the 11th day I could change it back to [complexPassword] and be good for another few months.
Only 49%? I sure as hell didn't come up with a completely original password when promoted by a 90-day-expiration. I just incremented the appended number.
First, we also have to change our password all 4 months or so.
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.
Windows domain and 13 separate SAP logon's for the various products I work on in Dev, QA and Regression as single SAP signon either costs too much money or is hard to get right.
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.
Shared secrets are a really dumb way to handle authentication.
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.)
I think they should go with fingerprints. I have to change my password every three months so I reuse the same password with a few numbers incremented. For a while I created completely new passwords but constantly memorizing them got really annoying.
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.
I'd bet it's more than 49%, to be honest. Everyone I know does it. Pick a good password, add a digit to the end, then just increment until it rolls back around. Ta-da!
Our IT server team has been using Microsoft's best practices from the 90s or so, and never bothered to modernize.
I find that we need to reinvent passwords. If you write a long sentence of twenty words and you miss some letters the passwords should still match somehow. Currently I can't imagine using long phrases for passwords as a small change invalidates the whole thing./
I'm still not entirely convinced that writing passwords down is such a horrible idea. An opponent who is willing to pickpocket me or break into my home to steal my password sheet is an opponent who will probably be able to social engineer their way in anyways.
Yes and sites that force such changes deserve to get shit passwords, get hacked, and go the fuck out of business. If they are too stupid to understand security, they shouldn't run a website. That includes companies like Microsoft and Amazon that force people to change pw through systems that generally don't work, fail randomly, and have different criteria for what constitutes a good pw (depending which m$ server you get, it'll allow proper long passwords or not). If people are using pw managers changing pw is never necessary. If they are not it's useless. Either way, it's a nuisance that exists only because of idiots implementing stupid shit they are too dumb to understand and forcing the rest of us to jump through their dumb rituals to get LESS security than if they didn't do any of this stupidity in the first place!
Of course they do. Very few people have the memory to recall different passwords for every service, with capital letters and numbers and punctuation, with no dictionary words, changing every 3 months.
A password manager does no good if it is your windows password, probably the most important one at work. Employees have to remember it, what else would the creators of this security policy expect?
Guilty. Treating passwords like door codes is an unwise and inappropriate policy. Ideally every user should have a unique passcode/account that is not shared.
When I was forced to do this, I would just change my password 7 times until it was back to the original one by appending 1 digit/letter each time. Easy peasy.
Oh for fucks sake, why do people want to make using passwords so difficult?
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?
It's strange to me that passwords exist in 2019. Somehow the best practice is to use a passwords manager, which is an entire layer of poorly pasted-on UI that uses hacks to intercept every login you make whether via app or website. And I'm not saying password managers are bad, they're amazing for security, it's just odd that password managers are the best thing we have because their UI is terrible. It seems like these things should be handled at the browser / device level for universal one-tap login.
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 :(
Not trying to set myself to be a target of hacking with this comment, but what's wrong with that? Why does a password that wasn't hacked need to be changed a lot? If someone is going to try to break into my account my password being similar to one I used 6 months ago increases my vulnerability how?
The point of changing your password is to prevent a password leak from affecting your system. If an unauthorized user has a password they have access until it's changed.
If the change isn't meaningful they can continue using credentials.
It vastly reduces the key space for a brute force attack, e.g. if an attacker has access to old passwords, they can brute force ~50% of them by iterating through A-z0-9 fairly quickly.
I don't remember where I read it, but someone advocated for writing down passwords because people are very accustomed to, and pretty decent at, keeping physical items safe.
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
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.
https://saaspass.com/
https://www.grc.com/sqrl/sqrl.htm
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.
https://en.m.wikipedia.org/wiki/Clef_(app)
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.
[1] https://www.keopass.com/index_en.html
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.
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.
[0]: http://www.inputstick.com/
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...
[1]: https://www.passwordstore.org/
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.
[0]: https://brainwalletx.github.io/#converter
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.
https://news.ycombinator.com/item?id=21204297
You require new passwords every year, done Require symbols, done lower and uppercase, done numbers, done
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%.
That's good, I just increment the last digit.
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.
Someone in their IT department is the Grand High Idiot of Cargo Cult Security.
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!
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.
https://correcthorsebatterystaple.net/
If my bank did that, I'd be searching for a new bank. Just just reeks of passwords being stored in plain text.
[1]: https://www.ing.com.au/securebanking/
(+ (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 ;)
"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?
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.
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.
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:
http://www.dcmembers.com/f0dder/download/fsekrit/
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?
https://saaspass.com/
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.
Enforced password complexity, is actually a in user space implemented algorithm:
while (passwordIsToComplex()) do
try{
if(createEasierPassword()){ goto FAILURE;} if (circumventSecurityMeasures()) { goto FAILURE;} if (hackSecurityToGetWorkDone()){ goto FAILURE;}
}
FAILURE:
Basically, you train a process-organism in your company to circumvent your security measures, for little gain.
(http://bash.org/?244321)
1% use a password manager[1]
[1]%100 of these stats are assumed
(Admittedly, the database is behind a very strong network firewall.)