Potential security issue with Frontend Token Autentication

boringproxy
1

I recently started using BoringProxy; love it, but I have a security concern with the token authentication method to access the web UI. This might be an edge case, but would like to start discussion on this while the project is still in beta.

Currently all user/client authentication is done via the tokens generated via the Web UI. If I create a new User it generates a token for that user. This token can then be used to access the Web UI for that User as well as connect clients to the server. It is also possible to generate secondary tokens and from what I can see these tokens have the same access level as the original token, please correct me if I am wrong.

Lets say for instance, I set up a number of clients each using the same or different tokens, but linked to the same user. If any of these devices gets compromised, the token for the user is exposed and access can be gained to the Web UI for the user. From there, tunnels can be added and removed for all client instances connected to the user.

I think that secondary tokens should not give full access to the user’s account in the Web UI. Or alternatively there needs to be a separate password to authenticate users for the Web UI. The use of tokens makes the project easier, but having a single compromised token can put all clients connected to a user at risk.

It might be stated that client devices should not be compromised or that if this happens this is a larger issue than BoringProxy, but as a example: lets say I have a Pi(s) running boringproxy installed at a remote location(s). It’s connected to the same user as my other clients, but since this is connected to a external network, my Pi(s) can be compromised since the token is stored in plaintext on the Pi SDCard. If this happens, it can give an attacker the token needed to access my user account on the Web UI.

Creating separate user accounts for each device can work, but then you lose the ability to manage everything from a single user account. If the project expands and its used on large scale in commercial applications, you will run into the problem where creating multiple users is a headache.

For this reason I think a primary and secondary token method should be investigated. I am not a Go developer, therefore I don’t know the complexity of implementing something like this. Would love to hear feedback from the community.

If anything is unclear, please let me know and I will try to explain. If I missed something important that makes this irrelevant, please also let me know

1 Like
2

Hey @WGrobler, this is a great point. I definitely designed the system with simplicity in mind, but security isn’t something you can afford to oversimplify.

I’m currently in the process of designing an open tunneling protocol. You can read about it here.

The goal is to have a protocol that can be implemented by TakingNames.io so I can integrate it into my open source apps and sell tunnels to those who want the simplest possible option, but I would also implement it in boringproxy so people can use my apps with self-hosted tunnels if they prefer.

This protocol will work over OAuth2. In order to make that work in boringproxy, I’ll almost certainly need a new token management system. I could imagine dropping the current token system and moving to an OAuth2-only setup.

Do you think that would solve your concerns? Do you think we need to keep the old way (but make it more secure) in addition to offering OAuth2?

3

I think it will depend on the way you implement OAuth2. I don’t think the token management system is flawed in the way its used to open the tunnel. There will always be a token/key/password used on the client side to connect to the tunnel. When this token is used in combination with a service running on the client machine, you will end up with at token stored in plain text, anything else will require user input every time it needs to connect. This token can then be obtained if anyone has access to the client machine.

The issue for me is the fact that the same token is used to connect the client and access the admin web UI. If a separate token/password is used to authenticate the admin web UI access, the concern I am taking about will be eliminated.

If you use OAuth2 to generate tokens and the same token (that is stored on the client machine) can be used to access the admin web UI, nothing will be different than the current implementation. But, if you generate separate tokens for clients and web UI, it will resolve the issue I am referring to.

I will have to take some time to properly read the open tunnel protocol, seems like a good idea. I haven’t looked into your TakingNames.io, think its useful for someone who knows little about domains and setting up DNS, its a good idea.

4

Yeah, OAuth2 would definitely only be used for client tokens. Either way I agree we need to add some level of scoping to tokens to address the issues you’ve brought up.

I’ve created an issue to track this here:

https://github.com/boringproxy/boringproxy/issues/141

5

Latest conversations here and next to the code repository have led to many improvements in the code base which respect the rationales above, and caused a new release v0.9.0.

It was also influenced by thoughts in Rereading Documentation: Client arguments largely redundant? - #4 by yala