Files
@ f629e9a0c376
Branch filter:
Location: kallithea/docs/usage/debugging.rst - annotation
f629e9a0c376
1.2 KiB
text/prs.fallenstein.rst
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.
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.
4d076981a7b1 4d076981a7b1 4d076981a7b1 e73a69cb98dc 4d076981a7b1 4d076981a7b1 4e6dfdb3fa01 4e6dfdb3fa01 4d076981a7b1 4e6dfdb3fa01 4d076981a7b1 fbbe80e3322b 03bbd33bc084 4d076981a7b1 4d076981a7b1 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 097327aaf2ad 4d076981a7b1 4d076981a7b1 03bbd33bc084 4d076981a7b1 4d076981a7b1 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 | .. _debugging:
===================
Debugging Kallithea
===================
If you encounter problems with Kallithea, here are some instructions
on how to debug them.
.. note:: First make sure you're using the latest version available.
Enable detailed debug
---------------------
Kallithea uses the standard Python ``logging`` module to log its output.
By default only loggers with ``INFO`` level are displayed. To enable full output
change ``level = DEBUG`` for all logging handlers in the currently used .ini file.
This change will allow you to see much more detailed output in the log file or
console. This generally helps a lot to track issues.
Enable interactive debug mode
-----------------------------
To enable interactive debug mode simply comment out ``set debug = false`` in
the .ini file. This will trigger an interactive debugger each time
there is an error in the browser, or send a http link if an error occured in the backend. This
is a great tool for fast debugging as you get a handy Python console right
in the web view.
.. warning:: NEVER ENABLE THIS ON PRODUCTION! The interactive console
can be a serious security threat to your system.
|