[HN Gopher] Microsoft says mandatory password changing is "ancie...
___________________________________________________________________
Microsoft says mandatory password changing is "ancient and
obsolete" (2019)
Author : Tomte
Score : 605 points
Date : 2021-04-19 15:33 UTC (7 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| nosmokewhereiam wrote:
| Who has the best password matrix generator?
|
| Are there any that encode generated passwords on a slip of paper
| that require something you know in case you lose it?
| nixpulvis wrote:
| Rotating passwords every so often is good advice, and I find it
| unlikely to discover a good reason not to.
|
| With a password manager, this process is pretty painless, if not
| automatic.
|
| Mandating it for my Hello Kitty: Island Adventure account seems a
| bit heavy-handed though.
|
| Rather than pulling back the recommendations, we should really be
| implementing open standards for automatic rotations that don't
| rely on reverse engineering / implementing various third party
| reset password flows.
| kelnos wrote:
| > _Rotating passwords every so often is good advice_
|
| Why, though? The article debunks, with evidence, the usual
| reasons people give for requiring rotations.
|
| If something we doesn't measurably increase security, we should
| scrap it.
| nixpulvis wrote:
| Debunks?! More like claims that I will most likely reuse or
| slightly modify the old password.
|
| > The same researchers have warned that mandating password
| changes every 30, 60, or 90 days--or any other period--can be
| harmful for a host of reasons. Chief among them, the
| requirements encourage end users to choose weaker passwords
| than they otherwise would.
|
| That is incorrect in my case since I generate random
| passwords, and no other evidence is cited. I would be curious
| what other reasons they have in mind.
|
| I agree in general, most people may not have password
| managers still, but that seems like the problem to be fixing,
| rather than relaxing security advice.
|
| Specifically, password managers for login passwords is a bit
| of a tricky subject, but that's why I hate the idea of "live"
| accounts, where my login password and online password are the
| same.
| nixpulvis wrote:
| I should add that a password which you actually need to
| remember, like the master password to a password manager,
| should _never_ be used online. The more isolation you can
| maintain the better. This way offline attacks against stolen
| hashes are unlikely to find anything, since they will only
| contain randomly generated passwords.
| whatsmyusername wrote:
| It's not just Microsoft, I believe NIST has the same guidelines
| now.
|
| Forcing people to constantly change passwords just means they
| either iterate a number or write them down. It also means they
| start to resent the tech and people who make them do it. It helps
| no one.
| llimos wrote:
| The problems with passwords have seeped out into the non-tech
| world too: https://www.youtube.com/watch?v=aHaBH4LqGsI
| ben509 wrote:
| > Microsoft employee Aaron Margosis said the requirement is an
| "ancient and obsolete mitigation of very low value."
|
| That kind of magical thinking is what got us mandatory password
| rotation in the first place.
|
| Password rotation has a kernel of truth: automated credential
| rotation really works, and sometimes you need to force manual
| rotations to migrate to a newer hash algorithm, and I'll bring up
| another reason for it.
|
| But the main reason we have password rotation is people have some
| magical belief that a credential gets "old" so we have to freshen
| it up.
|
| Security rules are the same: they work, or they don't, and that
| can be very complicated due to human factors. But they don't "get
| old" and magically lose their effectiveness. If password rotation
| is broken, it's always been broken.
|
| > Chief among them, the requirements encourage end users to
| choose weaker passwords than they otherwise would. A password
| that had been "P@$$w0rd1" becomes "P@$$w0rd2" and so on.
|
| Not true. If they hadn't been forced to rotate, they would have
| stuck with P@$$w0rd1 the whole time, and P@$$w0rd2 is not weaker
| than that.
|
| > At the same time, the mandatory changes provide little security
| benefit, since passwords should be changed immediately in the
| event of a real breach rather than after a set amount of time
| prescribed by a policy.
|
| There is a clear benefit, especially for large enterprise
| systems: a periodic password change does put a limit on when the
| attacker could have used the password.
|
| So when a credential is exploited, if you're rotating yearly, you
| only need to search back at most a year to figure out the scope
| of the breach.
|
| I don't know how much of a benefit this is, in practice. Maybe
| someone who has done a real log dive can comment.
|
| The only certainty is that you must never have passwords older
| than logs.
|
| > If it's a given that a password is likely to be stolen, how
| many days is an acceptable length of time to continue to allow
| the thief to use that stolen password?
|
| They get this right.
| aflag wrote:
| > Not true. If they hadn't been forced to rotate, they would
| have stuck with P@$$w0rd1 the whole time, and P@$$w0rd2 is not
| weaker than that.
|
| The thing is that with the requirement you can guess the last
| one or two characters of pretty much the entire user base.
| Also, if you're constantly changing your password it possibly
| means that people have to type it in more often, which can lead
| to shorter passwords too.
| dredmorbius wrote:
| Rotating (or required change) on some _circumstantial_
| criterion (the old password is know or suspected to be
| compromised, system update, etc.) is entirely valid.
|
| _Forced scheduled frequent password updates are not and worsen
| rather than improve security._ That 's the point here.
|
| In environments in which data leakage probability is high, and
| detection capabilities poor, periodic password changes are a
| defensible risk-mitigation measure, though in practice unless
| new tokens are themselves robust, the practice backfires. The
| problem is that both sides of the risk calculus need to be
| considered --- compromised token validity period, and token
| strength. People being people, the first is actually the safer
| risk to take.
| wooptoo wrote:
| Ideally passwords would be phased out in favour of hardware
| backed authentication. We all have at least one device supports
| authentication methods like: fingerprint login, face id, FIDO2
| tokens, etc. Why not use these instead of passwords for
| applications/websites which require single-factor auth.
| dredmorbius wrote:
| A wearable NFC ring still strikes me as one of the best
| options.
|
| - It's something _on your body_ , you'll notice if it's not
| there.
|
| - Unintentional use / involuntary use is relatively rare.
|
| - The hardware token can still be paired with other metrics
| (password/passphrase, PIN, biometrics, secondary device, OTP,
| geocode).
|
| - A duress code can be included. ( _Memorable_ duress codes ...
| are another matter.)
|
| - The NFC ring is itself replaceable. This solves the "ten
| fingers" biometrics replacement/rotation challenge. (Count
| Rugen gets a bonus.)
|
| - A "ring tap" can be incorporated reasonably into most
| authentication workflows.
|
| - Those unable to wear a ring directly will likly have other
| options that should be suitable (amputees, paraplegics, motor-
| neural disabilites, etc.). Disabled access should be pretty
| high, especially relative to altnernatives.
|
| But yes, the initial assumptions surrounding password-based
| security at MIT in 1960 are all but entirely voided in present
| usage.
| kristaps wrote:
| If there was no user inconvenience, how could you tell those
| responsible for security are doing their job?
| [deleted]
| tylermenezes wrote:
| Fun fact, Microsoft requires all their vendors to have mandatory
| password rotation.
| bombcar wrote:
| Mandatory password rotation does help in one place - when
| passwords to an account are shared.
|
| So if Microsoft Employees 1,2,3 share a password to Vendor X's
| system, and employee 2 moves to another part of the company or
| leaves, the shared password will eventually change and employee
| 2 won't know it anymore.
| tylermenezes wrote:
| Not talking about feature support in an app. Employees of
| companies which contract with Microsoft must rotate their
| passwords. (In addition to attending mandatory training,
| using an anti-virus, etc)
| dyingkneepad wrote:
| Passwords have to change every 3 months. Calculate M as how
| many months since you lost acces. Increment the last password
| digit by M/3.
| krupan wrote:
| I can't wait until we can just say "passwords are ancient and
| obsolete"
| toomuchredbull wrote:
| Can somebody tell Microsoft this fact?
| gfxgirl wrote:
| Question: If I change my password from mydumbphrase to
| mydumbphrase1 and the system says "too close to your previous
| password" is that proof they kept my password in plaintext and
| that their service in insecure?
| hackerbrother wrote:
| Why, when passwords leak all the time?
| bachmeier wrote:
| My employer finally got rid of mandatory password changes -
| mostly. My Surface requires a password change every _30 days_ in
| order to log in. Logging in to teach a class that starts in one
| minute? Guess what. You 're going to come up with a new password
| on the spot or you're not teaching.
| ChrisArchitect wrote:
| Here's a bunch of the discussion from the time:
| https://news.ycombinator.com/item?id=20077967
| imwillofficial wrote:
| So much this, I find it frustrating that we do this at my
| workplace.
| rootusrootus wrote:
| I blame Microsoft for most of the password policies my company
| implemented years ago and won't change. Mandatory password
| changes included.
|
| While on my soapbox, I'd like to tell them that it's really dumb
| to count multiple attempts of the same password individually and
| then lock you out after you attempt the same password three
| times. And your most recent password should count as zero
| attempts. These kinds of dumb policies only hurt legitimate users
| and do nothing to improve actual security.
| cryptica wrote:
| Mandatory password changes never made any sense. It's especially
| terrible when systems don't allow users to re-use previous
| passwords.
|
| It forces users to keep inventing new passwords which they can
| never remember, then they end up writing the passwords on post-
| it-notes and sticking them on their computer screens where
| everyone can see.
|
| Same issue with forcing people to use special characters in their
| passwords; it makes people choose passwords that they can't
| remember.
|
| I've used systems where the situation became so out of control
| that I literally had to go through the entire 'forgot your
| password' (reset password) flow every single time I wanted to log
| in. That was the fastest way for me to log into that service.
| dathinab wrote:
| I would go further: "passwords are ancient and (should be)
| obsolete".
|
| If you can don't rely on passwords, use hardware security keys
| and protocols like U2F and other FIDO2 related protocols. Sure
| you might still have a pin, but now you rely much less on it so
| it can be much simpler.
|
| If you can't use word phrases instead of passwords, e.g. 4
| randomly selected words, and yes randomly selected for the user,
| not choose by the user. But with a way to "re-roll" when setting
| the pass phrase.
|
| As a side effect of being more secure (then normal remembered
| passwords) and easier to remember. As a benefits they are also
| easier to insert on phones with swipe keyboards and have some
| nice tricks wrt. internationalization you could use. (Make sure
| they still work with password managers.)
|
| Practically maybe not possible currently, but if you already rely
| on a password manager there is technical very little reason not
| to replace passwords with a U2F/FIDO like process connecting to
| the password manager. This might be less secure than a HSK but
| still nice. Ah, anyway that's currently not a think.
|
| Lastly if your service isn't generally "security sensitive" and
| login sessions tend to be long consider login links send to your
| password reset email. Especially if combined with password-less
| fido auth based on the browser + TPM this can be a nice approach
| (you use password-reset-like links to setup password-less fido
| auth on the given device).
| kevinpet wrote:
| It's a poor article that talks about Microsoft "bucking the
| trend" on this when NIST put out new guidance four years ago
| saying this.
| fossuser wrote:
| Agreed - there's so much I find frustrating about how companies
| manage passwords in addition to mandatory changing.
|
| - Maximum length requirements (often secret until you try to put
| a password in)
|
| - Requiring some symbols, but not others
|
| - Silent truncation of the the password without telling you
|
| - Failure because the password is too long, but the error says
| something else (like missing symbol)
|
| This isn't just small unknown companies either. If you use a
| password longer than 32chars in Zoom when creating your account
| it just truncates the remaining without telling you. Login works
| on the websites, but if you try to login via the client it fails.
| If I manually backspace to 32chars it works. I tried to tell it
| to their US Twitter support and they just kept sending me a
| password reset link so I gave up (they're a bad company anyway
| [0]). Tmobile's website used to do the same thing, except worse
| because it would truncate on creation but not on validation.
|
| How is this not standardized in some sane way?
|
| An old credit union I was part of in NY (SEFCU) mandated
| passwords with exactly 6 characters. When I complained about this
| I was told it was secure because they forced one of the
| characters to be a symbol.
|
| [0]: https://zalberico.com/essay/2020/06/13/zoom-in-china.html
| jackson1442 wrote:
| > An old credit union I was part of in NY (SEFCU) mandated
| passwords with exactly 6 characters. When I complained about
| this I was told it was secure because they forced one of the
| characters to be a symbol.
|
| For a bank?! And here I am complaining that Chase doesn't
| support application-based OTP. I hope you ran far far away from
| that CU.
| fossuser wrote:
| Yeah, I was in college at the time - banks often seem to have
| really old and not very good systems.
|
| I use Fidelity now and while it has issues, it's much better.
| millerm wrote:
| I forgot my password for a credit union back in the day
| (before I started using a password manager as we all have so
| many online accounts now). I clicked the "Forgot password?"
| button... and they sent my original damn password back to me,
| in email. There are just so many things wrong with that. I
| complained, actually talked to their "technical people" and
| explained the awfulness of it, then moved all my money out of
| that credit union. They did change how it reset later, as
| another member had told me, but I bet they still stored the
| plain text password. I was seriously angry with their awful
| security.
| ajford wrote:
| A shitty local bank back home truncated without telling you as
| well. Didn't realize it until they rolled out a mobile app and
| my password didn't work. After complaining about it, a friend
| who worked at said bank as a teller said to try truncating to 8
| chars and it worked. :rage:
|
| Apparently it was known internally, as they used some ancient
| system behind the scenes that would only support a max of 8
| chars, and the website just truncated your password and passed
| that on. The new app didn't truncate and would get an error
| response.
| isoskeles wrote:
| Maximum length makes sense if the hashing algorithm they're
| using does not go past that length. I think this puts your 1st
| and 3rd bullet points at odds in some cases, if I understand
| your point correctly.
|
| I'm not looking this up right now, but I believe bcrypt or some
| 'version' or 'implementation' (excuse the inaccurate language)
| of bcrypt limits you to 72 characters. If that limit is not
| made clear to the user, then they may find it odd when their
| 73+ character password can have the last N-72 characters
| changed and still successfully log in. Silent truncation is
| most likely a result of ignorance on the part of the software
| developer (I'll admit I did not know about this limit for a
| long time), whereas maximum length could be the opposite.
|
| More info on this, since I'm no expert:
| https://security.stackexchange.com/questions/39849/does-bcry...
| fossuser wrote:
| Thanks - the sites I'm complaining about typically limit
| characters somewhere between 18-32 so I suspect it's
| unrelated to this.
| Sammi wrote:
| You can solve this limitation yourself by implementing a
| simple client side digest hash before sending to the backend
| for proper password hashing. So your backend receives the
| fixed length digest hash and not the actual password for
| hashing. With a good digest hash algorithm like sha256 you
| are effectively able to support "infinitely" long passwords
| without any significant loss of entropy.
| kccqzy wrote:
| The problem with this approach is that now someone on the
| backend will mistakenly think, hey the password is already
| hashed by the client, let's just store that directly in the
| database! And now you essentially have passwords stored in
| plain text.
| charcircuit wrote:
| >like sha256 you are effectively able to support
| "infinitely" long passwords without any significant loss of
| entropy.
|
| I disagree. I used to have my password manager generate
| long passwords, but I realized that the entropy was just
| being clipped to 256 bits by the hash function. It's not
| that crazy to go over. That being said 256 bits of entropy
| is plenty.
| teddyh wrote:
| > _like sha256 you are effectively able to support
| "infinitely" long passwords_
|
| If my math is correct, 256bits of hash can effectively
| support up to about a 36-character password, depending on
| how many bits of entropy you give each character.
| vladvasiliu wrote:
| > Silent truncation of the the password without telling you
|
| Bonus points for truncating the password differently in the
| login form and the password change form. Now you can't login
| anymore!
|
| > Failure because the password is too long, but the error says
| something else (like missing symbol)
|
| A few years ago the local City government in Paris put out some
| new app to pay for parking. You'd have to create an account and
| give them your credit card[0]. When I say they had some
| ridiculous maximum password length, something like 8
| characters, I decided that I could actually take the five
| minutes to pay in person.
|
| I haven't tried the app ever since, so no idea if this crazy
| limitation is still in effect.
|
| ---
|
| [0] There was no option to give the credit card on each
| payment, they had to save it on file. Of course, they weren't
| aware that local banks were rolling out credit cards with
| changing verification codes, so some cards would've had to be
| re-entered anyway...
| syntheticnature wrote:
| > Bonus points for truncating the password differently in the
| login form and the password change form. Now you can't login
| anymore!
|
| Yes, when I setup my first password manager one of my banks
| said "max length 32" so I updated to a 32-character password.
| Then, when I next went to login, I found the login form had
| an off-by-one error and Javascript would truncate the
| password down to 31 characters.
|
| I was lucky and knew just enough to be able to use the
| console to patch the Javascript on the fly. I complained to
| them and they said they'd look into it; a month later I went
| down to a 30-character password, to stay far away from any
| further off-by-one issues.
| emayljames wrote:
| A big EU bank that I have my account (and an online
| account) with, cannot change customers OTP mobile phone
| number if they no longer have access to the old number
| (they require to send an OTP when number is being changed).
| The reason I know this is after several visits and calls
| over many months, all with a lot of effort put in. I am
| assuming they have zero CRUD that doesn't send OTP to the
| old number. A bank with billions should know better.
| TeMPOraL wrote:
| > _A bank with billions should know better._
|
| A bank with billions should have a manual process that
| may involve checking your identity in 20 different ways
| and maybe even pre-registering your whereabouts with the
| police, but ultimately resulting in giving you access to
| your account back.
|
| I'm guessing it might take sending them a strongly-worded
| legal letter to make further progress.
| Enginerrrd wrote:
| >I went down to a 30-character password, to stay far away
| from any further off-by-one issues.
|
| Heh...
|
| Developer: Shoot, we've got an off by one error here. No
| problem, I'll just add one. Or should I subtract one?
|
| * _10 min later*_
|
| OP: That's weird, my 30 character password is now failing.
| emayljames wrote:
| Even bigger brain: I'll just x by 2 and change the DB
| type to LONGTEXT.
| TechBro8615 wrote:
| This has happened to me so many times that I've started
| presumptuously subtracting 2 from any max length a website
| gives me.
| wave100 wrote:
| Ha, funny to see my old bank from college mentioned on here.
| For what it's worth, their site seems to be a lot more
| reasonable about passwords nowadays.
| glasss wrote:
| There was a "bug" a few years back in Dell iDRAC that silently
| truncated the password. Took a number of support calls and
| ticket escalations to get them to recognize it and patch it. It
| occurred to me then that if Dell's enterprise team did it that
| it must be much more rampant than I've seen.
| sofixa wrote:
| iDRACs aren't supposed to be public, and are on average far
| less sensitive than a bank account, so all in all, not that
| bad. And considering the quality of Dell software, it's
| actually better than most of their useless pieces of
| crapware.
| LilBytes wrote:
| I saw this bug.
|
| Security risk or not. Changing your password on the idrac
| and it not being what's expected and having to jump into a
| DC to change 30+ host iDRACs was not ideal.
|
| All because I couldn't find the bug at the time, I read it
| a few weeks later only after over a week of back breaking
| basic sys admin work.
|
| Small bonus. It built my use case for fucking off more on
| premise infrastructure into the cloud.
| rPlayer6554 wrote:
| > An old credit union I was part of in NY (SEFCU) mandated
| passwords with exactly 6 characters. When I complained about
| this I was told it was secure because they forced one of the
| characters to be a symbol.
|
| Woah that's so secure. What if you only had 2 characters; both
| symbols. I'm sure that is 2x as secure.
| michaelcampbell wrote:
| > What if you only had 2 characters; both symbols. I'm sure
| that is 2x as secure.
|
| Wouldn't it be 4x? (2^2)
| mr_smith434 wrote:
| My favorite is silent truncation on the signup page but not on
| the login page.
|
| > I paste in my password. It gets cut off to N characters by
| the form. > I paste that same password on the login page. There
| is no character limit on the login form.
| OGWhales wrote:
| Wow... surely that would've blown up in their faces almost
| immediately.
| fossuser wrote:
| "Just get them to create an account, they can suffer through
| our horrible software after."
| livre wrote:
| The opposite happened to me a few times, signup doesn't
| truncate, the database accepts it but login truncates on the
| backend and you can't login.
| strifey wrote:
| Schwab used to do the "silently truncate to 8 chars" fail, but
| they _also_ silently changed all chars to upper/lower so the
| password was case insensitive.
|
| Still can't believe they were allowed to have such a bad and
| secret password policy for so long.
| xmprt wrote:
| Who in the right mind thought that would be a good idea? It
| seems like the type of case where some executive though that
| failed password attempts would increase customer support load
| by 0.1% and therefore decided to make it a lot easier to log
| in. But in that case, why did they decide to stop at 8? I
| feel like they would have made passwords a 4 digit pin if
| they had their way.
| sjy wrote:
| > they would have made passwords a 4 digit pin if they had
| their way
|
| There's a well-known bank in Australia that has been doing
| this for years [1]. It's very convenient, and if there was
| a significant fraud risk associated with it, you'd think
| they would have changed their policy by now.
|
| [1] https://www.ing.com.au/securebanking/
| [deleted]
| bluGill wrote:
| Probably someone working on a limited mainframeish type
| computer in 1964 when many terminals didn't support lower
| case and the memory to store passwords was expensive. The
| idea of encrypting the password probably didn't exist in
| those days either. None of this mattered because all the
| terminals were inside their building so you had to get by
| the guard to get in. Best practices have moved on many
| times since then.
| OGWhales wrote:
| This was my guess too. Last mainframe I used still used 8
| character, non case-sensitive passwords.
| Spivak wrote:
| Honestly the case thing makes total sense to me. The odds
| that someone knows the my password but not the casing is
| vanishingly low.
|
| For pw manger based passwords sure you just cut your search
| space down by a lot but for human typed passwords that are
| words / sentences ehhh
| kevin_thibedeau wrote:
| Reducing the key space makes brute forcing easier. Nobody
| should accept such outdated password policies rooted in 50
| year old practices that can't be safely used in a world
| with external threats.
| NaturalPhallacy wrote:
| The trouble is some of these passwords are stored on 50
| year old systems!
| fossuser wrote:
| I think FB does this?
|
| Though it's a little bit different when it's an intentional
| tradeoff decision vs. just being bad at software.
|
| In FB's case with billions of non-technical users the
| tradeoff is probably valid.
| vel0city wrote:
| FB does case-inversion of the password. If at first the
| password hashes don't match, it inverts the case (not all
| upper or all lower, but passWORD <-> PASSword) to solve
| if the capslock is on or not.
| fossuser wrote:
| Ah - that is what I remembering, thanks for the
| clarification.
| strifey wrote:
| I think I'm more worried about the lack of complexity than
| the guessability. It removes a huge amount of potential
| variance in any sort of brute force attempt.
| UncleMeat wrote:
| Online brute force basically doesn't happen and can be
| managed by sane traffic filtering.
|
| It _does_ make passwords weaker. But 26^8 is still 200B.
| People aren 't making 100B login attempts to break your
| case-insensitive alphabet-only eight character password.
| strifey wrote:
| Sure, brute force doesn't online typically, but isn't the
| reason we have most password requirements generally for
| the scenario where someone gains offline access to
| password hashes?
| [deleted]
| NaturalPhallacy wrote:
| This is the second post in this thread where people for some
| reason expect banks to be better than others at tech.
|
| I've worked at a bank, in software.
|
| They are _significantly worse_ at tech than other industries.
| They 're propped up by usury, overdraft fees, slow,
| antiquated systems. Why does it take 3 business days to get a
| refund? The information moves in milliseconds today, yet it
| still takes 3 business days to get your money back.
| brutal_chaos_ wrote:
| > people ... expect banks to be better than others at tech.
|
| Banks hold people's life savings among other things and
| thus, I would think, should absolutely be putting the best
| security to practice. Both physical (like safes and so
| forth) and technical.
| [deleted]
| dustinmoris wrote:
| I think that mandatory password changing only weakens security
| because it incentivises users to rotate a single fragment at the
| end of an otherwise static password.
|
| Example:
|
| MyStaticPassword-2019
|
| MyStaticPassword-2020
|
| MyStaticPassword-2021
|
| If an attacker knows that the last 4 characters of a password are
| "2021" then it is additional information which can help to
| possibly crack a cryptographic algorithm.
| wussboy wrote:
| My network login has become progressively simpler as I have
| been forced to change it. I use KeePass and unique/random 20
| character passwords for every website that I log in to. But not
| for work. It used to be "Quite hard and very long password".
| Now it's "NotVeryHardPassword7".
| mikestew wrote:
| Yup, I'd use whatever super-duper random stream of
| consciousness my password manager cares to emit where it not
| for the fact that I have to change it regularly. I'd let the
| password manager handle the logins if the Windows GINA (or
| whatever it's called these days) didn't require me to type
| the whole thing. But if I ever have to type the password
| somewhere, then MyPassword12! it shall be rather than
| something that looks like line noise because I'm not muscle-
| memorizing a new 30 char password every 90 days.
| WinstonSmith84 wrote:
| yup. Even password managers half the time fail to properly
| capture a password change so that the easiest way is simply to
| increment the password, then add that increment in the password
| manager - instead of going through the trouble of generating a
| new random password which may or may not end up getting saved.
| thesuitonym wrote:
| Not only do you get poor passwords like that, you also get
| water cooler chatter about how users "beat the system" by using
| companynameApr2021!
|
| Nothing worse than users blabbing details about their passwords
| like that.
| dspillett wrote:
| The usual answer to that is to dictate a minimum difference
| policy between credentials (meaning you have to provide the
| previous password at the point of change as it can't be read
| from elsewhere if properly stored, but that is usually the case
| as a check against someone changing passwords using a session
| that is accidentally left unlocked). That can lead to
| passwords-on-paper which is an issue itself, though not a high
| risk if security against remote attackers is your only
| significant threat profile.
| mikestew wrote:
| You only have to change it once a year? Such luxury. I have to
| divide by four to figure out how many years I've worked here.
| Thing is, when the topic comes up it seems that everyone on my
| team openly admits to doing just that (static PWD with
| incrementing integers on the end). But they didn't hire me to
| secure their network, so if no one else cares...
| cratermoon wrote:
| My employer requires that all passwords be rotated every 180
| days _unless_ the password is at least 14 characters, then it
| 's good for 365 days.
|
| I maintain a user-facing system that expires passwords after
| 120 days, no exceptions, and I've tried in vain to get that
| restriction lifted.
| korethr wrote:
| And yet, there are Fortune 100 financial institutions that
| require their vendors to have a policy of mandatory 30 day
| rotation for sysadmins and 90 days for non-privileged persons.
| Companies that don't have and enforce said policy are unqualified
| for the privilege of vendorhood. Pointing out this Microsoft
| paper, the NIST guidelines, or the NCSC guidelines will just get
| the subcontracted droids giving you a negative mark on your
| annual vendor security assessment.
|
| No, I am not jaded or bitter on this topic. Why do you ask?
| nottorp wrote:
| Mandatory password changing leads to only one thing: password
| rotation.
|
| I had a bank that expired their online banking passwords every 30
| days (in spite of also having 2FA via physical token ON TOP OF
| THE PASSWORD). Guesss what, my password was word-number-word. I
| just incremented the number 10 months, then reused old numbers.
|
| Incidentally they rebuilt their online interface and changed the
| tokens for new ones. The password doesn't seem to expire any more
| but it's still required for some reason.
| ddingus wrote:
| I wish pass phrases were more widely used.
| jugg1es wrote:
| My company adopted 'passphrases' and we no longer have to change
| it much at all anymore and my life is that much better for it.
| Thanks Microsoft!
| _1 wrote:
| That's what my company did recently ... now I have a 30
| character phrase that expires after 6 months :-/
| serjester wrote:
| A while back I was tasked with getting hundreds of our companies
| computers back online after a ransomware incident bricked them
| and for that I needed users passwords. Our company mandates
| quarterly password changes and as a result I was blown away how
| many people had some variation of "{company_name}{season}{year}"
| as their password. I'm convinced these mandatory password changes
| do more harm than good.
| efitz wrote:
| This is also NIST's guidance. The problem is that PCI requires it
| pretty explicitly, so if your company requires PCI compliance
| then you have to convince your auditor to give you an exception.
| GrantZvolsky wrote:
| Radical idea: Don't let users choose their passwords. Let them
| instead generate access keys.
| jnwatson wrote:
| In my first job, the ancient VMS system for timesheets required
| you to select a password out of a list. You could refresh it as
| many times as you wanted, but you had to type one of the
| passwords provided by the system.
| MaxBarraclough wrote:
| The problem is enabling the user to keep track of the key.
| These two solutions spring to mind:
|
| * Password managers
|
| * Physical objects that hold the key (credit cards, access
| cards)
|
| Or, for a non-solution:
|
| * Just get angry at anyone who forgets their password, while
| also insisting they never write it down (a common approach in
| the bad old days)
| ben509 wrote:
| I think that's the best approach.
|
| My router had a random pre-generated password. It was a series
| of consonant vowel consonant atoms separated by numbers. That
| manages to be reasonably memorable and highly secure, and it's
| reasonably unlikely to land on something someone finds
| offensive.
| partiallypro wrote:
| They still constantly require password changes for Microsoft
| services though
| twobitshifter wrote:
| Just had to do a mandatory change. We were acquired so my
| computer is not fully integrated. To change the password I only
| needed to provide the code from the Authenticator app (MFA)
| Whenever I log in I need the password and the MFA code, but if
| the MFA code is enough to change the pw, what's the point?
| karmicthreat wrote:
| One of the key features to making this work is the attack
| protection features these services have. Okta, Azure, Auth0 all
| have this. Is there an open source alternative? Seems like we
| would need a service, like SPAMCOP is for email, to make it work.
| Cosmows wrote:
| hese days the only sane way to operate is with password managers
| and separate 2fa. One single strong password that is only used
| for accessing the password database. One secure device with the
| 2fa generation.
|
| From there every site can use a long randomized password. With 16
| random characters, pure alphanumeric is more than fine sufficient
| to be essentially impossible to crack. If one does get
| compromised, such as by being stored in plaintext, nothing else
| is. The only way to compromise the user is to compromise the
| password manager key which should never leave the user's
| computer.
|
| Yes it does become a master key, but email already acts like that
| and a well implemented password manager is far better. The
| alternatives all involve bad passwords, password re-use, and
| passwords on post-its.
| mc32 wrote:
| Makes sense in a time where you know if a log-in behavior is
| unusual or not (smart/adaptive auth) and have policies which act
| accordingly.
|
| The big obstacle to reason is baked-in policies encouraged or
| enforced by regulation which demand rotation.
| cratermoon wrote:
| I'm pretty sure at least one of my employers continues to
| mandate passwords expiration date because of a contract, either
| with the government or under government regulation, and the
| regulations are outdated.
| [deleted]
| jimnotgym wrote:
| I knew an old hack IT guy who had a spreadsheet full of users
| passwords which he obtained through demanding them when their
| computers needed fixing. Rotation dealt with that particular
| issue!
|
| Then somewhere else I read an IT policy that said 'You will be
| assigned a password by IT, do not change it.'
|
| I have seen numerous cases of IT support asking users passwords
| to make fixing a machine more permanent. I have seen more than
| one where they kept that record.
|
| I have also seen lots of cases of, 'I have their passwords so I
| can log in to their email when they are away'. We know it is
| stupid, but these smart people didn't.
|
| That is why I still rotate passwords, I know some will be
| compromised internally. I do it on a slow schedule though.
| marcosdumay wrote:
| The fact that all of those are created to circumvent some other
| stupid and baseless security policy speaks loudly. (Except the
| second, that one is the policy itself.)
| hobs wrote:
| I have worked for several companies where when I started they
| actively promoted this practice to make it "easier" for devs to
| "fix" things.
|
| Each time it has been a huge political battle to get people to
| do the most basic not insane things to have even the most basic
| security.
|
| I bet there's a looot of company websites where CompanyName123
| is the default password.
| [deleted]
| pianoben wrote:
| Microsoft has been saying this since before FTA, but nobody seems
| to have told corporate IT. When I was there (2015-2019), we had
| to change our passwords every six months.
| lucb1e wrote:
| Security consultant here - I put it in many of our reports
| (whenever we notice such a policy). They're not exactly
| changing course just yet, but we do try to communicate the good
| news where relevant. Also to avoid complexity requirements
| ("you don't have any digits in correct horse battery staple,
| that cannot be secure!") but to use a blacklist and length
| requirement instead, as recommended by NIST and NCSC (hopefully
| other countries will follow suit).
| brightball wrote:
| I have referenced Microsoft's guidance directly when answering
| enterprise security questionnaires that insisted my company
| provide this functionality.
|
| We offered MFA instead including Fido 2. If password rotation is
| that important, you're welcome to pay for SAML support so that
| you can control it yourself, but the platform would not be
| offering it.
| delaynomore wrote:
| Turning off mandatory rotation without strengthening other
| controls would simply allow users to keep their weak password
| (Spring2021! or {CompanyName}2021!) for a longer period of time.
| lovelyviking wrote:
| I wish I could explain that to some _dumb_ system administrator
| in our company some years ago ...
|
| Perhaps it's a general question of how to explain something to
| someone who is not too bright to comprehend it?
| swiley wrote:
| Shared secret auth in general is ancient and obsolete.
| rPlayer6554 wrote:
| > Researchers have increasingly come to the consensus that the
| best passwords are at least 11 characters long, randomly
| generated, and made up of upper- and lower-case letters, symbols
| (such as a %, *, or >), and numbers.
|
| Relevant XKCD? https://xkcd.com/936/
| birdyrooster wrote:
| They gave me the password "Welcome1" so I just kept incrementing
| it until I quit. "Welcome3"
| abunuwas wrote:
| I welcome websites removing mandatory password rotation. And it's
| true that rotating passwords doesn't necessarily reduce the
| chances of having it brute-forced. But that's not the point of
| changing passwords every so often. Rotating passwords is useful
| because a security vulnerability in the site or some mistake on
| your part can get the password exposed. You're not trying to
| protect yourself against super hackers (that's the website's
| responsibility), but against your own mistakes.
| dheera wrote:
| Yep. Every time a website asks me to rotate a password I end up
| using a bad password for a while and rotating it later.
| aequitas wrote:
| I can't honestly think of any website that enforces password
| rotation. Except for corporate application websites, which I
| would consider application's that fall under my companies
| password security regime.
|
| I wouldn't want to image a world where every website would
| force me to rotate my password, each with it's own interval and
| method. Imagine the upkeep time cost.
| bombcar wrote:
| Many of my banks do password rotation forces - one which
| annoyingly requires you to update your password if you
| haven't logged in in 90 days - but doesn't count Touch ID on
| their app as a login.
| kstrauser wrote:
| Almost every .gov I work with requires it regularly, along
| with account deactivation if you haven't logged in very
| recently.
|
| There's one particular website I have to log into exactly
| once per year. I have monthly reminders to log into and
| change my password anyway, lest I have to create a new
| account 10 months later.
| svara wrote:
| Ok, but if you're using a password manager with long random
| passwords, that changes the calculation. The advantage might not
| be huge at the end of the day, but it's non-zero.
| ocdtrekkie wrote:
| It's no longer a recommended industry standard, but
| unfortunately, it is still basically required, because many
| compliance policies have not updated. I would be shocked if at
| least some of Microsoft is still required to employ password
| rotation policies because of their own compliance requirements.
|
| At least one policy I am looking at maintains the 90 day rotation
| requirement if you use basic password authentication, but offers
| alternative options for compliance with other authentication
| features. But even most of those tend to have yearly rotation
| requirements.
| muttled wrote:
| Wording is important too. You can't say something you'd like to
| move to "no passwords." You might get further with "password-
| less."
| pitaj wrote:
| Recently had a long discussion over email with an executive
| security officer of my company regarding this topic. Their
| conclusion was basically "until the standards change this is
| how it will be".
| artful-hacker wrote:
| PCI-DSS is commonly cited as having this requirement, and its a
| huge pain in my ass.
| xtracto wrote:
| I just went through PCI-DSS and SOC2 certifications in the
| last 3 months. OMG was that painful.
| post_break wrote:
| Tell that to my office 365 please. I'm sick of changing it. It's
| stressful for me and I'm often worried I'll get locked out at a
| very bad time.
| 0xffff2 wrote:
| Huh? Microsoft doesn't require password rotation AFAIK. Are you
| talking about a work account where your org has mandated
| password rotation?
| post_break wrote:
| I'm the admin of a 365 account for an org, my account forces
| it. I seemingly have no way to turn it off, even for my
| account.
| marcosdumay wrote:
| The domain administrator of your org forces it. The office
| 365 just enforces the domain choices.
|
| And yeah, if you think using your org domain to
| authenticate people on a 3rd party cloud server is a
| security problem, well you are not alone.
| post_break wrote:
| No I'm saying I'm the admin, for our whole 365. And I
| have it and can't turn it off for myself.
| technion wrote:
| If you have password rotations forced in Office 365, it will
| actually prompt you at the admin page with a recommendation to
| turn them off. There's documentation here:
|
| https://docs.microsoft.com/en-us/microsoft-365/admin/manage/...
|
| Which states: Current research strongly
| indicates that mandated password changes do more harm than good
| freeflight wrote:
| Tbh I don't trust passwords to keep my accounts save, it's 2FA
| all the way.
|
| Passwords have this nasty tendency to get leaked, one of my older
| e-mail accounts is listed in 12 different breaches on
| haveibeenpwned.com
|
| And while the ideal is not to reuse passwords, keeping that
| practice up with the number of accounts that are nowadays
| required with a somewhat digital lifestyle is kind of impossible,
| short of using a password manager.
|
| But then you are locked into a password manager and gotta hope it
| works on all the devices you gonna need your passwords on or else
| you will be stuck manually putting in long and complex passwords.
| krupan wrote:
| This!! Passwords are old and obsolete. We should have stopped
| using them years ago
| hsbauauvhabzb wrote:
| It's worth noting that MFA solves credential sprays but not
| targeted phishing
| bob1029 wrote:
| I still say we should move into the direction of doing away with
| user passwords altogether and viewing the device itself as the
| basis for authentication.
|
| Everyone has a personal computing device in 2021. Who is still
| sharing a family computer and needs to switch user accounts? How
| many businesses still operate with shared workstations?
|
| Adding additional sessions (i.e. devices) to my netflix account
| should be as simple as scanning a QR code from an already-
| authenticated device with my unauthenticated device. This pattern
| feels magical with applications like Whatsapp web interface. It
| instantly works and you had to remember nothing. Virtually
| everything along the consumer segment could work like this.
|
| There are obviously pedantic edge cases that we could invent all
| day, but there are also blindingly-obvious value paths we can go
| down as well. Recovery of lost devices is clearly a big issue
| with this scheme, but its the same resolution in any scenario.
| You resort to SMS/Email/Phone to re-establish your identity on
| the new device and use some emergency token issued as part of
| recovery to bootstrap the whole thing again. It's exactly the
| same shape problem as forgetting your password.
| tim333 wrote:
| As to what works in practice, most cryptocurrency exchange
| accounts, which are prime hacking targets as you can steal
| large amounts of money irreversibly work as follows:
|
| Enter email@address.com and easypassword1
|
| You are then asked for Google Authenticator code, which is a
| six digit code based on a secret key and the time of day.
|
| It generally works quite well though it's a pain if you lose
| your Authenticator key (stored the in a phone app usually)
| vladvasiliu wrote:
| What happens when one of the "personal" devices gets lost? How
| do you authenticate to the device in the first place?
|
| I also don't feel like lugging around my employer's laptop
| wherever I go, but I sometimes happen to need to check an email
| or something when I'm at a friend's house (so I can't register
| the device). Should I not be able to do that?
|
| > Who is still sharing a family computer and needs to switch
| user accounts?
|
| My client does. People work in shifts, it would make absolutely
| no financial sense to have double the number of computers. It
| would also be a pain to have to switch screens, etc. Or much
| more expensive to equip everyone with laptops.
| bob1029 wrote:
| > What happens when one of the "personal" devices gets lost?
| How do you authenticate to the device in the first place?
|
| The device you initially register on is the one that has
| access. Subsequent devices could chain off of that one.
|
| If you lose a single device and have others on the same
| account, it's trivial to recover. If you lose _all_ devices
| on the account, it 's the same scenario as forgetting your
| gmail password. You go to some recovery page and follow steps
| to prove your identity again.
| vladvasiliu wrote:
| I've got this point, this allows you to maintain access to
| your accounts.
|
| But the question was more along the lines of: how do you
| protect the lost device from being used by the thief,
| thereby impersonating you? You presumably need some method
| to let the device know it's really you.
|
| So if it's not a password, what is it? I seem to remember
| an article a few years back of a group (probably the CCC,
| but I'm not sure) that managed to reproduce Angela Merkel's
| fingerprint without physical access to her fingers. Apple
| claims Face ID is more secure. But is it, really? I
| honestly don't know, and finger unlock was supposed to be
| secure, too. What happens if we find out it isn't?
| bob1029 wrote:
| > You presumably need some method to let the device know
| it's really you.
|
| Enter literally every mobile device unlock/security
| scheme since this all began.
|
| Which is more secure in the average case today?
|
| A) A password or passphrase, with all of its historical
| flaws in aggregate.
|
| B) Apple's iOS unlock feature using a recommended/default
| configuration, and some 256 bit session token tucked away
| somewhere in secure device storage.
|
| I would personally have a hard time answering this
| directly. Lots of "it depends", which tells me there are
| contexts where each scheme can make sense.
|
| If you were to apply the spy movie aesthetic here, you
| would probably find it much easier to coax a password out
| of an unwilling participant than it would be to hack open
| a pile of cryptographic secrets you found laying on the
| street.
| jpindar wrote:
| >How many businesses still operate with shared workstations?
|
| The ones that deal with physical objects. Ones that control
| machinery, keep track of objects in warehouses and stores, etc.
| dsjoerg wrote:
| > Everyone has a personal computing device in 2021.
|
| 85% of Americans have a smartphone. 15% of Americans do not.
| https://www.pewresearch.org/internet/fact-sheet/mobile/
|
| What are the stats for other countries?
| billytetrud wrote:
| > Researchers have increasingly come to the consensus that the
| best passwords are at least 11 characters long, randomly
| generated, and made up of upper- and lower-case letters, symbols
| (such as a %, *, or >), and numbers. Those traits make them
| especially hard for most people to remember
|
| Sounds pretty wrong to me. I think when they say "the best
| passwords" they mean the hardest to crack. But a password that
| you need to remember that's hard to remember is not a good
| password. It doesn't take much research to understand that
| passphrases are the best kind of password. 4 random words (if
| throttled, 5-6 if not eg for local encryption). It's a bit silly
| to me for this article to imply these people are spending years
| researching passwords, and this is what they come up with. We
| need to switch to client side certs already. Passwords for
| websites are obsolete.
| lostcolony wrote:
| I mean...passphrases, plus a little noise thrown in, make sense
| for logging into a password manager.
|
| After that, the advice sounds pretty correct to me.
| billytetrud wrote:
| If you're using a password manager, shouldn't you just have
| it generate a random strong password you don't expect to
| remember? If you're remembering it, it's really best to not
| use noise, just plain correctly spelled lower case words.
| Adding an additional word adds both more security and is
| easier to remember than adding an ampersand somewhere in your
| password
| lostcolony wrote:
| What it generates you have control of. So you can say "I
| want uppercase, lowercase, numbers, characters, of length
| X". So the guidelines are still relevant.
|
| The only thing you should remember is the password into
| your password manager, and if you want to add more words,
| by all means; I just find it quicker to type, no harder to
| remember, while making a dictionary attack unfeasible, by
| adding a character or two to the passphrase. I.e.,
| "correct!horsebattery,staple" (though I agree that at four
| words you're fine anyway; I'm just saying that with a
| little noise thrown in I can type two or three words, plus
| a couple standalone, easy to remember characters for the
| same level of complexity)
| billytetrud wrote:
| Fair enough
| charcircuit wrote:
| I think it would be good to have mandatory password changing when
| it is discovered that you have reused a password. Password reuse
| is a major security breach waiting to happen.
| Yhippa wrote:
| One place I worked at had a policy that you couldn't use any
| password within your 10 most recent passwords. So when it came
| time to change they would do 10 password resets in succession so
| that they could use their original password and never have to
| remember a new one.
| qw3rty01 wrote:
| The article kinda misses the reason why mandatory password
| changes existed in the first place -- unknown breaches. The idea
| was that if there was an undetected breach, the attacker would
| have a maximum of the mandatory password change to use
| credentials. You would still have mandatory password changes upon
| discovering a breach, which would reset the counter. And the
| article wasn't very clear as to why this is no longer
| recommended, but when mandatory password changes are enforced,
| users tend to make new passwords which are trivial to crack if
| you have a known old password. So if there's an unknown (or even
| known) breach, users will tend to make a new password which an
| attacker can easily guess given the older known passwords, losing
| any benefit gained from mandatory password changes. And this is
| worse than not having mandatory password changes, because rare
| password changes (when a breach is discovered) don't put people
| into the habit of just iterating off of an old password.
| ocdtrekkie wrote:
| Yeah, I think there's value in it, but if you don't have a way
| to prevent "plus one passwords", it probably isn't super
| effective anyways. It may be a case where frustrating the user
| four times a year isn't worth it... maybe just frustrating them
| once a year will lead people to put more effort into making
| their passwords suitably different.
| qw3rty01 wrote:
| There definitely is value in it if users created proper
| passwords, but path of least resistance tends to win out in
| the end, and people will just find ways around the mechanisms
| to prevent weaker derived passwords.
| GordonS wrote:
| Four times a year? I've had to change mine once a month for
| the past 20 years. Needless to say, I increment a numeric
| suffix that wraps around every 10 or so months.
|
| It has _always_ seemed like a totally pointless exercise.
|
| I can see potential value for service accounts, as long as
| you have automation in place to change them where needed -
| but for user accounts, it's complete madness.
| marcosdumay wrote:
| Hum... I have never seen any place that implemented
| password rotation for the users and didn't exempt service
| accounts. And the security solution sellers I've talked to
| are all either on the position of "yeah, password rotation
| is incredibly important, but you can't rotate service
| accounts" or "yeah, I know you don't rotate the password of
| service accounts (no need to tell me), here's a tool to
| reduce the risk this causes".
| GordonS wrote:
| Place I work started rotating service account passwords
| around a year ago, using automation built in to some
| super expensive PIM (Privileged Identity Management)
| system.
| marcosdumay wrote:
| Just to complement, so next time I can say I heard about
| one place on the internet... Does your workplace require
| password rotation for personal users?
| GordonS wrote:
| Yes it does - something like once a month. And
| every.single.employee is going to be incrementing a
| numeric suffix, providing no increase to security
| whatsoever, and annoying the hell out of
| every.single.employee. Actually, it probably weakens
| security, since employees will be more likely to have
| notes of their current password around, since it's
| difficult to remember the current suffix, since it
| changes so damn often :/
| ocdtrekkie wrote:
| Microsoft's approach now is to recommend using Managed
| Service Accounts, which is an Active Directory feature in
| modern Windows servers. They rotate their own passwords
| through some sort of magic. That being said, plenty of
| janky old Windows apps won't work with them anyways.
| csours wrote:
| "A friend" used to have the password set to the 3 character
| month name + the month ordinal + "!" - MarMar04!
|
| We were required to change passwords once a month, and not
| re-use any of our last 6 passwords.
| rightbyte wrote:
| Nice! My friend rotate through 3 digits to be able to guess
| it quicker when he forgets which digit it is. This solves
| it.
| letitbeirie wrote:
| My "friend" doesn't use this system anymore, but passwords
| along the line of '1stQuarter2001!' worked for well over a
| decade of being required to change passwords 4 times a
| year.
| naikrovek wrote:
| do attackers wait to use passwords months after they've
| compromised those passwords? or, do they give themselves other
| ways to maintain their access so that no passwords stand in
| their way from that point on?
|
| it's the latter, not the former. once you're compromised,
| passwords, changed or not, are no longer an obstacle at all.
|
| password rotation does not increase security.
| numpad0 wrote:
| > do attackers wait to use passwords months
|
| Unix-like OS in 80s-90s truncated passwords to 8 bytes,
| hashed in MD5 and stored them to regular file `/etc/passwd`.
| And in those era it was estimated to take six months to few
| centuries to brute force a password, therefore it was
| recommended to maximally complicate the password within 8
| letters in length, and change it every one half the brute
| forcing time, or three months. Supposedly everything made
| sense in that timeframe in that context.
| jodrellblank wrote:
| A 1979 UNIX /etc/passwd file surfaced a couple of years ago
| (it's on Github[1]) and people tried to brute force the
| passwords; Brian Kernighan's was the weakest. Ken Thomson's
| took " _more than four days on an AMD Radeon RX Vega64
| system running hashcat ( a password cracking tool) at about
| 930MH /s (Million Hashes per second)_" and was the last to
| fall.
|
| https://inbox.vuxu.org/tuhs/87bluxpqy0.fsf@vuxu.org/
|
| https://fossbytes.com/unix-co-founder-ken-thompsons-bsd-
| pass...
|
| [1] https://github.com/dspinellis/unix-history-
| repo/tree/BSD-3-S...
| cesarb wrote:
| > Unix-like OS in 80s-90s truncated passwords to 8 bytes,
| hashed in MD5 and stored them to regular file
| `/etc/passwd`.
|
| In the era when password hashes were still readable to
| everyone in /etc/passwd (this was later fixed by storing
| the passwords instead in a shadow file called /etc/shadow
| which can only be read by root), it was not MD5, but
| "crypt" (a DES variant). AFAIK, the MD5 and newer password
| hashing schemes don't truncate the password to 8 bytes,
| only traditional "crypt" did that.
| crazygringo wrote:
| Really depends on the level of access the password gives you.
|
| If you're infiltrating a company, most people's accounts
| certainly don't give you the level of access required to
| bypass the need for passwords entirely. You'd have to be
| specifically hacking a sysadmin's account or something.
|
| There are very many different levels of "compromised" and
| they're not all the same.
|
| That being said, I agree with the overall premise that
| password rotation is outdated.
| grepthisab wrote:
| Hi, attacker here, I usually use the password immediately but
| it really depends on the level of user as to whether I can
| ensure that password changes won't affect me going forward.
| If you're a normal user, changing the password is helpful.
| Root? Forget about it.
| SamuelAdams wrote:
| I once read a book where an attacker accessed a live system
| with a set of compromised credentials, then found some
| "disabled" accounts from retired staff, re-enabled them, then
| simply used the retired accounts for routine access. Sventek
| was one of those, I think.
| teddyh wrote:
| https://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_(book)
| RcouF1uZ4gsC wrote:
| It sounds good in theory, but in practice rotating passwords
| really doesn't help much. You alluded to it in your last
| sentence, but if you require password rotations, say every
| year, a lot of your users will end up using:
|
| basepassword-2021
|
| which they will change next year to
|
| basepassword-2022
|
| Because password hashing makes it impossible to retrieve the
| original password, there is no way to guard against people just
| using a basepassword and appending some type of counter to it.
|
| Thus if there really is a breach where the plaintext password
| is recovered by an attacker it is trivial to find out what this
| year's version is.
|
| So all you end up doing is needlessly irritating your users,
| for not much security.
|
| Multifactor Authentication is a much better solution for the
| issues of unknown breaches.
| ajuc wrote:
| > Because password hashing makes it impossible to retrieve
| the original password, there is no way to guard against
| people just using a basepassword and appending some type of
| counter to it.
|
| Almost all the implementations require the old password when
| you change it to the new password, so it's trivial to check
| if they are too similar. def
| changePassword(login, cleartextOld, cleartextNew):
| if too_similar(cleartextOld, cleartextNew):
| return new Error("too similar") hashOld =
| hash(cleartextOld) hashNew = hash(cleartextNew)
| if authorized(login, hashOld):
| setPassword(login, hashNew) return new Ok();
|
| If you're afraid of sending cleartext passwords - do the
| too_similar check on the client side. The users that can
| write their own client to bypass client-side checks are
| exactly the users you don't need to worry about.
| gmfawcett wrote:
| A user could defeat this by changing to an intermediary
| password and then incrementing the original. E.g. sign in
| with current password "cat100", change it to "dog100", then
| sign in as "dog100" and change to "cat101".
| tshaddox wrote:
| The system can just store the last n passwords (salted
| and hashed, of course) for each user. I seem to recall
| some software I had to use in college wouldn't let you
| toggle between passwords like this.
| unrealhoang wrote:
| Storing salted & hashed passwords can only prevent reuse
| the exact old password, it can't prevent reuse & increase
| though.
| tshaddox wrote:
| Unless you generate all the password variations upfront
| and salt+hash them all! I think I've heard that some
| place (maybe Facebook?) does this for common password
| entry mistakes like capitalization.
| michaelt wrote:
| Ah, but one could write a script to change password n+1
| times.
|
| That's why, to encourage users to assume last month's
| password was compromised, when my users change their
| password the old password is automatically posted to
| twitter
|
| /s
| garmaine wrote:
| > Because password hashing makes it impossible to retrieve
| the original password, there is no way to guard against
| people just using a basepassword and appending some type of
| counter to it.
|
| > Thus if there really is a breach where the plaintext
| password is recovered by an attacker it is trivial to find
| out what this year's version is.
|
| These are contradictory statements.
| zrail wrote:
| > there is no way to guard against people just using a
| basepassword and appending some type of counter to it.
|
| Sure there is. In your update logic, decrement any numbers
| and check the hash against the existing password.
| Alternatively, require the existing password in the same form
| and you don't have to check against hashes, since you have
| the plaintext password right there.
| unionpivo wrote:
| Sure thaen you have:
|
| SomePasswordABC SomePasswordDEF SomePasswordGHI
|
| ...
|
| Or
|
| My1Password! My2Password! My3Password!
|
| ...
|
| Or
|
| MyPasswordUno MyPasswordDue MyPasswordTre
| avianlyric wrote:
| I think you underestimate people inventiveness when it
| comes to circumventing these types of systems.
|
| People will either keep trying new strategies to embed
| counters in their passwords (maybe increment a letter, or
| multiple a number by 10), or they'll just write the
| password on a post-it they keep on their laptop.
|
| Either way you've now got a whole load of complicated code
| that makes it harder to people to create genuinely strong
| and memorable passwords, and no additional security.
| josephcsible wrote:
| This wouldn't work either. It would just make users bounce
| between 2 passwords: foo100 -> bar200 -> foo101 -> bar201
| -> foo102, etc.
| banana_giraffe wrote:
| The one system where I saw this implemented in practice
| used my last x passwords to check. I think "x" was 50
|
| Because it had a fairly short password cycle, I'm sure
| most users ended up with something like
| "password1!TwentyFour" then "password1!TwentyFive".
|
| Me: I just changed my password 51 times when it was time.
| I'm not sure what point I was proving, but I was proud of
| myself.
| josephcsible wrote:
| You can't stop someone's next password from being a
| variant of their next-to-last one unless you store them
| unhashed.
| banana_giraffe wrote:
| Couldn't you hash some obvious variants of the new
| password to test against? I always assumed this system
| did that since it would reject some passwords that were
| close to old passwords.
|
| Of course, it's also possible they stored the clear text
| password, I have no real way of knowing.
| josephcsible wrote:
| > Couldn't you hash some obvious variants of the new
| password to test against?
|
| This is impractical if you're following good password
| storage practices. Assume the user's new password is 16
| characters long, and that only the 95 printable
| characters are allowed in passwords. Then to test that
| the Levenshtein distances between it and the user's last
| 5 passwords are all greater than 1, the server would have
| to compute (5 * (1 + 95 * 17 + 16 + 94 * 16)) = 15,680
| different hashes, which will take quite a while if you
| picked a secure iteration count for your password hashing
| function. And even if you did this, it still couldn't
| detect mypassword100100 -> mypassword101101 ->
| mypassword102102, etc. (Making sure the Levenshtein
| distances are greater than 2 would require checking
| millions of hashes.)
| RcouF1uZ4gsC wrote:
| > Alternatively, require the existing password in the same
| form and you don't have to check against hashes, since you
| have the plaintext password right there.
|
| Presumably, you will also have a forgot password flow that
| allows you to change your password without entering the old
| one.
|
| People will make things easy for themselves. Coming up with
| good passwords is hard. Having to rotate passwords just
| seems like a lot of busywork and people will make it as
| easy for themselves as possible.
| [deleted]
| glasss wrote:
| I don't believe there is any function to perform these
| checks in Windows Active Directory or Office 365.
| UnquietTinkerer wrote:
| Off topic for password rotation, but has anyone tried assigning
| randomly generated passwords to the users rather than letting
| them choose their own?
|
| People (including me) _hate_ memorizing things and would
| probably write an assigned password down, but isn't it better
| to expose passwords to nosy coworkers than to the whole
| internet, as is so often the case with weak or reused
| passwords?
| benhurmarcel wrote:
| Best way to have all passwords written on post-its under each
| monitor.
| jodrellblank wrote:
| You have access to the office where the monitor is, you
| have the post-it note. Somewhere you are, something you
| have; 2FA right there.
| wolverine876 wrote:
| That's been our practice, for the reasons you describe, and
| we also take steps to make the passwords memorable (while
| retaining sufficient resistance to cracking). We also tell
| users that if they write down the password, don't write
| 'password' or the username or anything else on the paper -
| you will know what it is - and don't put it someplace obvious
| (on the monitor, under the keyboard, etc.).
| teddyh wrote:
| > _has anyone tried assigning randomly generated passwords to
| the users_
|
| We do that. We generate long random-character passwords (both
| for e-mail, web sites, and other accounts), and we don't
| provide any online way for users to change them. If the users
| need to change a password, they have to contact us to do it
| (which is reasonable, since a big part of our value
| proposition is our responsive support). We only _very
| occasionally_ even get such requests, and _even more_ seldom
| get requests from users to set their own passwords. So far,
| _everybody_ has been perfectly satisfied when hearing "No,
| users don't set their own passwords. We can generate a new
| one for you any time you like.".
|
| This policy has been in effect since before my time, and I
| have worked here for more than 10 years. During this time,
| there was _one_ user who really wanted something more
| memorizable for a specific account, so I set a
| correcthorsebatterystaple-style password on that account
| only. One other user had trouble adding the password to their
| password manager, and I had to help them do that. Otherwise,
| no problems.
| cratermoon wrote:
| You'd have to make users change their password every day to
| fend off undetected breaches now.
| tinus_hn wrote:
| If your security is breached every day passwords, whether you
| change them daily or not, are not going to save you.
| cratermoon wrote:
| It's not about one company being breached any more. It's
| about the entire world of password databases, rainbow
| tables, easy and fast cracking tools.
| tinus_hn wrote:
| Why would that require changing passwords every day? You
| can't use these tools without compromising the site
| first.
| cratermoon wrote:
| One of original motivations for password expiration was
| the belief that if your password DB was stolen, you had
| some significant amount of time before any malicious
| party would be able to crack a password and use it. That
| is no longer true: it's extremely likely that at least
| one user in your system has a password that is trivially
| cracked or in a rainbow table. Your system is vulnerable
| in a day, or less, after you've had your passwords
| stolen.
| bakatubas wrote:
| Or mandate 2FA and password managers.
| goodpoint wrote:
| Even that is often not enough: sessions are long lived and
| very often stealing a cookie is all the attacker needs.
| tamrix wrote:
| Just going to say, if you've been beached, you've pretty much
| done for anyway.
|
| The focus should be on preventing a security breach, not what
| to do after its happened.
| tape_measure wrote:
| Would it be a bad idea to salt and hash probable increments of
| a password when it is changed? For example, password would be
| salted, hashed, and stored along with Password, password1, etc.
|
| Then the system could reject these on the next password change
| without storage of the original plaintext password.
| tape_measure wrote:
| ixwt gave a better solution - do these calculations when the
| password is changed, not when it is set. Therefore, less
| storage is required
| andi999 wrote:
| Actually the fastest possible way to detect unknows breaches on
| the user side is to show your last login time. (On the server
| side is looking for IP patterns)
| crazygringo wrote:
| In theory, but in practice some accounts are only rarely
| accessed by their intended user (might not log in for months
| at a time). And on the flip side, it's really easy to ignore
| the displayed last log-in time/IP/location altogether.
| charcircuit wrote:
| Attackers can easily mitigate this by using residential
| proxies.
| slaymaker1907 wrote:
| I think approximate location would be a good idea too. I
| wouldn't remember the last time I logged in to many important
| services since I do it so often. Relatedly, I have trouble
| remembering when I paid for so something so just looking at
| my banking log for fraud requires me to see who the payment
| actually goes out to.
| millerm wrote:
| Unfortunately, a lot of us are using VPNs now. So, location
| isn't a very good indicator as that would provide a lot of
| false positives. That actually happened to me recently, and
| I though "Oh yeah, I was using a VPN then." So, that
| indicator is just getting worse as I use a VPN on my phone
| all the time now.
| [deleted]
| TheDudeMan wrote:
| It does not seem that difficult to detect when the new password
| is very similar to the old password. Do it on the client side
| on a page that the user enters both the old and the new. And
| give the user guidance to use a password manager and auto-
| generated password.
| ed25519FUUU wrote:
| The whole point of this article is that rotating passwords is
| pointless. It doesn't solve the original problem. MFA is the
| solution to that problem, not password rotation policies with
| Byzantine change requirements.
|
| A better focus is on plugging the hole where the password was
| stolen. If it's not plugged the password will simply be
| stolen again.
| RandallBrown wrote:
| It helps with the original problem.
|
| The reason rotating passwords is pointless is because
| people always end up changing their password to some easy
| to guess variation of the original password. If you prevent
| that from happening, the new password won't be guessable if
| you have the old one.
| II2II wrote:
| If I recall correctly: Active Directory can be setup so that
| the last few passwords cannot be reused, otherwise people
| would just cycle through two passwords. I am guessing that
| people would simply use a variation of their second to last
| password to come up with a new password under your proposal.
| bentcorner wrote:
| A long time ago as a student I worked at a company that had
| mandatory password changes every month. So I just used the
| same password and appended the current month to it.
| gmfawcett wrote:
| If the old password is salted and hashed (which it should
| be), then it is practically impossible to detect when the new
| password is similar.
| Kranar wrote:
| OP literally gave a method for how to do it.
| gmfawcett wrote:
| Unfortunately it's an easily defeated method. The
| motivated user just changes their password to a temporary
| value, and then again to the incremented value.
| bobthepanda wrote:
| I've been at places where the old passwords seemed to be
| kept around, so that it was detected whether or not you
| were switching to the password you used six or seven
| passwords ago.
| throwawayboise wrote:
| This is done by keeping the old hashes around. The new
| password hash is compared to prior hashes to be sure it
| doesn't match any of them. This only catches exact
| matches on re-used passwords.
|
| Or, the current plaintext password is compared to the new
| plaintext password (normally a password change requires
| the current password) so you can do more sophisticated
| similarity checks, but only compared to the current
| passord, not any older ones.
| Spooky23 wrote:
| Some IDM products store the password with symmetric
| encryption and analyze it. Siteminder is/was one that
| spooked to mind.
| Kranar wrote:
| A user can also trivially defeat any password system by
| publishing their password to Facebook.
|
| The purpose of preventing similar passwords isn't to
| prevent a user from defeating themselves, it's to prevent
| an adversary from defeating the user.
|
| Now you can rightfully argue that blocking similar
| passwords isn't an effective measure against an
| adversary, and this article kind of suggests that... but
| it is possible to implement such a system.
| gmfawcett wrote:
| Of course, you're right that it's possible, and that they
| have easier ways to subvert the system.
| nearbuy wrote:
| True, but if someone is really motivated to undermine
| their own security, I don't think there's anything you
| can do to stop them.
|
| I think the idea is that most users will just choose
| another password if you tell them the one they entered is
| too similar to their previous password.
| ixwt wrote:
| Not true. If you have the new password, and old salt and
| hash, you could change a few things in the new password
| (common things, like increment or decrement a number if
| there is on the end), and hash it with the old salt. All
| this would be done when updating the old password.
| gmfawcett wrote:
| Ah, fair enough, you could do that.
| Jiejeing wrote:
| Proper password change procedures generally require the old
| password to update it, so the code running on that page
| theoretically has access to both and can run a similarity
| check.
|
| But my opinion is that ensuring creative passwords with an
| unclear similarity rule will only result in creative
| bypasses of that rule.
| muttled wrote:
| A better focus for security efforts is detection of compromise.
| For example, say you detect a user has signed in from 2
| different countries in a short window or perhaps malware signs
| are discovered in their cloud storage. Perhaps MFA is failing
| often for a user meaning an attacker is successfully using a
| password but is unable to get past confirmation on the user's
| phone.
| jaywalk wrote:
| This is the key. With Okta for example, you can configure a
| maximum velocity for a user for Behavior Detection to trigger
| additional scrutiny on a login. _That_ type of stuff is
| useful.
| rtkwe wrote:
| How well does this handle things like logging in from
| mobile devices? If I logged in from my desktop and later
| from my mobile phone I would appear to zip 350 miles
| because my mobile data exits the phone network 2 states and
| 350 miles away.
| moron4hire wrote:
| I don't understand what you mean. The cellular network to
| which you are connected is not forwarding your requests
| to your "home" cellular network.
| quantumcd wrote:
| Not sure about Okta, but systems I've seen in the past
| (fraud detection etc) will quickly learn the pattern and
| not challenge you as often. It depends a lot on the data
| points the system uses to calculate risk as well as any
| configurable thresholds.
| hsbauauvhabzb wrote:
| In some cases it can make sense, one off the top of my head is
| captured but uncracked NTLM credentials - rotating the password
| (even if it's +1) invalidates the existing hash. There's probably
| better ways of doing it technically (resalting the password) but
| they're not technically possible.
| SavantIdiot wrote:
| I'm sorry, but Prof. Falken never would have chosen "JOSHUA" to
| secure what is essentially the most important computer in all of
| DARPA/CIA/NSA, etc. that was connected to a landline.
| kipchak wrote:
| I believe this has been Microsoft's guidance as far back as 2016,
| with the caveat of using Azure AD risk analysis /MFA.[1]
|
| >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/...
| solatic wrote:
| > Experiments have shown that users do not choose a new
| independent password; rather, they choose an update of the old
| one.
|
| 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.
| iso1631 wrote:
| I used my PW generated password on a site earlier, the site
| refused to accept it. 2^102 bit aren't enough (18 from 52
| random upper/lower characters) aren't accepted, but P@55word
| was fine.
| andromeduck wrote:
| Password must between 6-12 characters...
|
| _rips hair out_
| teekert wrote:
| If only I could use my pw manager at the windows login
| prompt.
| Larrikin wrote:
| 1password syncs to your phone. I can count on one hand the
| number of passwords I actually have memorized
| benhurmarcel wrote:
| I use 1password for everything, but I need to type my
| professional Windows password every time I log in, I'm
| not copying a password from my phone every time I come
| back from the bathroom.
| cyberpunk wrote:
| I store a 32 char random string on a yubikey and have it
| setup so a "long press" on it enters it, works pretty
| well...
| Godel_unicode wrote:
| I'm curious why you use this and not the Windows
| integration with yubikey?
|
| https://www.yubico.com/products/computer-login-tools/
| cyberpunk wrote:
| I'm on a Mac and couldn't be arsed setting it up properly
| ;) It's fairly easy to put a static OTP on two keys
| incase I lose one also instead of trying to register two
| with the OS.
|
| Also I can use it for various other things (like password
| manager secret etc) which don't support yubis out of the
| box.
| michaelcampbell wrote:
| Indeed. I use a passphrase, or a series of typeable but
| random words in the 'correcthorsebatterystaple' vein for
| that.
| jackson1442 wrote:
| Exactly. My university requires a yearly password update. I
| have to manually enter my password to log into computers,
| print release stations, a billion domains that just use an
| LDAP connector instead of our Shibboleth page, servers
| after home directory wipes, etc.
|
| 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.
| kevin_thibedeau wrote:
| They've allowed third party fingerprint scanners to handle
| login so the APIs are there to do it.
| syntheticnature wrote:
| Indeed, my work login password, with regular rotation
| requirements, has been dropping entropy by a few bits each
| time it comes up for renewal. I work to make my work
| passwords as different as I can, but that password doesn't
| get used enough for me to trivially remember it, and it
| can't be offloaded to a password manager easily.
| ben0x539 wrote:
| This is _specifically_ the one place where we require a
| rotating password too, so I think those experiments are
| informative.
| FredPret wrote:
| Internet1...Internet2...etc
| robbyking wrote:
| > _These policies drive users to very predictable passwords_
|
| 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_.
| ifdefdebug wrote:
| Did you just give away very predictable credentials from a
| very predictable person with full access to very predictable
| IT equipment?
| moron4hire wrote:
| With passwords that simple, it's crackable almost
| instantaneously without any preknowledge of the password
| format. That, coupled with the fact that systems get
| randomly attacked all the time, I doubt it's really that
| big of a deal.
|
| Attackers don't need hints on passwords, they don't need
| hints on targets. They just target everyone, and try all
| easy passwords.
| ivalm wrote:
| But if the password is salted is it still easy to crack?
| hansvm wrote:
| Yes, definitely. The salt just means you have to compute
| a few hashes yourself rather than relying on a lookup
| table.
| tracker1 wrote:
| Yes... there are lists that are generally used for common
| variants of passphrases and can generally crack a simple
| passphrase like ggp in less than a day easily, faster or
| slower depending on hardware in use, concurrency and
| order.
|
| 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.
| hsbauauvhabzb wrote:
| It depends on the context, if I have a hash it's trivial
| to crack dictionaryword29, if I'm brute forcing a VPN/RDP
| endpoint, generally fail2ban are hard enough to block
| mass attempts (an AD default, iirc), the latter is
| usually solved by phishing which has the added benefit of
| MFA capture also.
|
| Pentester here, to clear any dubious assumptions.
| csomar wrote:
| It might be a good idea to omit the school's name.
| niels_bom wrote:
| Maybe the school doesn't exist and is in fact a honey pot.
| walleeee wrote:
| The school district certainly exists but that doesn't
| alter the honeypot calculus
| gregmac wrote:
| > 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.
|
| 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.
| withinrafael wrote:
| And NIST. https://pages.nist.gov/800-63-FAQ/#q-b05
| [deleted]
| mattowen_uk wrote:
| And NCSC:
|
| https://www.ncsc.gov.uk/collection/passwords/updating-
| your-a...
| edlebert wrote:
| And my ax!
| rozab wrote:
| >cyber criminals almost always use credentials as soon as they
| compromise them.
|
| 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.
| pc86 wrote:
| If users actually selected new passwords maybe. But they
| don't, they increment the number at the end or change the
| special character.
| Godel_unicode wrote:
| For those who may not know, password cracking/brute-force
| tools have all of this logic and more besides.
|
| 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.
| lostcolony wrote:
| Just have to hope that mypassword03 on the work account is
| not in sync with mypassword03 on the facebook account then.
| And that no one either automatically, or as part of a
| targeted attack, notices the 03 and tries 04 (and etc).
| Spooky23 wrote:
| Nobody remembers real passwords so they come up with
| frameworks to have a pattern that meets policy.
|
| 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.
| iso1631 wrote:
| > 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
| phumberdroz wrote:
| Check this twitter thread out.
|
| https://twitter.com/jmgosney/status/714599256410054657
| Spooky23 wrote:
| Pretty long.
|
| But given a list of common words, it's pretty easy to
| figure out how "Autumn2012!!!" will change with the
| seasons.
| lstamour wrote:
| Neither password is secure once it leaks, though. That's
| the problem when people pick a secure password but then
| use it everywhere. This is why password managers are
| mandatory for secure passwords.
|
| 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...
| hda111 wrote:
| Is there any popular site that allows to only use FIDO2?
| I want to get rid of all passwords but it seems it's not
| possible at the moment.
| lstamour wrote:
| Sign in with Apple, required by Apple for all apps with
| social logins, will only prompt you for a password when
| you don't have Face ID, Touch ID or a PIN set on your
| device, according to https://support.apple.com/en-
| ca/HT211687
|
| 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.
| dlubarov wrote:
| Bitcoin miners are doing around 170 quintillion hashes
| per second, so if all of those resources were put toward
| cracking these passwords, in theory it should take around
| 20 billion years for the longer one [1], or about 38
| milliseconds for the shorter one [2].
|
| [1] https://google.com/search?q=0x5ae2b1ce4999dfd2c8f1a57
| 509650e...
|
| [2] https://google.com/search?q=0x5ae2b1ce4999dfd2+%2F+%2
| 8170+qu...
| gerdesj wrote:
| Well OK but not all passwords are hex numbers! Given that
| testing a few simple classes the length of the shorter
| one takes about a second or two then that seems
| worthwhile.
|
| 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 $PS% 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.
| dlubarov wrote:
| Yeah -- I assumed that a random hex password was chosen,
| and that the attacker does a brute force hex search (e.g.
| JtR with Incremental:Lower). Granted, in practice the
| attacker usually doesn't know the exact format, so they
| might waste additional time searching other formats.
|
| I agree about incorporating other characters. As long as
| it's not "Dictionaryword1!" :)
| https://youtu.be/aHaBH4LqGsI
| TranceMan wrote:
| Is this similar to Enigma decoding - whereby the 'encoding' key
| was reasonably predictable and not random due to new keys being
| required to be generated regularly?
| sn_master wrote:
| This been Google's guidance for even longer time, if not
| forever. I worked at Google for a year and was very surprised
| about that. Before that I had to find ways to memorize the new
| password every 60-90 days.
| pbreit wrote:
| Most password requirements are dumb. Six alphanumeric is OK.
| Sohcahtoa82 wrote:
| Probably the second most wrong comment I've ever read in my 5
| years on HN.
| michaelcampbell wrote:
| ...40 years ago.
| xxpor wrote:
| My understanding is the biggest driver of still having
| mandatory password rotation is PCI (the payments security
| requirements, not the bus)
| mywittyname wrote:
| It wouldn't surprise me if this were a regulation
| requirement, since most very large companies I've worked with
| all have pretty much identical password expiration policies.
| closeparen wrote:
| Regulation is usually pretty light on specific technical
| measures, it says something vague like "you must follow
| best practices" and then there's industry consensus /
| rumors about what those are.
| xxpor wrote:
| That's really dependent on what regulation you're talking
| about. The FCC has some extremely specific rules in Part
| 15, for example.
| PeterisP wrote:
| Change travels very slowly - some years ago NIST and
| everybody else's recommendations used to require password
| rotation, so lots of policies and habits of policy
| writers/enforcers and educational materials still echo the
| old recommendations.
| xxpor wrote:
| PCI is, practically speaking, nearly the same as an actual
| regulation, given how stringent and widespread it is.
| jrodthree24 wrote:
| This requirement can come from lots of places. I remember
| at the last place I worked, we had to get audited for SOC2
| compliance and password expiry was part of the requirement.
| I imagine these things lag behind the recommended security
| guidelines by quite a few years.
| xmprt wrote:
| It feels extremely negligent of third party auditors to
| recommend (and sometimes require) companies to enforce
| worse, obsolete security practice.
| underwater wrote:
| SOC 2 is defined by the American Institute of Certified
| Public Accountants. Having computer security defined by
| accountants seems crazy, but is in the style of the
| bureaucratic mess of modern enterprise.
| mumblemumble wrote:
| I've also seen it written into business contracts with
| clients. Which makes it almost impossible to change,
| because doing so would require both sides to agree to pay
| for an expensive (and irksome) exchange between their
| respective legal teams.
| sd6594 wrote:
| Rumors has that the next PCI-DSS revision will change that
| requirement.
| jrnichols wrote:
| I have the feeling that HIPAA requirements are also another
| driver.
| quesera wrote:
| That's correct. PCI DSS section 8.2.4(a) requires that
| passwords are changed at least every 90 days.
|
| 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.
| pbreit wrote:
| That only applies to Level 1 and/or SAQ D merchants (who
| are storing card numbers) which the vast majority are not.
| quesera wrote:
| This is true. As John (Cougar) Mellencamp sang: "Hold on
| to SAQ A / As long as you can ..." :)
| inter_netuser wrote:
| wouldn't MFA/OTP be sufficient to compensate?
| quesera wrote:
| PCI DSS section 8.3 requires MFA explicitly.
|
| 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!
| AmericanChopper wrote:
| I've had a number of Level 1 merchants/service providers
| ditch PCI password complexity/rotation rules, and I've
| always managed to get it accepted by QSAs.
|
| 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.
| whatsmyusername wrote:
| This is why when I built our systems, I did most of them
| using a combination of public/private keys and TOTP 2fa.
| Also severely isolating those systems so that the list of
| people who need access is as small as possible.
|
| It's orders of magnitude less of a pain in the ass than
| password cycling.
| briffle wrote:
| Yep, Its very secure, because nobody would use:
| P@ssw0rd! P@ssw0rd!2 P@ssw0rd!3
| P@ssw0rd!4 P@ssw0rd!5
| 001spartan wrote:
| That's why those of us in the security industry have to
| say "compliance is not security" whenever PCI is brought
| up.
| xtracto wrote:
| PCI is just so asinine it made me want to poke my
| eyeballs out when I had to go through it (Level 1 Service
| provider). In some situations it actually prevents you
| from being more secure.
|
| One of the reasons why I want the Credit card cartels to
| die.
| merb wrote:
| well I've known more clever users, guess what you need to
| do if your password needs to change every 90 days, but
| you need to have a different password for at least 5
| cycles?
|
| 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!
| corobo wrote:
| This is how I used to do it. Just slap the year and Q on
| the end whenever it wanted me to change it. End of the
| quarter gets a bit tricky if things don't line up but
| it's mostly muscle memory by then
|
| Sup3rdup3rp4ss2021Q2
| jagger27 wrote:
| I once used a system that stored old passwords as
| plaintext and searched for substring repetitions.
| Horrible.
| rovr138 wrote:
| Microsoft has that.
|
| Not 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...
| ben0x539 wrote:
| If you encrypt the prior passwords using a key derived
| from the current password, you're enabling this sort of
| check on password change without really sacrificing
| security, don't you?
| dr-detroit wrote:
| I am forced by management goons to give human resources
| database password in plaintext to indian/chinese
| developers who cannot grok typing a password but their
| job is sweet and better than mine but whites cant do
| database work dont be silly. Dont worry hr data isnt
| institutional only the poor suckers who work here are at
| risk.
| jnwatson wrote:
| The excellent (or horrible, depending on which end you're
| on) pam_pwquality[1] module for Linux allows rather fine-
| grained enforcement of how much a new password must
| differ from the old password.
|
| 1. https://www.systutorials.com/docs/linux/man/8-pam_pwqu
| ality/
| AdamJacobMuller wrote:
| > You might be able to justify non-compliance with a
| compensating control, but I've never heard of anyone who
| tried it.
|
| 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.
| smallnamespace wrote:
| Would you consider sharing it? Might be useful for others
| in the same boat.
| sadness3 wrote:
| Can you please pop this list of articles into pastebin
| and paste it here? tyvm
| technion wrote:
| This hasn't been updated in a while but there's plenty of
| references:
|
| https://gist.github.com/technion/65c652194fb1427e6828ea23
| ff4...
| thrwyoilarticle wrote:
| >Furthermore, you must retain old passwords to disallow
| dupes for at least 5 cycles.
|
| More cynically: password reuse is allowed after 5 cycles.
| jlund-molfese wrote:
| I've actually known people who, when required to change
| their password, would change it 5 times in a row, then
| back to the original password in order to keep using it.
| jamesvnz wrote:
| This is why many systems - I've seen it with Microsoft
| and Salesforce - set a "minimum password age". Which is
| usually a minimum of 1 day.
|
| 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.
| andersonvom wrote:
| This is amazing: "guaranteed at least 24h of exploiting a
| recently compromised account or your money back"
| liversage wrote:
| Yeah, I've tried that. First day in my new job. "Here's
| your PC. Your user name is [some initials] and your
| password is abcd1234". I sign in and immediately proceed
| to change my password to something that doesn't suck. I
| keep getting an error message about my new password not
| meeting the complexity requirements. Super confusing... I
| give up.
|
| 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.
| ornornor wrote:
| Oh this is clever, I'll use that next password rotation
| so that my password doesn't change in effect. We must
| change every 60 days where iWork, and it doesn't work
| well so some systems still use the previous password,
| some still use 3 passwords ago, etc. It's random though,
| you never know in which systems the password change will
| take and in which it won't)
| awruko wrote:
| It is internal joke, you 'forgot' your password, so you
| get something like 'Spring2021' from IT as password
| reset. Now you pick a target account, trigger account
| lockout. Most of the time, the target is confused and
| gets a combo, account unlock and password reset. Now the
| IT guy who does password reset ... uses seasonal
| passwords which of course can't be changed for 24 hours.
| Corrado wrote:
| Back in the day, I changed my password 13 times every
| month in order to reuse the same one again. Super secure!
| TeMPOraL wrote:
| Slightly more tech-savvy users will just use a password
| manager... called "passwords.txt" file saved on the
| desktop.
|
| 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).
| NaturalPhallacy wrote:
| Guilty as charged.
|
| It's why mandatory change policies are so stupid. Users
| will always sacrifice security for convenience.
|
| Even those that know better.
| ljm wrote:
| I've worked at places that would disallow re-use for the
| last 30 passwords. When you're forced to change every 3
| months you're looking at a company maintaining a password
| history for over 7 years.
|
| 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.
| drzaiusapelord wrote:
| I believe Active Directory just stores the hash like it
| does for your current password. Yep, if you crack the
| domain controller or grab a copy of the backups and get
| those hashes then all the bets are off. You also get
| their current passwords because they're there as well, so
| its not like having the old ones makes anything worse.
| And of course, if you do have admin privs on the domain
| controller, you can do a lot better and easier things
| than bothering with those hashes anyway.
|
| 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.
| gdw2 wrote:
| this.
|
| I wonder if Microsoft employees (all or portions) have to
| rotate their passwords due to PCI compliance despite
| Microsoft's stance on the subject.
| hirsin wrote:
| Not any more, as of a year or two ago? We finally updated
| our internal structure to follow the NIST guidelines we
| helped write.
| slver wrote:
| Isn't it weird when all of us individually knew forced password
| change is more harm than benefit, but it took literally decades
| for this to become institutionally admitted?
|
| Just imagine, maybe a subset of neurons inside your brains have
| amazing ideas that could change your life, but it might take
| decades (or never) for them to surface to the conscious level
| where you realize "oh, I have an idea".
|
| How to make sure organizations are not less than the sum of their
| parts?
| sneak wrote:
| > _Isn 't it weird when all of us individually knew forced
| password change is more harm than benefit, but it took
| literally decades for this to become institutionally admitted?_
|
| The US bank I recently opened an account with (in 2021) is in
| the S&P 500, publicly traded. The only form of 2FA they support
| is SMS or some proprietary hardware keychain LCD thing they
| don't give out for free (which I assume is the M+A great
| grandchild of those RSA TOTP fobs that were the fad in the
| 90s).
|
| It's not weird. Most security organizations are wholly
| incompetent, doing cargo cult security nonsense "because that's
| the way we've always done it".
| wil421 wrote:
| The company I work for is one of the large(est) "FinTech"
| conglomerates. After talking to a lot of our security folks they
| agree about not changing passwords but are unable due to PCI and
| Federal standards/audits.
|
| We have to adhere to outdated security practices simply because
| the auditors will flip out and the documented controls in
| government mandates. Section "10.12.3.4" says you must rotate
| passwords.
| topkeks wrote:
| NIST recommends NOT to rotate passwords.
|
| https://pages.nist.gov/800-63-FAQ/#q-b05
| a-dub wrote:
| > Researchers have increasingly come to the consensus that the
| best passwords are at least 11 characters long, randomly
| generated, and made up of upper- and lower-case letters, symbols
| (such as a %, *, or >), and numbers. Those traits make them
| especially hard for most people to remember.
|
| in other words, the only good password is a randomly generated
| bitstring (just like a key!) represented as some weird almost but
| not quite total subset of 8-bit ascii that was based around some
| weak and wild assumptions that human generated text is not
| guessable.
|
| this is getting out of hand.
| simonjgreen wrote:
| One of the things I used to hear cited "back in the day" was that
| things like the SAM file from a DC took about a month to crack so
| you should rotate passwords on a frequency that beats that race.
| But it's always struck me as an awful lot of burden to put on to
| your users for a rather low likelihood attack surface. These days
| though it makes even less sense.
| asplake wrote:
| And still they won't let me reuse an old one
| 1cvmask wrote:
| The ideal solution is passwordless multi factor authentication.
| You have to the power of randomly generated numbers coupled with
| extreme usabilty. We do that by scanning an encrypted barcode to
| login with mfa running in the background. We also can do that
| with a push login approval, or webauthn or FIDO U2F physical
| keys.
|
| Disclaimer: worked on the design of the passwordless mfa solution
| set at saas pass.
| cabaalis wrote:
| Can you describe the meaning of passwordless multi factor? What
| replaces the "something you know" in this case?
| josephcsible wrote:
| How are those multi factor? Aren't they all just the single
| factor of "something you have" if they're passwordless?
| bkandel wrote:
| > Bucking a major trend, company speaks out against the age-old
| practice.
|
| Next sentence:
|
| > Microsoft is finally catching on to a maxim that security
| experts have almost universally accepted for years
|
| So ... they're not bucking a major trend?
| artful-hacker wrote:
| The guy who first recommended rotation "has since come out and
| apologized about the first iteration of the NIST guidelines"[1]
|
| Password rotation has always been a bad idea.
|
| https://labs.bishopfox.com/industry-blog/2018/08/password-se...
| user3939382 wrote:
| To clarify, he was apologizing for everything in those obsolete
| guidelines including the complexity requirements. Apparently
| DHS didn't get the memo:
| https://studyinthestates.dhs.gov/sevis-help-hub/sevis-basics...
___________________________________________________________________
(page generated 2021-04-19 23:00 UTC)