Delete password from memory in AuthenticationManager
Zero out the password to remove it from memory after use.
This is only a first step, implementing it for one method:
`AuthenticationManager.authenticate(String, char[], String)`.
The upgrade of a MD5 stored password hash to a PBKDF password hash
destroys the stored password. The has check zeroes out the password that
is tested, so that the new hash is built over the zeroed out value.
This fix prevents that an also adds a check to the test.
Fixes #1335
Integrate the `PasswordHash` class and subclass in the user
and password editing and authentication. Replaces the old code and
the previous `SecurePasswordHashingUtils` class.
Mark the user authentication cookie to be only used for HTTP, making
it inaccessible for JavaScript engines.
If only HTTPS is used and no HTTP (i.e. also if HTTP is redirected to
HTTPS) then mark the user cookie to be sent only over secure connections.
Lower log level of servlet authenticate when request is already authenticated
When calling a servlet which has already been authenticated, the server would produce
a lot of superfluous log entries, e.g:
Called servlet authenticate when request is already authenticated.
The log level for this log entry has been lowered down to DEBUG.
Fix authentication failure warning log messages for FEDERATION_USER
The AuthenticationManager did not encounter for FEDERATION_USER and would unnecessarily
generate a lot of failure warning log messages, e.g:
Failed login attempt for $gitblit, invalid credentials from XXX.XX.XX.XX
A simple condition will prematurely return null bypassing the regular authentication path
and immediately make the authentication be routed via FederationManager.
Handle ssh keys as objects, not strings, and improve the ls and rm key commands
"gitblit keys ls" now defaults to showing an indexed list of fingerprints which almost matches the output of "sshadd -l". The indexes are useful specifying key(s) to remove using "gitblit keys rm <index>". This is an important improvement for key management.
issue-361: Reset user cookie after administrative password change
Cookies were not reset on administrative password change of a user
account. This allowed accounts with changed passwords to continue
authenticating. Cookies are now reset on password changes, they are
validated on each page request, AND they will now expire 7 days after
generation.
Florian Zschocke
Florian Zschocke
Martin Spielmann
Dariusz Bywalec
Joel Johnson
Paul Martin
Joel Johnson
Fabrice Bacchella
James Moger
David Ostrovsky