Files
@ f629e9a0c376
Branch filter:
Location: kallithea/init.d/kallithea-daemon-redhat
f629e9a0c376
2.6 KiB
text/plain
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 | #!/bin/sh
########################################
#### THIS IS A REDHAT INIT.D SCRIPT ####
########################################
##################################################
#
# Kallithea server startup script
# Recommended default-startup: 2 3 4 5
# Recommended default-stop: 0 1 6
#
##################################################
APP_NAME="kallithea"
# the location of your app
# since this is a web app, it should go in /var/www
APP_PATH="/var/www/$APP_NAME"
CONF_NAME="production.ini"
# write to wherever the PID should be stored, just ensure
# that the user you run paster as has the appropriate permissions
# same goes for the log file
PID_PATH="/var/run/kallithea/pid"
LOG_PATH="/var/log/kallithea/kallithea.log"
# replace this with the path to the virtual environment you
# made for Kallithea
PYTHON_PATH="/opt/python_virtualenvironments/kallithea-venv"
RUN_AS="kallithea"
DAEMON="$PYTHON_PATH/bin/paster"
DAEMON_OPTS="serve --daemon \
--user=$RUN_AS \
--group=$RUN_AS \
--pid-file=$PID_PATH \
--log-file=$LOG_PATH $APP_PATH/$CONF_NAME"
DESC="kallithea-server"
LOCK_FILE="/var/lock/subsys/$APP_NAME"
# source CentOS init functions
. /etc/init.d/functions
RETVAL=0
remove_pid () {
rm -f ${PID_PATH}
rmdir `dirname ${PID_PATH}`
}
ensure_pid_dir () {
PID_DIR=`dirname ${PID_PATH}`
if [ ! -d ${PID_DIR} ] ; then
mkdir -p ${PID_DIR}
chown -R ${RUN_AS}:${RUN_AS} ${PID_DIR}
chmod 755 ${PID_DIR}
fi
}
start_kallithea () {
ensure_pid_dir
PYTHON_EGG_CACHE="/tmp" daemon --pidfile $PID_PATH \
--user $RUN_AS "$DAEMON $DAEMON_OPTS"
RETVAL=$?
[ $RETVAL -eq 0 ] && touch $LOCK_FILE
return $RETVAL
}
stop_kallithea () {
if [ -e $LOCK_FILE ]; then
killproc -p $PID_PATH
RETVAL=$?
rm -f $LOCK_FILE
rm -f $PID_PATH
else
RETVAL=1
fi
return $RETVAL
}
status_kallithea() {
if [ -e $LOCK_FILE ]; then
# exit with non-zero to indicate failure
RETVAL=1
else
RETVAL=0
fi
return $RETVAL
}
restart_kallithea () {
stop_kallithea
start_kallithea
RETVAL=$?
}
case "$1" in
start)
echo -n $"Starting $DESC: "
start_kallithea
echo
;;
stop)
echo -n $"Stopping $DESC: "
stop_kallithea
echo
;;
status)
status_kallithea
RETVAL=$?
if [ ! $RETVAL -eq 0 ]; then
echo "Kallithea server is running..."
else
echo "Kallithea server is stopped."
fi
;;
restart)
echo -n $"Restarting $DESC: "
restart_kallithea
echo
;;
*)
echo $"Usage: $0 {start|stop|restart|status}"
RETVAL=1
;;
esac
exit $RETVAL
|