Files
@ f629e9a0c376
Branch filter:
Location: kallithea/LICENSE-MERGELY.html
f629e9a0c376
5.6 KiB
text/html
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 | <!DOCTYPE html>
<html lang="en">
<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<![endif]-->
<head>
<meta charset="utf-8" /><title>Mergely License</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<meta name="description" content="Mergely license requirements for open source software and commercial software" />
<meta name="keywords" content="diff,merge,compare,compare documents,js diff,javascript diff,comparison,online diff,difference,file,text,unix,patch,algorithm,saas,longest common subsequence,diff online" />
<meta name="author" content="Jamie Peabody" />
<meta name="author" content="Jamie Peabody" />
<link rel="shortcut icon" href="http://www.mergely.com/favicon.ico" />
<link href='http://fonts.googleapis.com/css?family=Noto+Sans:400,700' rel='stylesheet' type='text/css' />
<link href='fonts/berlin-sans-fb-demi.css' rel='stylesheet' type='text/css' />
<link href='style/mergely.css' rel='stylesheet' type='text/css' />
<link href='/Mergely/lib/mergely.css' rel='stylesheet' type='text/css' />
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js"></script>
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-85576-5']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
</head>
<body>
<div id="page">
<div id="content">
<div id="header">
<h1><span>Mergely License - Closed Distribution License</span></h1>
<div id="options">
<a href="/editor" class="button">Online Diff</a>
<a href="/download" class="button">Download</a>
</div>
<nav>
<ul>
<li><a href="/">Home</a></li> <li><a href="/doc">Documentation</a></li> <li><a href="/about">About Mergely</a></li> <li><a href="/license">License</a></li> <li><a href="#footer">Contact</a></li> </ul>
</nav>
</div>
<div id="main">
<h1>Mergely License</h1>
<p>
All Mergely code is Copyright 2014 by Jamie Peabody.
Mergely is distributed under the
<a href="http://www.gnu.org/licenses/gpl.html">GPL</a>,
<a href="http://www.gnu.org/licenses/lgpl.html">LGPL</a>
and
<a href="http://www.mozilla.org/MPL/MPL-1.1.html">MPL</a> open source licenses.
This triple <b>copyleft</b> licensing model avoids incompatibility with other open
source licenses. These open source licenses are specially indicated for:
<ul>
<li>Integrating Mergely into Open Source software;</li>
<li>Personal and educational use of Mergely;</li>
<li>
Integrating Mergely in commercial software, taking care of satisfying
the Open Source licenses terms, while not able or interested on supporting
Mergely and its development.
</li>
</ul>
</p>
<h2>Mergely Commercial License - Closed Distribution License - CDL</h2>
<p>
You may contact <a href="mailto:jamie.peabody@gmail.com">Jamie Peabody</a> to enquire about
obtaining a CDL license.
</p>
<p>
This license offers a very flexible way to integrate Mergely in your commercial
application. These are the main advantages it offers over an Open Source license:
</p>
<p>
Modifications and enhancements do not need to be released under an Open
Source license; There is no need to distribute any Open Source license terms
along with your product and no reference to it have to be done; You do not have
to mention any reference to Mergely in your product; Mergely source code does not
have to be distributed with your product; You can remove any file from Mergely
when integrating it with your product.
</p>
<p>
The CDL is a lifetime license valid for all previous releases of Mergely published
prior to the year of purchase, and any releases in the following year. Please select
the license option that best fit your needs above. It includes 1 year of
<b>personal e-mail support</b>.
</p>
<h2>Third party codes</h2>
<p>
Mergely utilizes <b>CodeMirror</b>, a third-party library released under an
<a href="http://en.wikipedia.org/wiki/MIT_License">MIT</a>
license. Also used is <b>jQuery</b> and is released under the
<a href="http://en.wikipedia.org/wiki/MIT_License">MIT</a> or
<a href="http://www.gnu.org/licenses/gpl.html">GPL</a> Version 2 license.
</p>
</div>
<div id="footer">
<a href="/download" class="download">Download</a>
<ul>
<li id="google-plus"><a target="_blank" href="http://groups.google.com/group/mergely">http://groups.google.com/group/mergely</a></li>
<li id="github"><a target="_blank" href="https://github.com/wickedest/Mergely">https://github.com/wickedest/Mergely</a></li>
<li id="email"><a target="_blank" href="mailto:jamie.peabody@gmail.com">jamie.peabody@gmail.com</a></li>
</ul>
</div>
</div>
<div id="copyright">By <b>Jamie Peabody</b></div>
</div>
</body>
</html>
|