Re:Gitlab – Static passwords set during OmniAuth-based regis...
by dewey on Friday April 01, 2022 @01:48PM
(#30881090)
> then attempts to bruteforce the password should find “12345678” within an hour
But only if there's no rate limiting or increasing timeouts for wrong passwords which in most cases exists.
Re:Gitlab – Static passwords set during OmniAuth-based regis...
by NavinF on Friday April 01, 2022 @02:00PM
(#30881269)
Right, but you can bypass that in a testing environment.
Re:Gitlab – Static passwords set during OmniAuth-based regis...
by dewey on Friday April 01, 2022 @02:05PM
(#30881341)
Which then opens you up to exactly that class of bugs that also caused this issue. Having test specific code and feature flags and then testing a tweaked version isn't really covering all the cases then.
Just like in this case where a hardcoded password was set to maybe log in through a test based on the naming "test_default".
I think a test like this would also have found the dropbox and macos bugs that let you login to any account by using an empty password:
https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...
https://arstechnica.com/information-technology/2017/11/macos...
Edit: Oh, the password was "123qweQWE!@#000000000". Technically doable with an efficient password cracker that favors common patterns. zxcvbn’s entropy estimate says it will take 10^10.5 guesses. That’s 1 week at 50k/s. That’s a hell of an integration test for most software.
https://lowe.github.io/tryzxcvbn/