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

271–280 of 369 posts

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

#271

Post by mormegil »

tialaramex wrote: post #224
mormegil wrote: post #144

Earlier quoted context omitted.

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

I think the FIDO Alliance is already discussing solutions to these use cases. (And also this is a bit circular reasoning, isn’t it? “Why don’t you use the XYZ standard? Because it does not support our use case. So why don’t you cooperate on adding support to the standard? Why? So that you can use the XYZ standard!”) Also, I think there already are extensions supporting some basic forms of this, however, they are not supported very well.

But I’m afraid the basic prerequisite of secure transaction signing (“what you see is what you sign”) cannot be fulfilled on a generic “FIDO2 authenticator” – you need the authenticator to have a display. Sure, Windows Hello / Android FIDO / … might support this, but your common hardware Yubikey cannot.

I don’t know to which authentication method used by which bank in which country you refer in your “58430012” example, but this is definitely nothing which could be used as a method of transaction signatures in banks here, and it does not fulfill the requirements of the PSD2 regulation.

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

#272

Post by kortilla »

seized wrote: post #256
kortilla wrote: post #244

Earlier quoted context omitted.

This is the problem with this kind of thing. It just perfectly captures the privilege/shelter of the programmers who come up with these heuristics of “obviously unusual”. You just described the usage pattern of a pilot with a family, a truck driver, a seaman, etc. It’s only unusual if your definition of usual is “relatively rich, computer power user”.

Not really. What's the use case there, everyone sharing a Google account? I travelled a lot for work, and never had issues with account access. Nor did my wife ever have issues related to accounts. We don't share Google accounts though. It sounds like that user has personal accounts being used by three people for business use... Which isn't "A seaman and his family".

> What's the use case there, everyone sharing a Google account?

Yes. Everyone having their own distinct accounts is a property of high computer literacy in the family.

Many of my older extended family members have a single email account shared by a husband and wife. Or in one case the way to email my aunt is to send an email to an account operated by a daughter in a different town. Aunt and daughter are both signed in so the daughter can help with attachments or “emails that go missing”, etc.

> Which isn't "A seaman and his family".

The seaman in this scenario has a smartphone with the email signed in. It’s also signed in on the family computer at home. Both the wife and him send email from it. Maybe a kid does to from a tablet. This isn’t that difficult.

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

#273

Post by fire »

judge2020 wrote: post #111
fire wrote: post #80

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

Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.

From my experience it isn't a be-all-end-all so much as another point of data for anomaly detection.

In practice, geoip "regions" like used for this _are_ on the larger scale, yes; However that still lets you ask valuable questions like "why is this user who logs in from Vermont, USA suddenly in Hungary?" and potentially do something proactive like limiting that session's resource access until a new MFA challenge has been passed, or ( more aggressively ) destroy the session or otherwise force a full reauth.

The downside is that this almost always relies on some actively maintained geoip database ( ala maxmind ), which... well it isn't exactly cheap, and it isn't exactly perfect, either ( see: maxmind historically putting IPs in a central location when lacking specific data )

Ultimately it's one part of ( what should be ) a suite of checks for anomalous behavior, not something to blindly implement. The latter can cause a great deal of grief if your tolerances are too tight or your proactive actions aren't in line with the activity/abuse they're intended to mitigate.

A pretty direct example of proactive action would be restricting access to using saved payment methods on a platform until the user has completed a new 2fa challenge.

You could require this challenge every time the user wants to buy something, yes, but as that will probably impact checkout rates, you could get many ( if not most ) of the same fraud prevention benefits by only challenging when the session has moved some threshold distance - It won't stop them from buying something at home or a coffee shop in town, but would stop a session hijacker on an opposing coast or another country from doing so.

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

#274

Post by xyzzy_plugh »

mjg59 wrote: post #267
xyzzy_plugh wrote: post #249

Earlier quoted context omitted.

> * SSO integration on all internal apps. > * An authenticating proxy I'm having trouble understanding what the fundamental difference is between these. Is it just a matter of a single, centralized proxy at the perimeter of your service network versus in-service SSO? Is there a functional difference between being in the same process space versus a sidecar on the same host versus a service on another host? Ultimately…

Most SSO solutions don't verify device identity or state, so you're not ensuring that the connection is coming from a computer you trust running software you trust.

I guess it's a matter of what the IdP attests. It's definitely possible for an IdP like Okta to include a ton of client details as part of the attestation payload. Stuff like GeoIP, client certificate fields, MDM status, etc.

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

#275

Post by AndyMcConachie »

tptacek wrote: post #236
philosopher1234 wrote: post #142

Earlier quoted context omitted.

Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.

No, DANE is very bad. But it's a dead-letter standard, so I don't worry about much.

You think no one is deploying DANE for SMTP?

https://stats.dnssec-tools.org/images/domains.svg

It's deployed on many more domains than MTA-STS.

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

#276

Post by [deleted] »

thinkmassive wrote: post #268
pabs3 wrote: 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

[deleted]

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

#277

Post by cryptica »

AdamH12113 wrote: post #230
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?)

They haven't even come up with such practices, let alone taught them to anyone.

The practices which they did come up with have been terrible, even harmful (e.g. changing passwords often and using special symbols).

Of course if you teach the wrong thing, you will get the wrong results.

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

#278

Post by cabbagehead »

raxxorrax wrote: post #270
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…

These are strong requirements, but I fear the government just wants more transparency of citizens. Remote-attestation of trusted platforms could lead to the worst surveillance attempts we have ever seen. And it would require you to trust your government. That is a bad idea from a security point of view. edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So m…

No post body was provided.

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

#279

Post by grogenaut »

fire wrote: post #80

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

I'm constantly traveling between Seattle (home) and San Jose (vpn1) or Boardman, OR (us-west-2) according to "logged in from X", so doesn't really work unless you offsetting rules/attributes.

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

#280

Post by cabbagehead »

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…

No post body was provided.
Post reply on HN