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

201–210 of 369 posts

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

#201

Post by sciurus »

freedomben wrote: post #160
hansvm wrote: post #137

Earlier quoted context omitted.

Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.

It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what…

Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

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

#202

Post by withinboredom »

jollybean wrote: post #63
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.

That's all good except for the 'bank' part. It was expedient but banks are not the orgs. that should be running that. Every nation needs to turn their Drivers ID and Passport authorities into 'Ministry of Identity' and issue fobs, passwords that can be used on the basis of some standard. Or something like that, maybe quasi distributed.

Here in the Netherlands we have DigID. It’s actually pretty awesome.

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

#203

Post by tialaramex »

tptacek wrote: post #86
nextos wrote: post #85

Earlier quoted context omitted.

> 1. No more SMS and TOTP. FIDO2 tokens only. SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives. However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.

The major advantage of FIDO2 is that it's difficult to phish. SIM cloning is not the primary reason organizations are now advocating against SMS 2FA.

In particular [Thomas knows this, for anybody else reading], WebAuthn (the way you use FIDO for the web, U2F is a legacy system for doing the same thing that you should not use in greenfield deployments) recruits your web browser to defeat phishing.

When you use WebAuthn to sign into an site the browser takes responsibility for determining which site you're on, cutting out the whole phishing problem of "Humans don't know which site it is". The browser isn't reading that GIF that says "Real Bank Secure Login" at the top of the page or the title "Real Bank - Authenticate" or the part of the URL bar that says "/cgi-bin/login/secure/realbank/" it is looking only at the hostname it just verified for TLS which says fakebank.example

So the browser tells your FIDO authenticator OK, we're signing in to fakebank.example - and that's never going to successfully steal your Real Bank credentials because the correct name is cryptographically necessary for the credentials to work. This is so effective crooks aren't likely to even bother attacking it.

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

#204

Post by 0xedd »

btbuilder wrote: post #125
shbooms wrote: post #101

Earlier quoted context omitted.

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…

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?

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

#205

Post by freedomben »

sciurus wrote: post #201
freedomben wrote: post #160

Earlier quoted context omitted.

It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what…

Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

The frustrating thing to me is that as a user they don't give us any tools to help ourselves. I would gladly make it a "team" account and login individually if we could. I would gladly do a shared TOTP, or whitelist login locations, or anything like that. Or at least give us the option to accept the risk and disable whatever anomaly detection they are applying. But no, that's not how the software world works anymore. Extreme paternalism mode is the only option as a user.

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

#206

Post by dmd »

YeBanKo wrote: post #147
tims33 wrote: post #18

Really pleasantly surprised at how progressive this memo is. It will be interesting to see the timelines put in place to make the transition. Btw - I'd love to see the people who put this memo together re-evaluate the ID.me system they're implementing for citizens given how poor the identity verification is.

I have an issue with using ID.me for government websites, because it is a privately owned company. Online authentication at this point seems as important as USPS service and warrants being owned and developed by the government itself.

They even HAVE this already, at https://login.gov/ !

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

#207

Post by tialaramex »

withinboredom wrote: post #197
tptacek wrote: post #53

Earlier quoted context omitted.

It's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?" It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got…

Aren’t you talking about sms auth? The issue with TOTP is that it’s usually not rate limited. Just sit there guessing codes and you’ll eventually get in.

Nope, TOTP is vulnerable to phishing just the same.

Ordinary users think the fact your phishing site accepted their TOTP code is actually reassuring. After all, if you were a fake site, how would you have known that was the correct TOTP code? So this must be the real site.

The only benefit TOTP has over passwords is that an attacker needs to use it immediately, but they can fully automate that process so this only very slightly raises the barrier to entry, a smart but bored teenager can definitely do it, or just anybody who can Google for the tools.

Worse, TOTP involves a shared secret, so bad guys can steal it without you knowing. They probably won't steal it from your bank because the bank has at least some attempt at security, but a lot of other businesses you deal with aren't making much effort, and so your TOTP secret (not just the temporal codes) can be stolen, whereupon all users of that site relying on TOTP are 100% screwed.

Notice that WebAuthn still isn't damaged if you steal the auth data, Google could literally publish the WebAuthn authentication details (public key and identifier) for their employees on a site or paint them on a huge mural or something and not even make a material difference to their security - which is why this Memo says to do WebAuthn.

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

#208

Post by themacguffinman »

dathinab wrote: post #135
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.

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…

> but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them

The point of these restrictions is to ensure that your device isn't unusually vulnerable to privilege escalation in the first place. If you let them, some users will root their phone, disable all protections, install an malware-filled Fortnite apk from a random website then stick their credit card company with the bill for fraud when their user-mangled system fails to secure their secrets.

You want to mod the shit out of your Android phone? Go ahead. Just don't expect other companies to deal with your shit, they're not obligated to deal with whatever insecure garbage you turn your phone into.

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

#209

Post by 0xedd »

bigiain wrote: post #139
kelnos wrote: post #88

Earlier quoted context omitted.

It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.

I’m not even so sure I’m totally against banks doing that either. From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way w…

No post body was provided.

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

#210

Post by 0xedd »

alksjdalkj wrote: post #129
c0l0 wrote: post #31

Earlier quoted context omitted.

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 meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…

Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some po…

Wrong. 80% of attacks are social engineering ones. In which an employee is convinced to make a bank transfer, open some document, install some program. From there, often times it's exploiting wide spread software commonly found in large organizations.

Everything you said cannot be further from the truth.

Post reply on HN