Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gin.BasicAuth timing attack not properly fixed #3168

Open
jerbob92 opened this issue May 31, 2022 · 3 comments
Open

gin.BasicAuth timing attack not properly fixed #3168

jerbob92 opened this issue May 31, 2022 · 3 comments

Comments

@jerbob92
Copy link

Description

In #2226 and #2609 a fix was discussed and made to prevent timing attacks on the basic auth logic of Gin. However, this was only partly fixed. The decision was made to use subtle.ConstantTimeCompare, however, that has quite a big flaw that it immediately returns when the length of the 2 strings is not equal, which still allows it to be used for timing attacks to guess how long the password should be.

There are basically 2 ways to fix this:

  1. Hash both strings so that they are of equal length
  2. Pad the shortest string so that they are of equal length

In a personal project I decided to go for option 2, which looks like this:

// ConstantTimeCompareString forces both strings to the same length,
// because subtle.ConstantTimeCompare will return 0 early if the strings are
// not of equal length, which could leak the required string length.
func ConstantTimeCompareString(x, y string) bool {
	maxLength := len(x)
	if len(y) > maxLength {
		maxLength = len(y)
	}

	x = fmt.Sprintf("%*s", maxLength, x)
	y = fmt.Sprintf("%*s", maxLength, y)

	if subtle.ConstantTimeCompare([]byte(x), []byte(y)) == 1 {
		return true
	}

	return false
}
@jerbob92
Copy link
Author

jerbob92 commented Jun 2, 2022

I'm just wondering now if the padding loop in Sprintf also might allow for a timing attack. It's probably less vulnerable than subtle.ConstantTimeCompare, but it's still looping for one of the strings to make it equal length.

Maybe hashing is the better way after all?

@icy4ever
Copy link
Contributor

is it a better suggestion to golang crypto package method ConstantTimeCompare?

@jerbob92
Copy link
Author

There have been various discussions about that, for example here: golang/go#18936
It doesn't really look like they want to change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants