←back to thread

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

(www.bastionzero.com)
656 points EthanHeilman | 5 comments | 27 Jan 22 15:06 UTC | HN request time: 0.217s | source
Show context
staticassertion ◴[27 Jan 22 15:56 UTC] No.30102061[source]▶
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 edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
meepmorp ◴[27 Jan 22 18:05 UTC] No.30103846[source]▶
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.

replies(5): >>30104317 #>>30104644 #>>30104914 #>>30106431 #>>30108010 #
mooreds ◴[27 Jan 22 20:50 UTC] No.30106431[source]▶
To be fair, this was part of the NIST guidelines since Mar 2020. A whole appendix was added to justify it: https://pages.nist.gov/800-63-3/sp800-63b.html#appA
replies(1): >>30106864 #
1. gkop ◴[27 Jan 22 21:19 UTC] No.30106864[source]▶
Way earlier than that, even.

> Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets

Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too.

https://web.archive.org/web/20160624033024/https://pages.nis...

replies(2): >>30107106 #>>30109354 #
2. dragonwriter ◴[27 Jan 22 21:37 UTC] No.30107106[source]▶
SHOULD NOT and MUST NOT are very different from a compliance perspective.

The former usually means something between nothing at all and “you can do it but you have to write paperwork that no one will actually read in detail, but someone will maybe check the existence of, if you do”.

The latter means “do it and you are noncompliant”.

replies(2): >>30107391 #>>30108778 #
3. dllthomas ◴[27 Jan 22 21:59 UTC] No.30107391[source]▶
https://datatracker.ietf.org/doc/html/rfc2119 is a good reference, although those precise definitions may or many not be in effect in any particular situation (including this one).

See also https://datatracker.ietf.org/doc/html/rfc6919

4. gkop ◴[27 Jan 22 23:52 UTC] No.30108778[source]▶
Thanks for pointing out the improvement over NIST, it wasn’t clear to me. But did you mean to reply to my parent? Both the draft and the current language say SHOULD NOT. I’d rather “must”, but will settle for “should”; the NIST docs have certainly made my work easier. Hopefully NIST improves, and perhaps this memo will help!

The essential purpose of my comment was only to correct my parent on the date.

5. wslack ◴[28 Jan 22 00:54 UTC] No.30109354[source]▶
They accepted edits via pull request when that was in the works! [1] Such a better model of giving feedback or suggesting edits compared to sending in a marked-up PDF.

[1]: https://github.com/usnistgov/800-63-3/pull/576