gin.BasicAuth susceptible to Timing Oracle Attack

[atif1996]

Description

When using gin.BasicAuth to secure a website with only one admin user, the implementation is susceptible to a Timing Oracle Attack. Such an attack would brute force the password using a dictionary attack, noting that when more characters of the password are properly matched, the call will take longer. With this scheme each character of the password can be determined given enough time.

Additionally since the application contains the password in plain text, if a intruder is able to make it onto the server, he can use the linux strings command on the binary to yield the stored passwords. This would mean any intrusion into your server would be a reportable event to regulatory agencies.

How to reproduce

Please see here for details on the attack: https://en.wikipedia.org/wiki/Timing_attack

Expectations

1. The code shouldn't require the developer to enter a plain text password to begin with. Would be better if the the user entered hashed + salted password to begin with. See linkedin hack for rationale: https://en.wikipedia.org/wiki/2012_LinkedIn_hack
2. For Password comparison, it's best practice to hash or bcrypt the strings prior to comparison to randomize the response time. Alternatively one could force a rune by rune comparison that always takes constant time (https://golang.org/src/crypto/subtle/constant_time.go).

[buildscientist]

@atif1996
I agree that this is certainly an issue but this is a given with how Basic Auth is defined.

The basic auth spec (RFC 7617) even states it's not a "secure method of user authentication" and doesn't mention anything about hashing/encrypting credentials.

From Gin Gonic's perspective it's really up to the developer to understand that basic auth isn't a viable authentication scheme. It might be better to add documentation in the README that states something along these lines.

[atif1996]

Agreed, basic auth over http is definitely a bad idea.

However basic auth on an application accessed over TLS can be pretty secure and is used on a fair number of web applications. OAuth2 client credentials grant for example trades client_id and client_secret over a basic auth in exchange for a access_token.

The problem I'm pointing out is that the password is compared directly. This makes it possible to do a timing oracle attack the server. The solution is to use a constant_time comparison function, or hash the fields prior to comparison to randomize the comparison time. That would get you most of the way there in my opinion.

Hashing the password would be a step better, but that only matters once an adversary makes it onto your server.