[HN Gopher] The new White House memo on zero trust is a strong s...
___________________________________________________________________
The new White House memo on zero trust is a strong signal
Author : CKMo
Score : 145 points
Date : 2022-03-02 18:10 UTC (4 hours ago)
(HTM) web link (www.pomerium.com)
(TXT) w3m dump (www.pomerium.com)
| visviva wrote:
| Previous HN discussion on this memo:
| https://news.ycombinator.com/item?id=30101411
| dang wrote:
| Thanks! Macroexpanded:
|
| _I read the federal government's Zero-Trust Memo so you don't
| have to_ - https://news.ycombinator.com/item?id=30101411 - Jan
| 2022 (352 comments)
| righttoolforjob wrote:
| They're also (intentionally?) misrepresenting the memo.
|
| > MFA should be integrated at the application layer, such as
| through an enterprise identity service as described above, rather
| than through network authentication (e.g., a virtual private
| network).
|
| They comment with:
|
| > While it's no surprise seeing multi-factor authentication being
| a requirement, what stands out is that doing so at the network
| level is explicitly disallowed. Meaning all VPNs and tunnels -
| nextGen or not - do not meet the standard.
|
| Which of course is completely untrue. You still want VPNs to
| connect sites or even client/network and any security expert
| worth their salt will surely recommend you to have layered
| security. Opening up your internal network to the internet and
| rely on every app to do security correctly is a ridiculously bad
| strategy.
|
| I don't know or care who pomerium is or what they sell, but this
| sort of anti-advice severely diminishes their trustworthiness.
| noasaservice wrote:
| > Which of course is completely untrue. You still want VPNs to
| connect sites or even client/network and any security expert
| worth their salt will surely recommend you to have layered
| security. Opening up your internal network to the internet and
| rely on every app to do security correctly is a ridiculously
| bad strategy.
|
| Having done FedRAMP and also running Tor servers, I'm also at
| the conclusion that using IP in any sort of rules is a bad
| practice. You should be
| identifying/verifying/authorizing/logging the connection
| regardless how it came to you. Consistently doing that means
| you now can control user access at a chokepoint (usually an IdP
| or similar token passing credentialled login).
|
| If you have a malicious entry, you do not want lateral transfer
| to end up hitting less secure stuff on the network because of
| implicit network trust. Zero-Trust is about removing those
| implicit things. And if everything has service-level IdP token
| checks, not even replay attacks will work. As a malicious
| hacker, you're stuck there. Less scope of damage.
|
| Same with Tor. For anyone running a Tor client or operating a
| Onionserver, all connections are actually an IPv6 overlay with
| routers that only support TCP (not UDP/ICMP). And since those
| absolutely will be randomized every 10m on average, you
| absolutely must verify the connection AND NOT the
| source/destination.
| cdoxsey wrote:
| First of all its not a misrepresentation of the memo. The memo
| states:
|
| > Users should log into applications, rather than networks, and
| enterprise applications should eventually be able to be used
| over the public internet.
|
| Second with regards to this statement:
|
| > Opening up your internal network to the internet and rely on
| every app to do security correctly is a ridiculously bad
| strategy.
|
| That's precisely what zero trust networking is. Ala Google's
| BeyondCorp:
|
| > Virtually every company today uses firewalls to enforce
| perimeter security. However, this security model is problematic
| because, when that perimeter is breached, an attacker has
| relatively easy access to a company's privileged intranet. As
| companies adopt mobile and cloud technologies, the perimeter is
| becoming increasingly difficult to enforce. Google is taking a
| different approach to network security. We are removing the
| requirement for a privileged intranet and moving our corporate
| applications to the Internet.
|
| (https://storage.googleapis.com/pub-tools-public-
| publication-...)
|
| Maybe they're wrong about all this, but it's not anti-advice.
| It's a legitimate security model being pursued by many
| different companies.
| righttoolforjob wrote:
| Zero trust is about not trusting anything, which means
| neither external nor internal network. Not trusting the
| internal network does not mean that you should open it up to
| everyone. You have misunderstood this gravely.
|
| Google doesn't do what you suggest and I'll throw in another
| large security-aware company as well, known for their
| privacy-conscious phones. They protect the perimeter as well
| as the inside. As does any military organization. Stop
| spreading misinformation.
| onefuncman wrote:
| You're missing the point. There is no internal network in
| this new model.
| tptacek wrote:
| Even the BeyondCorp paper doesn't fully buy into this idea.
| If you're on a coffee shop's wi-fi network, you'll talk
| directly to Google's Access Proxy. But if you're in the
| building, you're 802.1x authenticating to their network
| before getting access.
|
| The problem with VPNs is that enterprises have used them for
| decades as a crutch, extending their perimeter model out so
| that instead of a small SPOF, they have a gigantic, ever-
| changing SPOF. "ZTN-think" pushes this basic idea way past
| usefulness, to the point where all network controls are
| somehow suspicious. Which is crazy; BeyondCorp fundamentally
| relies on network access controls as well as application
| access controls, like every other modern network design.
| They're just different controls.
| WalterBright wrote:
| "The foundational tenet of the Zero Trust Model is that no actor,
| system, network, or service operating outside or within the
| security perimeter is trusted"
|
| It's about time. That's how airliners are designed. The guiding
| principle is "no single failure will bring the airplane down."
|
| What it is _not_ is "guarantee critical components will not
| fail".
|
| The airline design principle is applicable to all kinds of
| things, like electrical grid design, security design, nuclear
| plant design, oil drilling platform design, ship design, and on
| and on. But I see it rarely applied, which is frustrating.
| tptacek wrote:
| It's a good sound bite, but it's not really true. Nobody
| designs their IT infrastructure so that nothing is trusted; in
| fact, universally, IT security teams talk about their "source
| of truth" (usually: their _single_ "source of truth") for
| things like authentication.
|
| What ZTN is mostly about is changing the SPOF we had before ---
| the network perimeter --- to something fuzzier and more
| flexible. It's a good plan; we've been talking for over 20
| years, going back to the Jericho Forum, about
| "deperimeterization" and "segmentation", and segmentation
| hasn't really worked out.
|
| But it'd be a mistake to look at all of this stuff and think
| that it's a shift away from single points of failure, or to
| fundamentally greater resilience. We're opting for better
| SPOFs, not the elimination of SPOFs.
| distortedsignal wrote:
| I kind of want to challenge this "better SPOFs" idea. From
| what I understand of the ZTN concept, the SPOF is the factory
| line. If an adversary can compromise what's on the board,
| it's really hard to prevent that adversary from controlling
| what happens on that machine.
|
| I have had people tell me in meetings at work that they have
| pictures of people swapping out parts on an assembly line for
| unknown parts. If that's happening, unless the machines are
| verified by XRay, from my point of view, the ZT concept isn't
| worth a whole lot.
| tptacek wrote:
| A pitfall of all these ZTN discussions is that they tend to
| propose a definition of "zero trust" as an axiom, and then
| use deduction to construct a whole system from those first
| principles. This is especially useful for security product
| vendors, who will pick the most congenial definition of
| "zero trust" in order to derive a mandate for their
| products.
|
| We don't so much have to get lost in abstractions here.
| There's a blueprint: all this ZTN stuff was inspired by
| Google's BeyondCorp paper (ZTN is the marketing-neutral
| name for BeyondCorp; the Kubernetes to BC's Borg). So: just
| go read the BeyondTrust paper; it's great:
|
| https://storage.googleapis.com/pub-tools-public-
| publication-...
| distortedsignal wrote:
| Thanks - my company is pushing a lot of ZTN stuff, and I
| wasn't totally sure where the principles are coming from.
| Having a root that I can anchor my debates in (which, as
| you can probably tell, is currently lacking) should be
| really helpful.
| WalterBright wrote:
| The idea is not to guarantee the board is not compromised,
| because, as you stated, such is impossible.
|
| The idea is _assume the board is compromised_. Now what?
|
| Answering that question is the key to robustness.
| distortedsignal wrote:
| Is there a "now what?" if the board is compromised? I
| have... difficulty... understanding what you could
| possibly do to prevent full distributed system compromise
| if one hardware node is compromised. You seem very
| certain that something can be done, and I trust you, so I
| can trust that something can be done, but perhaps the
| solutions in this space elude me. I'll keep watching this
| space, but my pessimism may leak through from time to
| time.
| WalterBright wrote:
| I can't answer it in detail because I don't know how
| those systems work. But if I did, I bet I could find a
| way. After all, it's clear to me how Fukushima and Deep
| Water Horizon both had an easily fixed single point of
| failure that doomed them, and I ain't no expert on
| nuclear reactors nor drilling rigs.
|
| When I got a job at Boeing, I thought it was impossible
| to design an airplane with full redundancy. They showed
| me how it was done.
| pinephoneguy wrote:
| How do you do shared secret authentication in this model? I
| know cert based auth is far better but today many apps rely on
| some kind of shared secret auth. Don't you by definition trust
| eg LDAP/IPA servers then?
|
| EDIT: In case it's not clear: I'm talking about employee facing
| software inside an organization where you might have some kind
| of single sign on system or a distributed account system (like
| IPA or LDAP.)
| noasaservice wrote:
| Use SAML.
|
| The SP never sees the credentials. The SP only sees a token
| which includes the username (NameID) and other attributes
| passed from the IdP through the client.
|
| https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang.
| ..
|
| (Scroll down to the "Single sign-on using SAML in a Web
| browser" image for a good data flow depiction)
|
| Basically this seems to be a "SAML-IZE EVERYTHING".
| distortedsignal wrote:
| But with SAML you're trusting the cert/key pair on the
| signing end of the connection. If you say "well, we can use
| the cert provided by the server by getting it over HTTPS
| every time we need to auth with SAML," then you're trusting
| the Root CA Cert/Key pair for the TLS connection that
| underlies the HTTPS protocol. (Source: I've written two
| SAML SPs.)
|
| With ZT, you basically have to bootstrap trust from the
| factory. I don't think of ZT as "don't trust anything" -
| it's more like "trust our supply lines".
|
| Think about the failure modes of ZT: if the NIC, the CPU,
| the OS, and the bootloader are deemed secure at boot time,
| there has to be something that starts the bootloader and
| loads its keys. If you compromise _that_ piece, then you
| can compromise anything further up the stack and not worry
| too much about security alerts. The only way to make sure
| that all machines are secure/uncompromised is to XRay all
| of the bootloader chips and verify them down to the ~100um
| level (got this figure by talking to a guy doing grad work
| @UofM when he was in SV around 2017-2018, I want to say).
| daveevad wrote:
| I don't know but have wondered about this sort of thing
| before.
|
| There is a Wikipedia article on 'Key ceremony'[0] that seems
| to indicate an in-real-life shared secret creation and or
| sharing event.
|
| (https://en.wikipedia.org/wiki/Key_ceremony)[0]
| WalterBright wrote:
| One method is "assume your system is penetrated, so do not
| put all your secrets on one system."
|
| For example, don't use the same password on your Etrade
| account that you use on your bank account.
| WalterBright wrote:
| Another way to look at it is to not ask the question:
|
| *Can* this fail?
|
| but instead ask:
|
| *When* this fails, can it be survived?
| distortedsignal wrote:
| With all due respect to the esteemed gentleman, I think
| sometimes an equally important question is " _When_ this
| fails, _should_ it be survived? " There may be some
| operations that _shouldn't_ be worked around. For example, if
| my auth service goes down, should accesses continue, or
| should we prevent all accesses?
|
| I don't think I'm communicating myself clearly here, but I
| would like to thank the parent commenter for his insight into
| this area and more. Just to cover my bases.
|
| EDIT: I want to make clear that there is no sarcasm here. I
| respect WalterBright probably only behind Knuth in terms of
| effective programmers/engineers in the field today, and I
| doubt I could add anything to his opinions.
| WalterBright wrote:
| If the auth service has failed, the correct response is to
| shut down all access to what that service was connected to.
|
| In order to survive shutting down that access, the system
| must be compartmentalized, so the shutdown is limited in
| scope.
|
| For example, the hydraulic system on an airplane has a
| redundant equivalent hydraulic system. But within a
| hydraulic system, it is designed to isolate failed sections
| of it from the rest, so the rest can still function. I.e.
| developing a leak in the elevator actuators won't disable
| the aileron actuators on the wings.
|
| The Fukushima plant and Deepwater Horizon rig both had a
| vulnerability to a single point of failure that produced
| cascading failures that unzipped the whole system. Both
| were easily and inexpensively preventable.
| WalterBright wrote:
| A related principle is compartmentalization. For example, if
| your system is penetrated, it doesn't give access to all the
| information. There should never be "X was penetrated, 100
| million records were stolen." It should be X only has access to
| 1 million records, and penetrating X should not compromise X2,
| X3, X4, etc.
| WalterBright wrote:
| Just on the last "60 Minutes" there was an episode about how a
| handful of substation failures would bring down the entire
| grid.
|
| Yet another example of the concepts of airliner design being
| completely unknown outside of the aviation industry.
|
| The "grid" doesn't appear to be a grid at all, but a tree. An
| actual _grid_ would be able to route around failures, much like
| the internet protocol can do.
| nwallin wrote:
| The power grid is in fact a graph, not a tree, and not a
| grid. It _is_ automatically able to route around failures,
| and it does route around the failures. These failures happen
| every day, but people almost never notice. Almost.
|
| The trouble is that the power grid just operates on the
| electrical principle of electricity following the path of
| least resistance. So if there's low resistance but low
| capacity line between generation and usage, the electricity
| will flow through it, and there is no QoS on the line that
| can limit how much power goes through it, besides on/off.
|
| The on/off nature of the interconnections is what makes the
| power grid fragile. If a interconnection has a rating of
| 100MW or whatever, and the grid attempts to pump 110MW
| through it, you either leave it on and hope it doesn't break
| or shut it off and pump 0MW. The grid will then automatically
| route that 110MW through other interconnects. If there is a
| nearby 500MW interconnect that is currently pumping 350MW,
| you're fine, but if it's pumping 475MW, you're probably not.
| This can lead to cascading failures.
|
| The grid does have the ability to shut down _usage_ if there
| 's a danger of a cascading failure. For instance, if your
| 100MW rated interconnect has 101MW coursing through it, you
| can shut down a neighborhood that's using 10MW or whatever,
| and keep the 100MW interconnect online with just 91MW running
| through it. This is what brownouts and rolling blackouts are.
|
| The grid can have major failures, but these major failures
| don't happen unless there are multiple overlapping minor
| failures. Similarly, if your 737 MAX has 2 MCAS sensors and 1
| manual MCAS override button, and both your sensors and your
| manual override all fail, you're going to have a bad time.
| Look at the sequence of events of the 2003 Northeast
| blackout: https://en.wikipedia.org/wiki/Northeast_blackout_of
| _2003#Seq... There are at least half a dozen failures between
| the initial problem at 12:15pm and until the point of no
| return failure at 4:05pm that if handled properly would have
| averted the crisis and turned it into a minor inconvenience.
| At least half a dozen instances of human error plus multiple
| instances of equipment failures. If an aircraft had that many
| things go wrong all at once, the plane's going down.
|
| Note that the Texas power outage last year wasn't like this
| at all. The grid actually kept working fine, the problem is
| that there were lots of generators that failed as a result of
| the cold, mostly due to impure natural gas freezing. The
| generation capacity of the grid was cut to a fraction of its
| capacity, and as a result, they shut down a bunch of cities
| to reduce load. For whatever reason, they just left power off
| in several cities for days instead of doing rolling
| blackouts. I don't know enough about the circumstances to
| speculate on what the reason for that is.
| thrashh wrote:
| The grid actually does route around failures.
|
| Load is simply distributed among the working parts of the
| grid.
|
| However the issue is that the grid doesn't cut off a part of
| itself for the sake of survival.
|
| I think the issue is: at some point you have to shed off some
| of your customers and choose the ones that still get power.
|
| Who makes that call? Where do you even draw the lines? And
| how do you do this quickly in a few minutes?
| tomohawk wrote:
| I just have to shake my head at this stuff.
|
| They still haven't fixed _this_ after decades of effort:
|
| https://www.washingtonpost.com/sf/national/2014/03/22/sinkho...
|
| It would be great if they could do something to prevent things
| like the OPM data breach, but check out this questioning of the
| principles involved in that debacle:
|
| https://www.youtube.com/watch?v=AK-zEGjxuAA
|
| Does this give anyone any hope that there is competence to deal
| with this?
|
| I know someone is going to say, "but we have to start somewhere".
| Sure. But, keep in mind there doesn't appear to be any pilot
| program where they've proven they can do this in even a single
| place. And now they're creating a blanket executive order to _do
| something_ across the whole federal government?
| opportune wrote:
| This has restored my faith in the government wrt technology. I am
| sure there are some very passionate and smart people behind this
| initiative who are motivated by doing things right rather than
| intellectual laziness.
|
| I'm convinced that the "defense in depth" and "security
| permitter" models were pretty much entirely driven by laziness
| (define a perimeter and call it a day) and pork (defense in
| depth= we can pay for tons of different disjoint security
| software/vendors/contracting because it adds depth). Zero trust
| actually requires you to do the right thing and do it everywhere,
| and hopefully reduces the amount of waste thrown at vendors. It
| will create a lot of integration work but will hopefully
| consolidate the actual security software used.
| MadVikingGod wrote:
| Does this mean that the decades of training on "Defense in Depth"
| is going to have to be rewritten and all the certs reacquired?
| bombcar wrote:
| Which answer makes more money flow around?
|
| That's the one!
| treatmentteam wrote:
| I like that they're setting such a high bar, despite the
| potential difficulties of achieving that broadly. One question I
| have: I've yet to encounter an entity (including login.gov) that
| allows FIDO2/WebAuthn without also requiring a HOTP/TOTP or other
| 2nd-factor. So what's the point of allowing the security key
| option if an attacker has the option to attack the authentication
| code (which is often sent via SMS)?
| acdha wrote:
| login.gov does allow you to have FIDO2 setup without a phone
| number -- my account currently only has hardware tokens -- but
| I think you want to look backwards from the challenges of
| supporting a service like this. If you're serving the general
| public, people reliably lose their tokens and you can't require
| them in general since multiple $20 tokens is a complete non-
| starter so there's a lot of appeal to things like SMS which
| don't require additional purchases.
|
| The other question I'd ask is how bad SMS really is: it's
| definitely not great from a security perspective but for the
| average person it seems unlikely that they're worse off from
| having it. Maybe we can start phasing that out now that common
| clients have integrated WebAuthn support (e.g. Apple's
| FaceID/TouchID for the web) but if you have to support the
| general public you probably have a different threat model than
| a more targeted audience.
| MadVikingGod wrote:
| I'm not sure about the public facing entities, but the Federal
| Government already has a VERY widespread PKI system in place
| that I'm sure they will leverage. Most federal departments
| already have a process for distributing a smartcard with a
| Federally signed key to all their employees and some
| contractors. I'm hoping that they can extend that to non-
| employees.
| toomuchtodo wrote:
| If DHS would issue Global Entry smart cards that were part of
| the CAC platform [1], that would be a convenient shim until
| national ID cards could be deployed. I picked up a TWIC card
| [2] thinking I'd be able to use it with Login.gov, but no
| such luck.
|
| [1] https://www.cac.mil/common-access-card/
|
| [2] https://www.tsa.gov/for-industry/twic
| toomuchtodo wrote:
| Login.gov has to serve a diverse customer base made up of every
| American resident/citizen, therefore its threat model and
| approach to securing identity is different than that of
| someone, say, storing cryptocurrency (where the risk of loss
| and lack of recourse is much higher than someone seeing your
| Social Security benefit statement).
|
| Consider an older citizen losing their hardware token, and
| unable to login to their Social Security or IRS account. The
| current model is to be expected until the government builds out
| its identity functions. Security is about trade offs and
| compromise.
|
| (no affiliation with login.gov or related federal agencies,
| just a fan of their work)
| brightball wrote:
| I haven't found a bank that will allow FIDO2 yet.
| tptacek wrote:
| This memo is driving me nuts. It's not that the memo is bad; it's
| very competent, and while there are things in it I disagree with,
| it's far better than anything else the USG has published, and its
| authors should be happy.
|
| No, my problem is that every goddam security product company in
| the world is treating it like the white paper for their product,
| and so, if you pay attention to security stuff, you're besieged
| with takes about how this memo is going to change everything,
| hmmm, just coincidentally, in such a way that makes our product
| vital to the continued working of every company connected to the
| Internet.
|
| God help us if the federal government ever publishes a memo about
| geographically distributing app workloads. You thought I was a
| nightmare now.
|
| "[M]any overlook device identity but it's one of the most
| important context sources". Yeesh.
| PTOB wrote:
| This observation makes me laugh ... so that I don't cry.
| oldstrangers wrote:
| Welcome to the wonderful world of inbound marketing.
| bduerst wrote:
| Yeah first party whitepapers are nothing, wait until you get
| sucked into content syndication networks that sell peoples'
| contact details.
| VikingCoder wrote:
| It's almost like mixing business with national security is
| likely to produce bad outcomes.
| staticassertion wrote:
| Security vendors gonna security vendor.
| zmmmmm wrote:
| would be fine except this is how we end up with mandatory
| invasive anti-virus forced onto all our laptops causing all
| kinds of problems and (yes!) security issues, 15 years after
| it was a good idea.
| tptacek wrote:
| Stuff like this always makes me think of the Mr. Show sketch
| "Coupon, The Movie". "The FBI calls it warm... and
| mandatory!"
| Smoosh wrote:
| If only the emphasis was on the security not on the
| vendoring.
| IncRnd wrote:
| > God help us if the federal government ever publishes a memo
| about geographically distributing app workloads. You thought I
| was a nightmare now.
|
| Well... Sort of? The Industrial Internet of
| Things (IIoT) refers to the application of
| instrumentation and connected sensors and other devices to
| machinery and vehicles in the transport, energy, and
| other critical infrastructure sectors. In the energy
| sector, distributed energy resources (DERs) such as solar
| photovoltaics including sensors, data transfer and
| communications systems, instruments, and other
| commercially available devices that are networked
| together. DERs introduce information exchanges between a
| utility's distribution control system and the DERs to
| manage the flow of energy in the distribution grid.
| This practice guide explores how information exchanges among
| commercial- and utility-scale DERs and electric
| distribution grid operations can be monitored and
| protected from certain cybersecurity threats and
| vulnerabilities. The NCCoE built a reference
| architecture using commercially available products to
| show organizations how several cybersecurity capabilities,
| including communications and data integrity, malware
| detection, network monitoring, authentication and access
| control, and cloud-based analysis and visualization can
| be applied to protect distributed end points and reduce the
| IIoT attack surface for DERs. [1]
|
| Or, you might have meant this, Building Secure Microservices-
| based Applications Using Service-Mesh Architecture [2]
|
| At least #2 is in draft and not finalized.
|
| [1] https://csrc.nist.gov/publications/detail/sp/1800-32/final
|
| [2] https://csrc.nist.gov/publications/detail/sp/800-204c/draft
| xwdv wrote:
| Security has it rough as it is. Low budgets, people not really
| giving a shit, poor understanding of value prop. They need all
| the help they can get.
| sergiotapia wrote:
| Nobody gives a shit about security. Companies wouldn't get
| SOC2 certification if it wasn't required to land B2B deals.
| It's an expense, not an investment in the eyes of most
| leadership.
| Rygian wrote:
| "Security [...] required to land B2B deals" is what I read.
| bob1029 wrote:
| We have to do all of the compliance games because of our
| B2B partnerships.
|
| In my view, SOC2 is equivalent to apple forcing PKI on
| app developers for ad-hoc testing. Ultimately a bunch of
| complex bullshit boilerplate that some adversarial actor
| could trivially usurp if they were inclined to do so.
| Lying to an auditor or due diligence process is not hard.
|
| Real security comes from practical experience and
| procedures, not bullshit busywork proposed by someone who
| has no clue how your business operates.
| tedunangst wrote:
| Pretty sure if most organizations doubled their security
| budget, it would end up being spent on checklist crap. All
| employees would have voice, thumb, and face checks to login
| in to their laptop, but their AWS bucket will remain wide
| open.
|
| I guess the context here is zero trust, so s/laptop/HR
| vacation request site/.
| noasaservice wrote:
| I'll believe it when I see it.
|
| I'm still waiting for feds to implement the guidance from
| https://pages.nist.gov/800-63-3/sp800-63-3.html from 2017 and
| 2020 about NOT rotating passwords arbitrarily, and NOT requiring
| undue amount of special symbols.
|
| Even when I've asked IT, I get crickets and more bullshit
| password rotation.
| earleybird wrote:
| Microsoft followed on with that NIST recommendation and
| suggested discontinuing regular password changes in 2019 [0].
|
| Where I work (MS infra & service) 90 password changes show no
| sign of going away.
|
| A pretty convincing argument that the folks involved are more
| into theatre than practice.
|
| [0] https://news.ycombinator.com/item?id=26863907
| bombcar wrote:
| For a long while you couldn't disable password rotation on
| Office 365 - you could only set it to some arbitrarily long
| time (and only via Powershell, if I recall correctly).
|
| Luckily that is starting to back off, but it has NOT trickled
| down everywhere by a long shot.
___________________________________________________________________
(page generated 2022-03-02 23:01 UTC)