I used to do a lot of contract work for the Clarke County School District in Athens, GA. For "security" reasons they weren't able to create domain accounts for people who weren't full time employees, so I'd often have to track down the IT manager to gain access to servers I was working on.
He eventually got sick of having to drop what he was doing a dozen times a day, so one day he just gave me his password: a dictionary word followed by the number 23. Eventually the password failed, and he gave me his new password: that same dictionary word followed by a 24.
Fast forward a few years and I'm back installing some updates, and before I get to work he hands me a slip of paper, on which he had written Dictionaryword29.
In a similar vein, over the past few years whenever I've got in a discussion with IT people who defend mandatory password change policies, I ask them to give me the last password they were using before changing it. No one has ever taken me up on that.
However, I would also not defend mandatory password change policies, so you would never end up asking me :D
† I can't tell you now because the day after I ceased working for them I sent the nice leather-bound book I write passwords down in to my Product Owner, so that the answer to all subsequent "Do you happen to remember the password for...?" questions would be "Either it's in the book which you have or No". To be fair he only called me and asked that question once, which is why he was my favourite Product Owner, "capacity to learn from experience: 10/10".
If something got a look inside your book, everything is compromised. At least by changing to another random gibberish password, an attacker would not get back in (in contrast to someone that increments a number, for example), but how much damage can something do in that time before you notice? How long do you think it takes a skilled attacker to install a backdoor (the answer is definitely less than 44 days)?
This is the second major problem with password rotation: it is false security. If credentials are compromised, immediately change them: don't wait 45 or 90 days.
If they're not compromised, changing them is basically pointless, because humans are going to human and either have an incrementing number, predictable pattern, or actual complex, random, unrelated passwords ... that they then write down.
Writing passwords down on paper and leaving that paper in an insecure area isn't.
Your little address book full of passwords is the same as a password manager, and for a lot of people it's easier for them to manage the security of a booklet than it is to handle a password manager properly. And for those people, it's definitely worth using a book for the sake reasons we say using a password manager is a good idea
I used a book for passwords issued by that employer because at that time they lacked any in-house password manager and I foresaw from the outset that I would want to be able to hand them "my passwords" in the limited context of that employment as distinct from stuff like my personal Wikipedia account, my Google account and so on.
Personally I would be much more concerned about other things - my stuff is there, not to mention often myself - but I'm sure that a vast faceless corporation would be primarily concerned with the potential for these hypothetical bad guys to learn and maybe disseminate secret passwords.
How often do you think that actually happens? It's a bit... high risk for opportunistic "cyber criminals" don't you think? Figure out where key employees live, then break in and... look for passwords they've written down and then presumably use them quickly before they're invalidated.
Besides, actually remembering your passwords is a security flaw, too. Memorable passwords are naturally less random, and if the password is in my mental memory, an attacker can compromise my password by smashing me over the kneecap with a heavy wrench until I tell them. If I don’t even know my password, that’s probably bad news for my kneecaps but slightly more secure overall.
If someone did break into my house as an act of espionage (corporate or nation state), I'd be worried about much more than just my password security.
In my experience the average password consists of 1-3 words with some meaning to the user, sometimes either in 1337speak or followed by numbers/symbols if the password policy requires them.
Attackers don't need hints on passwords, they don't need hints on targets. They just target everyone, and try all easy passwords.
Pentester here, to clear any dubious assumptions.
4-5 dictionary words with proper sentence structure is a lot safer for the most part. Random safer still, but much harder to remember... my current password for work in a sentence with 24 characters. spaces, capitals and punctuation. Other than my OS and password manager, I really don't remember any other passwords I use, and the majority are random generated at this point.
I also use a wildcard mail forwarder, so most new sites I've used in the past year or two are all unique emails as well.
Dictionary word with first letter uppercase, followed by two-digit number, followed by exclamation mark. With the overall length exactly being the minimum length of the policy.
I simply disabled password rotation policy on my account ノ(ジ)ー'
One aspect though is that some people tend to use the same password in multiple places and with passwords ending up in https://haveibeenpwned.com, you might argue for periodic password changes.
Other requirements from the same section: retain old passwords to disallow dupes for at least 5 cycles, passwords must be minimum 7 chars, and contain both alpha and numeric.
You might be able to justify non-compliance with a compensating control, but I've never heard of anyone who tried it.
Note that this only applies to employees who are in PCI scope. Most internal staff are not, and should not be!
Similar policies are common for all users though. They pre-date PCI (which is how they became part of PCI DSS) and now PCI's retention of these policies justifies continued use elsewhere. The tail wags the dog.
I just did similarly within a SOC2 audit. I sent the auditors a list of 50+ articles and references i've been maintaining for years saying that password changing is a bad idea (this article is on the list) from many different sources. I never heard back and the item was marked approved by them.
https://gist.github.com/technion/65c652194fb1427e6828ea23ff4...
forcing https://www.washingtonpost.com/news/the-switch/wp/2016/03/02...
regular https://www.wired.com/2016/03/want-safer-passwords-dont-chan...
password https://practical365.com/security/microsoft-recommending-non...
changes https://www.scmagazineuk.com/end-password-expiry/article/147...
is https://www.sans.org/security-awareness-training/blog/time-p...
a https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...
bad https://arstechnica.com/information-technology/2016/08/frequ...
idea https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...
can https://www.schneier.com/blog/archives/2016/08/frequent_pass...
you https://cryptosmith.com/password-sanity/exp-harmful/
please https://www.zdnet.com/article/changing-your-password-regular...
stop https://www.ncsc.gov.uk/articles/problems-forcing-regular-pa...
this was one of the more cheeky version I sent to a vendor.
More cynically: password reuse is allowed after 5 cycles.
It's why mandatory change policies are so stupid. Users will always sacrifice security for convenience.
Even those that know better.
This way, you can't change your password more than once a day. This makes quickly cycling through to get back to your original password hard.
Next day: I can now change my password.
Turns out that I couldn't change my password the first day because it had already been changed to abcd1234 that day. I was not impressed.
Unless you had data on your smartphone or had a friend who was logged in, you were SoL.
Won't work for the Windows password, but with more and more corporations outsourcing their tools to the cloud, system account password is rapidly becoming the least important one (like it already is for most people's personal devices).
P@ssw0rd!
P@ssw0rd!2
P@ssw0rd!3
P@ssw0rd!4
P@ssw0rd!5Not plaintext, but encrypted (not hashed) with the idea that they can be used for things like that.
https://docs.microsoft.com/en-us/windows/security/threat-pro...
This is selfish, though. If that database of passwords leaks, they are prime candidates to test on *other* sites.
How can you do that with a prior password if you didn’t store it as plaintext when it was current? You can’t encrypt something you don’t have. Unless you are encrypting the old hash, not the password.
Assuming the user uses the password in other places, this can be a bad thing.
1. https://www.systutorials.com/docs/linux/man/8-pam_pwquality/
One of the reasons why I want the Credit card cartels to die.
correct, you do it like that:
- h@se2003 - h@se2006 - h@se2009 - h@se2012 - h@se2103 - h@se2106
you get the point ;-) bonus points for encoding the username into it and making it a thing for the whole company, yeah very secure!
Sup3rdup3rp4ss2021Q2
It's orders of magnitude less of a pain in the ass than password cycling.
How is that managed? Are they hashed or stored in the clear? If they were hashed, then they would have to know which algo to use for a password at a point in time otherwise they would lose that data whenever they switched the hashing mechanism.
And when that data inevitably leaks, attackers have a nice table of passwords and metadata that will easily help them out in other places.
A solved problem with public key crypto, where you are in full control of the secret and can take your own steps to protect that.
This is why the modern approach is something you know (password, PIN) plus something you have or are given (time code, texted code, face, fingerprint) for authentication. For environments with MFA, regular password changes seem like a solution that's no longer needed. Ours is a long password changed once a year and I imagine the mandatory change will be phased out eventually.
The logical assumption is that PCI does not consider satisfaction of 8.3 to be a compensating control for the requirements in 8.2.4 -- however I've never heard of anyone who made the attempt.
...
PCI is a weird mix of requirements, evaluations, and compensations. The final authority is the PCI org themselves (i.e. the card networks), but the eval is performed by PCI-approved third parties, for report to your business partners. Requirements are extensive but not always definitive. Compensations are subjective, at best. Enforcement is sketchy but can be devastating.
The usual approach is to comply, comply, comply, and accept that some of it is policy theater, but it's rarely bad policy.
Password rotation is bad policy, but ironically it's mitigated by MFA!
The compensating control is to implement the full NIST recommendation (like enforcing an extra long password length, monitoring for compromised passwords, having a documented passphrase policy, etc...), and in your compensating control worksheet describe how those practices go above and beyond the DSS requirements. That bits quite simple, because there’s plenty of authoritative resources you can reference to justify that position.
The harder part is coming up with a justification for why you need to implement that compensating control. Because a compensating control can only be implemented to address a legitimate business/technical constraint. But that bit really just takes a little creativity.
Also, use of the term "passphrase" instead of "password" and recommending a short sentence with multiple words, casing, spacing and punctuation.
These are built into common assessment tools so you'll get identical policies down to things like byte-for-byte identical PAM module config because most places just licensed one of these tools and demanded everyone use it.
I wonder if Microsoft employees (all or portions) have to rotate their passwords due to PCI compliance despite Microsoft's stance on the subject.
For odd historical reasons HIPAA is passive-aggressively prescriptive through the definition of secured PHI in guidance issued under the HITECH act, whereas the basic Privacy and Security Rules are less so.
> It’s more about defining what PHI is, and what the consequences are for mishandling it.
Well, the Administrative Simplification part of HIPAA (which is far from the whole thing, and which the Privacy and Security pieces are in turn smaller components of) are really more about standardizing and encouraging use of health IT in multiparty interactions in healthcare. The Privacy and Security aspects were included largely to mitigate public fear of shared, common-format digital transactions and records being a privacy risk.
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/5...
There's still the problem of breaches in unrelated services, which must be considered as part of the attack surface when users can just use a single password anywhere. This to me seems like the most obvious benefit of expiring passwords.
Whatever human-rememberable algorithm people are using to rotate passwords, if an attacker knows a password they used at any point previously they'll get the new one quickly.
I did a consulting engagement a few years ago where we cracked 60% of passwords in a 40k user directory in under 3 hours, on a laptop. Every password met NIST complexity requirements of the time.
Would love to know how long it would take to crack
5ae2b1ce4999dfd2c8f1a57509650e75
as a password.
Hell even 5ae2b1ce4999dfd2 is probably more secure than the majority of passwords chosen by users
iOS has the right approach: they suggest random passwords in Safari and explain why, then save them in a local hardware-encrypted store with biometric quick unlock. Downside of course is they also sync to Mac and don’t have the same usability in other contexts. Windows support was recently added, but is only as secure as the TPM option and firmware of your BIOS/CPU chips and given encryption requires Pro, it’s possible some security features also require Windows 10 Pro. I’m also not sure how iCloud for Windows communicates with Chrome or if that’s been documented somewhere. https://support.apple.com/en-ca/guide/icloud/mmfeee20145e/ic...
A permanent solution is to skip the password and just use biometrics and machine identity, such as with FIDO2. Obviously not required in every scenario, but much more secure than a re-used password, even one that hasn’t yet leaked, because it might still (be leaked due to re-use, that is). Add to that tracking of which machines and locations a user logs in to for flagging suspicious “I can’t access my account,” requests etc. Encourage users to log in from more than one device if they can to help regain access automatically if a device is lost or reformatted…
So that's effectively the same thing as if the site only used FIDO2 - because that's the same technology Apple uses within Safari and other web browsers to implement Sign in with Apple.
You can do the same with your Microsoft account: https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/2...
The big name left out of all this is Google. They seem to have embraced using passwords everywhere, except, oddly enough, on their passwords management website - https://security.googleblog.com/2019/08/making-authenticatio...
Every once in awhile Google Chrome will prompt me to sign in with a password, skipping the 2FA check, just to validate my identity. It's kind of pointless, really. If they can't trust my device to be secure, why are they asking me to enter a password on my device? That just weakens my account's security if they legitimately couldn't trust my device... Better to have my device validate its ID and my ID via Windows Hello or the same FIDO2-style biometrics and call it a day.
You can opt to replace any biometrics with a device-specific password that is more secure than other passwords because it never leaves the device or even an additional two-factor key, at the option of the device maker.
For example, you can use a separate FIDO2 key within Windows Hello for enterprise use cases against Azure AD instead of using biometrics to sign in to your computer.
Folks can choose what level of security they are comfortable with. For me, personally, and everyone I know, passwords are much easier to steal and reuse because they leak regularly, can be tested multiple times without consequence, and so on.
To be clear, I’m saying password managers are awesome but device-based security is more awesome. Add a local password to your device based security is more awesome still, but then so is having a friend approve your request or other additional layers of security. Biometrics are the new PIN code “minimum” not the best we can do but better than sharing one string of text with the rest of the internet and assuming it will never leak.
Note that the risk model is roughly identical if a device is lost. Just as with a compromised password, you would have to visit websites using the device directly and revoke its access. This is made simpler if you combine FIDO2 with OAuth2 because then you only need to de-enrol the device from Microsoft or Apple. OAuth2 provides an additional layer of protection because it can tell you when your device is used, and can add additional security factors such as notifying you when a login occurs that not every site might build. OAuth2 does this by replacing passwords with timed tokens depending on how it’s configured, so at minimum new tokens are logged.
The same applies to the use of short-lived credentials in AWS or other cloud providers vs using permanent secret tokens. When using permanent secret tokens, like passwords, these are often very hard to rotate without consequences because you do so very rarely. They are also subject to reuse on different machines. By comparison, a short-lived token can use machine identity on a cloud server to add an additional layer of protection, and depending on the authorization system could validate a local device, use of a second FIDO2 or biometric device, validate the server requesting delegate permissions on your behalf, and validate the duration and scope of data being accessed, all at the same time.
In highly sensitive scenarios, one could even use asymmetric encryption stored on devices to ensure that any intermediate or delegate servers cannot decrypt API responses, only the recipient of the data. Of course, you need a model to trust your client app, but App Stores notarization and containerization go a long way to making it easier to wipe and redeploy secure machines frequently, such as with every system update, optionally leaving user data alone.
If your fingerprint is compromised, where can get new fingerprints?
Device based security (like a FIDO2 key, or even a phone with an authenticator app) is great, beuacse when it's compromised, you can change it.
Biometrics though is even worse than a userID, it's public, left everywhere, and can't be changed
If your fingerprints are lifted/leaked from a glass, for example, then published, your attackers also still need physical access to the device you use biometric security against.
If that's public, such as your house front door, I agree, you've a problem. If that's your cellphone, then you have to ensure you don't leave your phone unsupervised.
The same is frankly true of other exploits that can be done in-person, such as USB attacks or PIN code screen bypass, and so on. Once you have physical access to a device, you can authenticate via many means, not just biometrics.
I'd point out that a password can also be compromised. https://xkcd.com/538/
[1] https://google.com/search?q=0x5ae2b1ce4999dfd2c8f1a57509650e...
[2] https://google.com/search?q=0x5ae2b1ce4999dfd2+%2F+%28170+qu...
It's been a while since I fired up John the Ripper but it has low hanging fruit modes built in.
So even if you are using quite long simple alphanum strings of gibberish then seriously consider adding one or more character class into the mix eg capitals and easy to identify special chars like $£% etc.
To really go for gold why not mix entire scripts eg the usual en_* alphabet and say Bulgarian Cyrillic. Gasp as your keyboard mapper explodes! Alternatively, look into MFA.
I agree about incorporating other characters. As long as it's not "Dictionaryword1!" :) https://youtu.be/aHaBH4LqGsI
5ae2b1ce4999dfd2 is about 10^19 options.
Most passwords will come from a set of around 100 characters (52 letters, 10 numbers, about 35 symbols on my keyboard). An 8 character password would be 10^17 options.
But given a list of common words, it’s pretty easy to figure out how “Autumn2012!!!” will change with the seasons.
Such experiments clearly do not introduce the use of password managers which promote the generation of long passwords with high entropy.
Specifically in the case of master login passwords, where the usage of a password manager isn't feasible (like Active Directory and Windows logins), this may be the case. And it still requires that the domain forbid PIN/biometric logins and thus result in people complaining about entering long passwords with entropy each time.
My password needs to be something I can quickly type, so I just use the same one (a strong, multiple-word passphrase) and add its validity period to the end.
This actually makes hitting arbitrary password requirements easy too; make one word capitalized (or one lowercased), separate each with an allowed symbol, and the validity period is numeric so it passes just about every security check while being easy to type and remember.
Also I can use it for various other things (like password manager secret etc) which don't support yubis out of the box.
rips hair out
>Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password). Password change offers no containment benefits cyber criminals almost always use credentials as soon as they compromise them.
>Mandated password changes are a long-standing security practice, but current research strongly indicates that password expiration has a negative effect. Experiments have shown that users do not choose a new independent password; rather, they choose an update of the old one. There is evidence to suggest that users who are required to change their passwords frequently select weaker passwords to begin with and then change them in predictable ways that attackers can guess easily.
>One study at the University of North Carolina found that 17% of new passwords could be guessed given the old one in at most 5 tries, and almost 50% in a few seconds of un-throttled guessing. Furthermore, cyber criminals generally exploit stolen passwords immediately.
[1]https://www.microsoft.com/en-us/research/wp-content/uploads/...