Hacker News Reader

Comment by sdevlin | Hacker News Reader

The scheme you outline still allows trivial impersonation attacks.

Care 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.

Alice 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)->

If 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)

To 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.

I totally overlooked that, thank you for pointing out. Thankfully the fix is simple. I've updated the original post.

Well, 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.

Reply on news.ycombinator.com