Most active commenters

    ←back to thread

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

    (www.bastionzero.com)
    656 points EthanHeilman | 11 comments | 27 Jan 22 15:06 UTC | HN request time: 0.985s | source | bottom
    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 #
    1. pitaj ◴[27 Jan 22 18:17 UTC] No.30104022[source]▶
    What's wrong with TOTP?
    replies(4): >>30104104 #>>30104125 #>>30104610 #>>30114646 #
    2. Sesse__ ◴[27 Jan 22 18:22 UTC] No.30104104[source]▶
    It authenticates the user to the service, but not the service to the user, so it's vulnerable to phishing (or MITM, of course, if you don't have TLS).
    3. jaycroft ◴[27 Jan 22 18:23 UTC] No.30104125[source]▶
    I was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test.

    https://blog.trezor.io/why-you-should-never-use-google-authe...

    Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".

    replies(3): >>30104161 #>>30104615 #>>30104778 #
    4. ◴[27 Jan 22 18:26 UTC] No.30104161[source]▶
    5. tptacek ◴[27 Jan 22 18:59 UTC] No.30104610[source]▶
    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 a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious.

    You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.

    replies(2): >>30108176 #>>30109030 #
    6. tptacek ◴[27 Jan 22 18:59 UTC] No.30104615[source]▶
    Yeah these are very dumb arguments against TOTP.
    7. ◴[27 Jan 22 19:12 UTC] No.30104778[source]▶
    8. bradstewart ◴[27 Jan 22 22:52 UTC] No.30108176[source]▶
    They also come from (seemingly) random phone numbers and/or short codes, with absolutely no way to verify them.
    9. withinboredom ◴[28 Jan 22 00:20 UTC] No.30109030[source]▶
    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.

    replies(1): >>30109262 #
    10. tialaramex ◴[28 Jan 22 00:44 UTC] No.30109262{3}[source]▶
    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.

    11. yonixw ◴[28 Jan 22 14:00 UTC] No.30114646[source]▶
    MITM phishing attacks (also called real time phishing).

    If someone just put a fake domain that proxies everything between you and the server (with fake domain with HTTPS... which he social engineered you to get on)

    Looks like FIDO2 2FA only sign the challenge response against the server certificate available locally (= the phishing domain) so just passing it to the original server will fail. Also, the attacker can't just re-sign the challenge response after you, because the challenge was sent from the original server already encrypted with the public key of the user (stored from the registration phase). So only the registered user can see the challenge and respond to it.

    This leaves only 2 options to do a phishing attack: 1) Get a valid certificate for the original domain [1] 2) force downgrade the user to old TOTP [2]

    [1] https://security.stackexchange.com/q/157756/69837

    [2] https://eprint.iacr.org/2020/1298.pdf