1

I was thinking about zero-trust systems over the last few weeks and it seems like there are many things that could be implemented that way. With password managers being one of those things, I was curious about designing something like google sign-in as a zero-trust account/authentication system.

Let's call such a system "MyAuth" to make it easier to talk about it.

First of all, here are some requirements I have for MyAuth:

  1. Zero-Trust: It should not be possible for anyone from MyAuth to login as an MyAuth user on any of the registered 3rd party services. Note (1.a): I wanted to add that it should not be possible for anyone from MyAuth to see which services I am using or talking to, but I could not think of a way to do that in a way that it cooperates with requirement (3). Note (1.b): This implies that all 3rdParty Services need a way of authentication. MyAuth is not a replacement for that like it is with google sign-in.
  2. Data Breaches: For a 3rd party service, anyone with readonly access to the database must not be able to login with my user on that service and they should not be able to get any information on my MyAuthId or MyAuth credentials.
  3. Additional/Default Security: Whenever I want to login to a 3rd party service I also have to authenticate my access to this login via my MyAuth account. Note (3.a): This guarantees a basic level of security, the security of my MyAuth-account itself.
  4. Login Attempts: I want to see each login attempt from a yet unauthorized device on any of the 3rdParty services I use.

That said, I think I have a design for these things. I think the design could be tweaked a little but I will get to that after I present it.

Assuming I already have a zero-trust data service MyAuth0 which can store data and send messages between the server and the client. This means MyAuth0 can not read the data stored in my vault because I have a secret that is used to calculate the login password and the encryption key for the data and the encryption key cannot be calculated from the login password.

Registration:

  1. Me->MyAuth: I would like some login tokens to use with other services please
  2. MyAuth->Me: Sure thing, here are some tokens. You will need an active session to get an authentication request. 2.5. Me: Stores logins in the vault to be used in the future
  3. Me: pressing "sign-up with MyAuth", which opens an MyAuth dialog. Logging in and selecting an unused login-token I would like to use for the sign-up process.
  4. Me (session x on device z)->3rdParty: I would like to register on your Service using MyAuth and this login token please. We will be communicating over MyAuth in the future, so let us use a zero knowledge proof based authentication mechanism. Here, this is something you can use to test whether I know my secret, just generate as many questions as you think are sufficient and send them with your MyAuth authentication reqeust in the future.
  5. Me: Stores my secret and the login token in my vault in a way that I know which secret is needed if the server wants to authenticate the login token in the future, add a timestamp to the login token so I can differentiate between multiple accounts on the same 3rdParty App, might add a label manually later.
  6. 3rdParty->MyAuth: Hello, could you please authenticate that this login token can be used from this device and can you forward this message here? Thanks. (Message contains challenges)
  7. MyAuth->Me (on any active session): Hey, someone wants to verify that you are using this login token from the following device, is that correct? Oh, here is a message from them.
  8. Me (from any active session)->MyAuth: Yes, can you please send them this message back? (message contains the solved challenges)
  9. MyAuth->3rdParty: Okay, the login token may be used for the device this time, here is a message from the user.
  10. 3rdParty: Checks whether the responses match with what was expected
  11. 3rdParty->Me (session x on device z): looks good, here we go.

Login:

  1. Me: pressing "login with MyAuth", which opens an MyAuth dialog. Logging in and selecting the login-token I would like to use.
  2. Me (session x on device z)->3rdParty: I would like to log into your Service using MyAuth and this login token please.
  3. 3rdParty->MyAuth: Hello, could you please authenticate that this login token can be used from this device and can you forward this message here? Thanks. (Message contains challenges)
  4. MyAuth->Me (on any active session): Hey, someone wants to verify that you are using this login token from the following device, is that correct? Oh, here is a message from them.
  5. Me (from any active session)->MyAuth: (Clicks ok) Yes, can you please send them this message back? (message contains the solved challenges)
  6. MyAuth->3rdParty: Okay, the login token may be used for the device this time, here is a message from the user.
  7. 3rdParty: Checks whether the responses match with what was expected
  8. 3rdParty->Me (session x on device z): looks good, here we go.

The design could be tweaked a little as I said. I would also like to add the feature that MyAuth can't read the messages between the server and me. I think it would be possible to implement the communication protocol from signal. This got a little over my head but I think it would also add additional defence against someone from MyAuth trying to log in to a 3rdParty application if they know the secret I use for the zero-knowledge proof and if they have write access to the MyAuth database.

If this communication encryption is not present, someone from MyAuth with write permissions could change the MyAuthId related to the login token to theirs and store the secret to the 3rdParty service there. On request they can then calculate the challenges. With the encryption in place they would need yet another piece of the puzzle and it would make it harder to get the other piece in the first place.

I would love to hear your opinion regarding usability, security and feasibility of this as a real-world application. Are there any security holes in the design itself? Are there any unnecessary security features that are just security by obscurity?

4
  • 2
    Have you read anything about how OAuth works? That's what "Google sign-in" actually is. There is also a service called "Authy" that uses OAuth.
    – schroeder
    Dec 30 '20 at 8:07
  • @Gamer2015: I've replaced the name of your "authy" system with "MyAuth" in order to avoid confusion with the well established product Authy. Dec 30 '20 at 8:50
  • @Gamer2015: OAuth is independent from Google and is widely used outside of Google. It just happens that Google provides OAuth and Google also provides GMail. But OAuth can be implemented without this, i.e. the property 1 is not violated by OAuth but only by the specific use of OAuth in the context of Google. Dec 30 '20 at 8:54
  • @SteffenUllrich Okay yes, that was a little unfair of me. Using only the OAuth protocol I think this still does not satisfy 1. As I understand it there are a resource- and an authorization server, those servers authorize the 3rd party and provide them with an access token. From my understanding it should be possible for someone who has access to those servers to click "sign in with google/facebook etc" and then proceed to send an access token for my user to the 3rd party, thereby authenticating as me when in reality they are not. Deleted old comments because they were poorly formulated.
    – Gamer2015
    Dec 30 '20 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.