Live data from Hacker News

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

bastionzero.com

341–350 of 369 posts

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

#341
post #91

I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably o…

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…

> No, I'd expect it does include TOTP

I'd expect it to be any mechanism that doesn't do mutual authentication. In other words the authentication not only proves to the service your "you", it also proves to you the service is the one you think you are authenticating to. And it does that reliably even in the face of a MITM attack.

It's damned hard to do, and obviously none of SMS, TOTP and passwords do it. https + passwords was supposed to do it and technically does do it, but in practice no one looks at the domain name. Email + DKIM could do it, but no email client shows you outcome of DKIM auth and again no one would look at that anyway.

WebAuthn / FIDO2 does do it. It's undoubtedly the best option right now, but until tokens that open source + reproducible build right down to the metal, they aren't "Zero-Trust". You are forced to trust Yubi or Google or whatever as the tokens they give you are effectively black boxes. Worse, because an open source token means "easily build-able many companies" and thus means "WebAuthn tokens become a commodity", I expect Yubi to fight it to their dying breath.

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

#342
post #189

Earlier quoted context omitted.

Identical source code when recompiled should produce identical binaries: https://reproducible-builds.org/ Agreed that people should have the freedom to modify their software though.

A remote cryptographically-signed attestation is not reproducible https://developer.android.com/training/safetynet/attestation

I don't know much about attestation, but the repro builds folks have an approach for dealing with signatures; you build once, then copy the signature into the source, so that as long as the unsigned build result is bit-identical, the signatures still match and anyone can reproduce the signed build result.

https://reproducible-builds.org/docs/embedded-signatures/

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

#343
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.

> Do not give long-lived credentials to your users.

That was poorly worded in the article. Among the things it is is saying you should give to your users is a WebAuthn token. Inside the WebAuthn token is a random private key it never reveals. That is the thing the authentication "you are you" ultimately relies on, and it is very much a "long lived credential".

What he is trying to say is more complex. It's something along the lines of "you go to some authentication / authorisation service, prove you're you and say you want access to a service, and it hands you back some short term credentials you can provide to that service allowing you to use it". You, the authentication provider, and the service you trying to access might be in different countries. The danger in that scenario is someone might steal those credentials while they are in transit. One way to mitigate that is to ensure those credentials don't last for very long.

So, it's a statement about how distributed systems should handle passing credentials among themselves. The user never sees these credentials, and of course never has to remember them. Any temporary credential lasting longer than a persons sleep/wake cycle it considered broken in this world, but it's understood the user will carry with them a relatively long lived way of proving they are who they say they are.

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

#345

Earlier quoted context omitted.

Yubikeys aren't the serious long-term alternative to TOTP; software keys embedded in phones are what we're going to end up with.

I have a newbie question: Can't we embed a hardware key into a phone, and that'd be just as good as a Yubikey? Do we already do this, or is there a reason why we don't?

Laptops can have smart cards so there's no reason a phone couldn't

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

#346

Earlier quoted context omitted.

In practice, many credit unions/banks will only support recent versions of major desktop browsers (ie. the big three: Chrome, Firefox, Safari) which are known to mandate a good level of security. These browsers will usually have their own OS requirements. For eg Safari is tied to macOS versions directly while Chrome will drop support for older unmaintained operating systems like Windows XP. Any system can have malwar…

So require I have an up to date browser on my phone. Don't require that I haven't rooted it when every desktop is in an equivalent security state. That's not enough to be "unusually vulnerable". I'm not asking to use a 10 year old version of android that no modern browsers support any more and is missing many security features.

So what if the desktop is in a worse state? Mobile is still a common threat surface that supports stronger security measures. Unusual is relative, mobile is much more secure by default. It makes no sense to weaken the security posture for mobile users just because the desktop/web doesn't allow a stronger one.

I guess you also think Android/iOS should just get rid of app permissions because users could just use similar software on their desktops without any permissions gating?

Edit: Android/iOS are increasingly popular platforms, the security they pioneer far exceeds their desktop predecessors and has improved the average security posture of millions of mobile-focused users.

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

#347

Earlier quoted context omitted.

> As a side note the attack scenario you describe works without needing any rooting or anything it already exists and isn't detected by their security mechanism. Android will block non-Play-Store app installations by default, and root is required for lower level access/capabilities that can bypass the normal sandbox. I'm honestly not sure what you're saying about 2FA in the rest of your comment, it's kind of vague an…

> installations by default No, you basically have to click on ok once (or change a setting, depending on phone), either way it doesn't require root, and doesn't really change the attack scenario as it's based one someone intentionally installing an app from an arbitrary not-trusted source. > root is required Yeah, like privilege escalation attacks. As you will likely find in many compromised apps. And which on many A…

Only on Android is it so simple to sideload, and even then there are lower level app capabilities that require root even for sideloaded apps.

Good security is layered. Just because privilege escalation attacks are sometimes possible without root doesn't mean you throw open the floodgates and ignore the threat of root. The point of banning rooted devices is that privilege escalation attacks are much easier in rooted devices.

Of course online banking doesn't require locked down devices, but online banking is more secure in locked down devices. I don't see why banks should weaken their security posture on root just because they aren't perfect in other areas.

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

#348

Earlier quoted context omitted.

So require I have an up to date browser on my phone. Don't require that I haven't rooted it when every desktop is in an equivalent security state. That's not enough to be "unusually vulnerable". I'm not asking to use a 10 year old version of android that no modern browsers support any more and is missing many security features.

So what if the desktop is in a worse state? Mobile is still a common threat surface that supports stronger security measures. Unusual is relative, mobile is much more secure by default. It makes no sense to weaken the security posture for mobile users just because the desktop/web doesn't allow a stronger one. I guess you also think Android/iOS should just get rid of app permissions because users could just use simila…

> It makes no sense to weaken the security posture for mobile users just because the desktop/web doesn't allow a stronger one.

The motivation is not "just" that, or for fun, the motivation is that users should be allowed to control their own devices. And have them keep working.

> I guess you also think Android/iOS should just get rid of app permissions because users could just use similar software on their desktops without any permissions gating?

I want it to work... exactly like app permissions. Where if I root it, I can override things.

> Android/iOS are increasingly popular platforms, the security they pioneer far exceeds their desktop predecessors and has improved the average security posture of millions of mobile-focused users

Having that kind of sysadmin lockdown is useful, but if I want to be my own sysadmin I shouldn't be blacklisted by banks.

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

#349

Earlier quoted context omitted.

You're right, many secure apps don't go far enough in blocking Android releases that are probably too old & vulnerable. Not all apps are perfect, but blocking rooted and ancient devices is a start.

No, it's starting at the wrong end and not in any relevant way provide an improvement. Checking for an too old & vulnerable is where you start. And then you can consider to maybe also block other stuff. There is nothing inherently less secure about an rooted device. Sure you can make it less secure if you install bad software, but you can also make it more secure. Or you just need to lower the minimal screen brightne…

> There is nothing inherently less secure about an rooted device.

This is clearly wrong, rooted devices are much more insecure because they enable low level access to maliciously alter the system. Malware often requires root and will first try to attempt to attain root, which of course isn't necessary if a user has manually unlocked root themselves.

> Your claiming it's ok to take the agency from people away to decide over a major part of their live (which sadly phones are today) because maybe they could act irresponsible and do something stupid.

No one is taking away any user's agency. Users are free to root their phones if they wish (many Android phones at least will allow it), but companies are also free to deny these users service. Users are free to avail themselves of any company's service on a non-rooted phone. "Not using rooted phones to access anything you like" is hardly a major loss of agency.

Phone insecurity is very dangerous IMO, much more dangerous really than bathtubs or perhaps knives. You could argue that vehicles are similarly very dangerous and I'd agree. I don't think we're very far off from locked down self-driving cars. Unfortunately we're not there yet with self-driving tech and the current utility of vehicles still outweighs their immense safety risks. You can't really say that about rooted phones. The legitimate benefits of a rooted phone are largely relevant to developers, not the average user, and most users never attempt to tinker with their phone.

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

#350
post #250

Earlier quoted context omitted.

Have you considered using the same Proxy or VPN? I work remotely and sometimes access services through a VPN based in the country my coworkers are at specifically to avoid this kind of annoyance.

This is a great idea, although the boss is pretty technically challenged so getting him set up on it might be interesting. It's been extremely difficult just to teach him to use LastPass. Much appreciate the suggestion!

There are also a number of browser extensions which may be easier to set up and use for non-technical folks, for example FoxyProxy seems to offer one. I've never tried any myself, though.
Post reply on HN