-6

I just created Webkey in the last couple days. It's built to do client-certificate auth without using the (in my opinion unusable) client-cert functionality built into browsers. It would allow single-password auth just like an ssh key does, but for the web.

The user's password is never sent over the internet (even in encrypted form). This utility can be hosted entirely statically (and is currently being hosted at http://webkey-auth.github.io/test/guest.html ).

The requesting application loads webkey in an iframe over https. On-request of auth, if the user hasn't created an RSA keypair, webkey does that in the iframe and saves it in local storage (encrypted with aes using a password the user creates). The user also saves an email to be used as their ID.

Here are the auth steps in more detail from the perspective of the application requesting auth:

  1. On the client, request the user's acceptance (requestAcceptance command) and send the resulting email and public key to the server
  2. On the server, if that email is not already in the system with that public key, send them a verification email (if you want) and once verified, associate the email and public key in your database and skip to step 7 if that email is in the system with that public key, continue to step 3
  3. On the server, generate a 3-20 character token (in string form) and send it to the client
  4. On the client, send the token into webkey's iframe using the 'auth' postMessage command
  5. On the client, receive the signed token (called the proof) from webkey and send that proof to the server.
  6. On the server, verify that the token with the given public key (the server should still have the original token - do NOT trust any tokens sent to the server by the client)
  7. Profit! Your user's now authenticated!

Is what I'm doing here theoretically secure? What are potential problems with how this works?

Improve this question
5
  • 3
    Please make your question self-contained. Describe your protocol. Code is too much detail, but what you wrote in your question is too little. Who is trying to authenticate whom? What verifications are performed? When are keys generated and stored? It isn't even clear based on your question whether the party directly authenticates a client to a server, or involves a third party.
    – Gilles 'SO- stop being evil'
    Apr 5, 2016 at 11:04
  • 1
    How is your solution any better than using mutual auth SSL and a SSO system such as OpenID Connect?
    – Neil Smithline
    Apr 5, 2016 at 14:13
  • @NeilSmithline I added a couple sections talking about mutual ssl and oauth under the Motivation section in the readme on github if you'd like to check that out.
    – B T
    Apr 5, 2016 at 19:48
  • 1
    @BT If it is relevant to the question, it needs to be in the question, else it is unlikely to be considered. Remember that answers here tend to be written to last, so any third party links make them more likely to become less useful.
    – Matthew
    Apr 5, 2016 at 20:35
  • @Matthew Gotcha, I understand. Is there anything particular you think I'm missing? I feel like the gist is explained here, but I obviously won't paste my entire repo here.
    – B T
    Apr 5, 2016 at 23:39

1 Answer 1

Reset to default
3

If the service is meant to be statically hosted, there are several problems with this.

The most important one would be that you are using JavaScript in a browser for crypto. That is, as the link explains in detail, not even practically secure.

Discussing theoretical security may just as well stop right there.

Do not use JavaScript for crypto. You just cannot trust the user on anything.

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Apr 5, 2016 at 10:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .