Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I read the federal government’s Zero-Trust Memo so you don’t have to

bastionzero.com

Post reply on HN
Print view View original

71–80 of 369 posts

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#71

Post by zajio1am »

adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

Here in Czechia we have BankID and it is problematic:

1) No verification that the user trusts that particular bank to perform this service. Most banks just deployed BankID for all their customers.

2) No verification between bank and government ensuring that particular person can be represented by particular bank. In principle a bank could inpersonate a person even if that person have no legal relation with that bank.

3) Bank authentication is generally bad. Either login+SMS, or proprietary smartphone applications. No FIDO U2F or any token based systems.

Fortunately, there are also alternatives for identification to government services:

1) Government ID card with smartcard chip. But not everyone has a new version of ID card (old version does not have chip). It also requires separate hardware (smartcard reader) and some software middleware.

2) MojeID service (mojeid.cz) that uses FIDO U2F token.

Disclaimer: working for CZ.NIC org that also offers MojeID service.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#72

Post by PufPufPuf »

jollybean wrote: post #60

They should have given out free identify FOBs with vaccines. I'm only half joking. It's really just a matter of changing gears - you carry a physical key to your house, car, and your online life. You lose the key, you have to go through a bit of pain to get a new one. But establishing that norm is beyond the purview of anyone it seems. Perhaps one of those advanced Nordic countries will have the wherewithal, it seems…

The .cz domain managing company, CZ.NIC, actually gave away free GoTrust keys to people who promised to use them for e-government services.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#73

Post by Godel_unicode »

paganel wrote: post #24

> Do not give long-lived credentials to your users. This screams "we'll use more post-it notes for our passwords compared to before", or maybe the real world to which this memo is addressed is different compared to the real (work-related) world I know.

This was a very unfortunate choice of words by the author, as they don't mean credentials as in the credential a user uses to initially authenticate to the system. Rather they mean authentication tokens, be they Kerberos tickets, bearer tokens, etc.

This memo in particular emphasizes the existing guidance the US government has issued around not expiring passwords. If you are a federal agency, you can have (and are in fact encouraged to have!) users with passwords that are unchanged for years.

Edit: it's worth pointing out that the memo does a great job of laying this out. I work in security, so possibly there's some curse of knowledge at play, but I found the blog post explainer to be less clear than the memo it is explaining...

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#74

Post by xoa »

meepmorp wrote: post #17
staticassertion wrote: post #2

This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edg…

Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

Yeah, while the clear and correct focus overall is on moving away from passwords entirely (FINALLY!!!!!) it's still nice to see something immediately actionable on at least improving policies in the mean time since those should be very low hanging fruit. Although one thing one thing I don't see is a mention of is doing away with (or close enough) password max character limits and requiring that everything get hashed step 1. Along with rotation and silly complex rules, stupid low character limits is the other big irritation with common systems. If passwords must be used they should be getting hashed client-side anyway (and then again server-side) so the server should be getting a constant set of bits no matter what the user is inputting. There isn't really any need at all for character limits at this point. If anything it's the opposite, minimums should be a lot higher. If someone is forced to use at least 20-30 characters say that essentially requires a password manager or diceware. And sheer length helps even bad practices.

But maybe they didn't bother giving much more effort to better passwords because they really don't want those to stick around at all and good for them. Password managers themselves are a bandaid on the fundamentally bad practice of using a symmetric factor for authentication.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#75

Post by tptacek »

SecurityLagoon wrote: post #70
tptacek wrote: post #59

Earlier quoted context omitted.

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the impl…

Thanks for saying this. This was exactly my take. Saying goodbye to VPNs just completely ignores the risk of RCE vulnerabilities on your services. You can have a VPN that still brings you into a zero trust network.

It does essentially define away the authentication bypass problem, which is a class of vulnerability we still regularly find in modern web applications. To say nothing of the fact that no human has ever implemented a SAML RP without a game-over vulnerability. Seems like a self-evidently bad plan.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#76

Post by jandrewrogers »

thomascgalvin wrote: post #23
adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.

There is a large contingent of non-religious people who are against it on civil liberties grounds. The resistance to it truly crosses both parties, and it requires the cooperation of the States, which makes it politically non-viable as a practical matter.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#77

Post by seniorThrowaway »

brimble wrote: post #21
adreamingsoul wrote: post #16

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

There's significant bi-partisan resistance, in the US, to anything like a national ID, unfortunately, with the result that we have one anyway (because of course we do, the modern world doesn't work without it) it's just an ad-hoc combination of other forms of ID, terrible to work with, heavily reliant on commercial 3rd parties, unreliable, and laughably insecure. But the end result is still a whole bunch of public an…

I've done some thinking about this, and a possible solution is a bunch of cross signed CA's like the Federal common policy / FPKI for cross trust amongst federal agencies, but done at a state DMV / DPS level. Driver's licenses / state IDs could have certs embedded into the cards and then be used for things like accessing government websites, banks, etc. Yes there are some access concerns, and some privacy concerns that this is in essence a national ID, but what we have now is horribly broken, and we're already being tracked. We get all the downside of pervasive tracking, but none of the upside.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#78

Post by KarlKemp »

kstrauser wrote: post #37
KarlKemp wrote: post #22

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The sam…

The "trust" here largely refers to identity. Do you trust that everyone in your house is your relative, by virtue of the fact that they're in your house? That falls down when you have a burglar. Similarly, is it good to trust that everyone on your corporate network is an employee, and therefore should have employee-level access to all the resources on that network? I wouldn't recommend it.

No, but I trust the people I regularly interact with and therefore allow them to be in my home. Nobody trusts people just because they happen to be in their home. To the extend that trust can go to “zero”, my fear is it will harm the (existing) first form of trust, which is vital, and have little impact on the stupid latter definition of trust.

I know tech operates on different definitions/circumstances here. That’s why the word ”zero” is so wrong here, because it seems to go out of its way to make the claim that less trust ks always better.

Call it “zero misplaced trust” or “my database doesn’t want your lolly”, whatever.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#79

Post by InitialLastName »

nybble41 wrote: post #49
seibelj wrote: post #34

Earlier quoted context omitted.

Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero

Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot…

> no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.

It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#80

Post by fire »

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks?

For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation

The idea is that if a pair of events breaches that minimum travel time by some threshold, it's a sign of credential compromise; It's effective for mitigating active session theft, for example, as any out of region access would violate the aforementioned minimum travel time between locations and produce a detectable anomaly

Post reply on HN