Files
@ f629e9a0c376
Branch filter:
Location: kallithea/CONTRIBUTORS - annotation
f629e9a0c376
3.2 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.
24c0d584ba86 79283d4b1bed 79283d4b1bed 79283d4b1bed 79283d4b1bed 3dbe675b4342 62c4027b0321 c3172bc09503 3dbe675b4342 3dedf3991d40 dc16211e7292 1949ece749ce 1949ece749ce dc16211e7292 a7bee2a5de67 ee2817f2cb3d ee2817f2cb3d fb51a6fc10ae fb51a6fc10ae 3dbe675b4342 c4d8ed624728 9989d727ef1b 9989d727ef1b 31265f80cf8b 31265f80cf8b e61162c20222 02e668af87ac 02e668af87ac b1b31bfe2f99 b1b31bfe2f99 231160230379 c6f16271b60c 12b183c1628b 5f08551afb31 0c1c17db467c 53e5f01081ac c71e05076359 d8364b7e3451 433d6385b216 8b7294a804a0 8b7294a804a0 231160230379 8b7294a804a0 8b7294a804a0 9a6c224e1f68 8b7294a804a0 8b7294a804a0 231160230379 231160230379 231160230379 231160230379 231160230379 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c ebe8537c5c70 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c 0c4f2c53ea4c a73f98871e2b a73f98871e2b a73f98871e2b a73f98871e2b | List of contributors to Kallithea project:
Marcin Kuźmiński <marcin@python-works.com>
Lukasz Balcerzak <lukaszbalcerzak@gmail.com>
Jason Harris <jason@jasonfharris.com>
Thayne Harbaugh <thayne@fusionio.com>
cejones <>
Thomas Waldmann <tw-public@gmx.de>
Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
Dmitri Kuznetsov <>
Jared Bunting <jared.bunting@peachjean.com>
Steve Romanow <slestak989@gmail.com>
Augosto Hermann <augusto.herrmann@planejamento.gov.br>
Ankit Solanki <ankit.solanki@gmail.com>
Liad Shani <liadff@gmail.com>
Les Peabody <lpeabody@gmail.com>
Jonas Oberschweiber <jonas.oberschweiber@d-velop.de>
Matt Zuba <matt.zuba@goodwillaz.org>
Aras Pranckevicius <aras@unity3d.com>
Tony Bussieres <t.bussieres@gmail.com>
Erwin Kroon <e.kroon@smartmetersolutions.nl>
nansenat16 <nansenat16@null.tw>
Vincent Duvert <vincent@duvert.net>
Takumi IINO <trot.thunder@gmail.com>
Indra Talip <indra.talip@gmail.com>
James Rhodes <jrhodes@redpointsoftware.com.au>
Dominik Ruf <dominikruf@gmail.com>
xpol <xpolife@gmail.com>
Vincent Caron <vcaron@bearstech.com>
Zachary Auclair <zach101@gmail.com>
Stefan Engel <mail@engel-stefan.de>
Andrew Shadura <andrew@shadura.me>
Raoul Thill <raoul.thill@gmail.com>
Philip Jameson <philip.j@hostdime.com>
Mads Kiilerich <madski@unity3d.com>
Dan Sheridan <djs@adelard.com>
Dennis Brakhane <brakhane@googlemail.com>
Simon Lopez <simon.lopez@slopez.org>
Jonathan Sternberg <jonathansternberg@gmail.com>
Grzegorz Rożniecki <xaerxess@gmail.com>
Andrew Kesterson <andrew@aklabs.net>
David A. Sjøen <david.sjoen@westcon.no>
Jelmer Vernooij <jelmer@samba.org>
larikale
SteveCohen
RhodeCode GmbH
Sebastian Kreutzberger <sebastian@rhodecode.com>
thomas <thomas@rhodecode.com>
Bradley M. Kuhn <bkuhn@sfconservancy.org>
Sean Farley <sean.michael.farley@gmail.com>
Martin Vium <martinv@unity3d.com>
Daniel Anderson <daniel@dattrix.com>
Travis Burtrum <android@moparisthebest.com>
Calinou <calinou@opmbx.org>
Christian Oyarzun <oyarzun@gmail.com>
Denis Blanchette <dblanchette@coveo.com>
duanhongyi <duanhongyi@doopai.com>
Henrik Stuart <hg@hstuart.dk>
Ingo von Borstel <kallithea@planetmaker.de>
Jan Heylen <heyleke@gmail.com>
Jim Hague <jim.hague@acm.org>
Joseph Rivera <rivera.d.joseph@gmail.com>
Kazunari Kobayashi <kobanari@nifty.com>
Matt Fellows <kallithea@matt-fellows.me.uk>
Max Roman <max@choloclos.se>
Michael Pohl <michael@mipapo.de>
Michael V. DePalatis <mike@depalatis.net>
Michal Čihař <michal@cihar.com>
Morten Skaaning <mortens@unity3d.com>
Na'Tosha Bard <natosha@unity3d.com>
Nick High <nick@silverchip.org>
Niemand Jedermann <predatorix@web.de>
Peter Vitt <petervitt@web.de>
Sam Jaques <sam.jaques@me.com>
Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Tuux <tuxa@galaxie.eu.org>
Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com>
Kevin Bullock <kbullock@ringworld.org>
Marc Villetard <marc.villetard@gmail.com>
Matthias Zilk <matthias.zilk@gmail.com>
Tim Freund <tim@freunds.net>
|