[squid-users] 2FA with Google Authenticator and squid login

[Amos Jeffries]

On 3/02/25 18:25, NgTech LTD wrote:
> What i was talking about is using both the auth helper and the external 
> ack helper.


Using an ACL helper is just extra complication that is not needed and 
the "Keep It Simple" (KIS) principle of design is very important for 
security systems.


For "global" access you can authorize OR authenticate. Doing "validate + 
authorize + authorize" is pointless for this use-case.

You only need to add authorization on top of authentication (eg user 
login + group access) if you have some non-global resources/area needing 
special authorization that is not granted by just the login.



At the lowest-level of operations:
  * the auth_param helper performs security action "Validate". The 
http_access rules you use to call it perform security action "Authorize".

  * the external ACL helper performs "nothing"[0] as far as Squid is 
concerned. The http_access rules you use to call it perform security 
action "Authorize".

[0] It could actually be doing anything, but Squid cannot know what. In 
particular it does **not** trigger Squid to apply any HTTP 
authentication-related security requirements on the HTTP request/reply 
handling (where the HTTP headers used by auth_param does trigger those) 
- which can potentially be **extremely** dangerous.



> The password is static but the authorization itself is done via some 
> push or another totp method that will authorize the login for a specific 
> amount of time.


Sure. But you do not need an external ACL for that.

In my earlier suggested design the altered ERR_* page has a HTML form 
for POST'ing the 2FA token somewhere directly from the clients Browser 
to a server. That other service is what grants the "Valid" status to 
complete the 2FA login.


**IF** that POST goes through Squid it should use an unrelated TCP 
connection and/or HTTPS security - so there is no way for Squid or any 
other service than your auth server to know which previous client login 
it applies to.



> And indeed it will kind of degrade the connection to 1fa for a period of 
> time, but, it will protect against couple specific attacks.
> So, if the proxy connection is encrypted inside a tunnel then it's ok.


To be 2FA by definition the entire process has to happen over two 
distinct channels, each being used to pass a different token (a.k.a. 
"factor").

case 1: client does not send any user+pass at all:

  channel 1: client -> Squid : (no login)
	  : Squid->client   : 401 login required

  channel 2: auth server -> email : token

  channel 1: client -> Squid : POST username + pass + token
	  : Squid->client   : 200 login confirmed,



case 2: client sends login details, but no 2FA yet:

  channel 1: client -> Squid : HTTP username + pass
	  : Squid->client   : 401 login required

  channel 2: auth server -> email : token

  channel 1: client -> Squid : POST username + pass + token
	  : Squid->client   : 200 login confirmed,


NB: in both cases you could do a 307 redirect back to the original 
requested URL if it is known at that late stage.



> 
> As for a directly accessible proxy over plain http, it will be 
> vulnerable to many auth attacks..

This is not relevant. Any login system faces the same risks of attack 
floods.And the "plain HTTP" is not required. It is only part of this 
discussion because Squid is an HTTP proxy. Thus messages are interpreted 
by Squid as HTTP regardless if they were received as "plain" or HTTPS.


HTH
Amos