7 ms·
The scheme you outline still allows trivial impersonation attacks.
by sdevlin 11y ago
The scheme you outline still allows trivial impersonation attacks.
- BoppreH 11y agoCare to provide an example? And keep in mind this is not a complete authentication protocol. I'm just proposing a small change to fix the signing-not-random-nonce problem, so I assume the rest of the protocol context is kept. Barring stupid mistakes from my part, if this is vulnerable to impersonation so is the article's.
- sdevlin 11y agoAlice is an end user. Eve and Bob each host legitimate servers. Alice authenticates to Eve, and Eve impersonates Alice to Bob like so: A E B -hello-> -hello-> <-nonce- <-nonce- -random-> -S(rand)> -S(n^r)-> -random-> -S(rand)> -S(n^r)->
- BoppreH 11y agoIf Alice doesn't validate the identity of the server, that's absolutely a legitimate attack. But building a secure channel is out of scope and assumed solved here. The problem is how can Alice authenticate to Bob without exposing herself to signing arbitrary documents. (nice diagram, by the way)
- sdevlin 11y agoTo be clear, Alice is intentionally authenticating to Eve in this scenario. So a secure channel does not impede the attack. For example, suppose Eve is Facebook and Bob is Google. Alice logs into Facebook, but what she doesn't know is that Facebook is passing her signatures directly through to Google. Now Mark Zuckerberg can like YouTube videos on Alice's behalf. To prevent this, Alice must also sign the domain she's authenticating to. The article mentioned this, and maybe you had meant it to be implicit in your protocol, in which case: my bad.
- BoppreH 11y agoI totally overlooked that, thank you for pointing out. Thankfully the fix is simple. I've updated the original post.
- spb 11y agoWell, yeah, but as BoppreH said, that's still present in the original article's design. What BoppreH's solution doesn't allow (which is the problem the article raises) is the tricking of Alice into signing arbitrary data.