auth: secure password reset implementation This is a better implementation of password reset function, which doesn't involve sending a new password to the user's email address in clear text, and at the same time is stateless. The old implementation generated a new password and sent it in clear text to whatever email assigned to the user currently, so that any user, possibly unauthenticated, could request a reset for any username or email. Apart from potential insecurity, this made it possible for anyone to disrupt users' workflow by repeatedly resetting their passwords. The idea behind this implementation is to generate an authentication token which is dependent on the user state at the time before the password change takes place, so the token is one-time and can't be reused, and also to bind the token to the browser session. The token is calculated as SHA1 hash of the following: * user's identifier (number, not a name) * timestamp * hashed user's password * session identifier * per-application secret We use numeric user's identifier, as it's fixed and doesn't change, so renaming users doesn't affect the mechanism. Timestamp is added to make it possible to limit the token's validness (currently hard coded to 24h), and we don't want users to be able to fake that field easily. Hashed user's password is needed to prevent using the token again once the password has been changed. Session identifier is an additional security measure to ensure someone else stealing the token can't use it. Finally, per-application secret is just another way to make it harder for an attacker to guess all values in an attempt to generate a valid token. When the token is generated, an anonymous user is directed to a confirmation page where the timestamp and the usernames are already preloaded, so the user needs to specify the token. User can either click the link in the email if it's really them reading it, or to type the token manually. Using the right token in the same session as it was requested directs the user to a password change form, where the user is supposed to specify a new password (twice, of course). Upon completing the form (which is POSTed) the password change happens and a notification mail is sent. The test is updated to test the basic functionality with a bad and a good token, but it doesn't (yet) cover all code paths. The original work from Andrew has been thorougly reviewed and heavily modified by Søren Løvborg.

include           Apache-License-2.0.txt
include           CONTRIBUTORS
include           COPYING
include           LICENSE-MERGELY.html
include           LICENSE.md
include           MIT-Permissive-License.txt
include           README.rst
include           development.ini
recursive-include docs *
recursive-include init.d *
include           kallithea/bin/ldap_sync.conf
include           kallithea/bin/template.ini.mako
include           kallithea/config/deployment.ini_tmpl
recursive-include kallithea/i18n *
recursive-include kallithea/lib/dbmigrate *.py_tmpl README migrate.cfg
recursive-include kallithea/public *
recursive-include kallithea/templates *
recursive-include kallithea/tests/fixtures *
recursive-include kallithea/tests/scripts *
include           kallithea/tests/test.ini
include           kallithea/tests/vcs/aconfig