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

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

#221

Post by ineedasername » Fri, Jan 28, 2022, 1:20 AM UTC

0xffff2 wrote: post #165

ineedasername wrote: post #162

>It tells us to stop rotating passwords Finally! Maybe the places I've worked will finally listen. But I stopped reading TFA to praise this, so back to TFA.

NIST has made this recommendation for years. Sadly, I work for another branch of the Federal government and despite the NIST guidance I still have to rotate my password every 60 days. (Actually, the starts sending me daily emails warning me 15 days out, and the date is based on last change, so practically it's more like 45 days.)

I know, it's been a while since rotation was considered a best practice. Yet the security team where I work will pick a random shiny new security practice and impose it on users. (I don't mind the imposition of good security, the hassle is worth it).

Just one example where I work is a prohibition against emailing certain types of documents or data to others in the company (which is mostly Word & Excel docs) Which seems reasonable, but the accepted solution is to use the built in encryption of MS Office to secure the file with a password and then email the file. And then send the password in another email. Honestly, that's supposed to be the protocol. The policy also hasn't been amended in any way to account for implementing Google docs & sheets, which can be accessed with the same credentials used for email or opened on any unattended employee's machine if they left a Gmail tab open (along with anything else in their Google drive). And regardless of any of these rules, almost no one follows them. I do-- I have to, I'm a data custodian so I can't violate the rules, but it annoys people.

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

#222

Post by tialaramex » Fri, Jan 28, 2022, 1:29 AM UTC

Terretta wrote: post #95

kelnos wrote: post #91

Earlier quoted context omitted.

No, I'd expect it does include TOTP. Read it as "discontinue support for protocols that supply one-time codes". A TOTP app would fall under that description. TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SM…

> via SMS Or push, or other supply of a code from somewhere. It's just oddly worded, sounding like the code in all 3 cases is coming over the wire. Granted, phishing is a diff story, but in practice, I see Yubikeys permanently inserted to their laptop hosts, requiring even less intervention.

However the set of attackers who can get any advantage from the laptop sat on a conference table, much less your desk at home or in the office building, is both different and much less scary than the arbitrary crooks phishing people from the far side of the Internet.

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

#223

Post by chipotle_coyote » Fri, Jan 28, 2022, 1:30 AM UTC

0xedd wrote: post #204

btbuilder wrote: post #125

Earlier quoted context omitted.

I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions. They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.

Cars come with AndroidAuto (and whatever is for iOS). Only apps signed by Google can communicate with AndroidAuto. I don't want to use a Google phone or app to display OSM on my car's media screen. Why is this legal?

Once you're talking about interactive information displays in cars that can be accessed while the vehicle is in motion, traffic and highway safety regulations start cropping up. When you ask "Why is this legal," try rephrasing it to, "Why is it legal for companies to make it so difficult to play Doom on my BMW's touch screen," and you will probably arrive at the answer.

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

#224

Post by tialaramex » Fri, Jan 28, 2022, 1:37 AM UTC

mormegil wrote: post #144

zajio1am wrote: post #71

Earlier quoted context omitted.

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.…

#2 and partially #1 are solved by regulation and reputation: banks are highly regulated business, and BankID support requires specific security audit. Ad #3: FIDO is basically unusable for banking. It's designed for user authentication, not transaction signatures which banks need (and must do because of the PSD2 regulation).

If banks were actually onboard with this stuff, I'm pretty sure you can either make this happen in FIDO2 anyway, or you could add a FIDO extension that does it and get big vendors like Yubico to support that extension. Notice that off-line authenticating a Windows 10 PC relies on hmac-secret in FIDO, which is not a core FIDO feature, but it got ratified because there's a use for it, and a Yubikey can do hmac-secret.

But I do not see any such engagement from banks.

Transaction signatures are good if well implemented, but I'm not seeing a lot of good implementations. To be effective the user needs to understand what's going on so that they're appropriately suspicious when approached by crooks.

e.g. if I just know I had to enter 58430012 to send my niece $12, I don't end up learning why and when crooks persuade me to enter 58436500 I won't spot that this is actually authorising a $6500 transfer and I should be alarmed.

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

#225

Post by FredPret » Fri, Jan 28, 2022, 1:51 AM UTC

shbooms wrote: post #101

tablespoon wrote: post #81

Earlier quoted context omitted.

>> 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. > I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaning…

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

Your employer pays you, but you pay the TV provider. Hence what is acceptable is very different

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

#226

Post by missblit » Fri, Jan 28, 2022, 2:14 AM UTC

shbooms wrote: post #101

tablespoon wrote: post #81

Earlier quoted context omitted.

>> 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. > I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaning…

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

TV streaming services already do as much of this nonsense as they can get away with. The more "secure" of an environment their DRM runs in, the higher resolution the image they'll let you see.

It's just subtle enough (e.g. lower definition but will still play) and most people use "secure" enough setups that only techies, media gurus, or that one guy who's still using a VGA monitor connection end up noticing

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

#227

Post by zrail » Fri, Jan 28, 2022, 2:18 AM UTC

madjam002 wrote: post #172

zrail wrote: post #66

Earlier quoted context omitted.

Yeah, a thing that I wish Tailscale could do is hand off an attestation of some sort that says a TCP connection is being used by user X who is authorized by rule Y. Maybe "magic TLS client certs" is a thing coming on the horizon.

You can query the Tailscale API socket locally from your application to see who someone is (email address) based on the connecting IP. It would be nice if the API let you tap into their ACL system as well

Oh interesting!

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

#228

Post by pledess » Fri, Jan 28, 2022, 2:30 AM UTC

Our corporate IT folks have a Zero Trust Manifesto in which there are enrolled devices (laptops that remote SREs can carry around), there are enterprise applications, and there's connectivity between these (e.g., tunnel pairs). SREs often need to write scripts that operate on sensitive production data from the enterprise applications, but must do this work directly on an enrolled device.

Pre-Zero-Trust days seemed safer. Copying production data to a laptop wasn't allowed. Instead, each SRE had their own Linux VM in the data center, accessible from home and able to run the scripts (with connectivity to the enterprise application). This prevented a whole class of realistic attacks in which a laptop (while unlocked/decrypted) is taken by an adversary. Admittedly, in return, we're protected from a possible, but less likely, attack in which a Linux VM is compromised and used for lateral movement within one segment of the enterprise network. (An enrolled device has to be in the user's possession; it can't be any machine, Linux or Windows, in the data center or office.)

The only people who love this are our enterprise application vendors. Our bosses are paying them a TON more money to implement new requirements where, in theory, all possible types of data analysis can be done directly within the enterprise application. No more scripts, no more copying of data. No more use of Open Source. And, of course, people from these same enterprise application vendors advise the government that Zero Trust must be a top priority mandate.

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

#229

Post by lotsofpulp » Fri, Jan 28, 2022, 2:41 AM UTC

ryukafalz wrote: post #150

dathinab wrote: post #135

Earlier quoted context omitted.

Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…

This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies. I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.

That is a job for the government. They should have made electronic payments and electronic accounts for everyone a utility many years ago.

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

#230

Post by AdamH12113 » Fri, Jan 28, 2022, 2:42 AM UTC

cryptica wrote: post #213

I thought we had reached peak bureaucracy but I was wrong. On the plus side, it's good that they finally figured out that forcing frequent password changes and forcing the usage of special characters are anti-patterns. I've been repeating this for over a decade. Deprecating passwords is the wrong conclusion. A better solution would be to educate people about good password creation and handling practices. A 1-page doc…

Organizations have been educating people about good password creation and handling practices for over a quarter century. It hasn't worked and there is no sign that it will ever work.

(Perhaps I misunderstood and you were being sarcastic?)