2017-07-16 21:14:03 +02:00
|
|
|
// This reloads the module in development rather than refreshing the page
|
|
|
|
if (module.hot) {
|
|
|
|
module.hot.accept();
|
|
|
|
}
|
|
|
|
|
2017-06-22 22:08:43 +02:00
|
|
|
var common = (function () {
|
2012-10-18 20:29:16 +02:00
|
|
|
|
2017-06-22 22:08:43 +02:00
|
|
|
var exports = {};
|
|
|
|
|
|
|
|
exports.status_classes = 'alert-error alert-success alert-info';
|
|
|
|
|
|
|
|
exports.autofocus = function (selector) {
|
2012-08-29 17:45:15 +02:00
|
|
|
$(function () {
|
2017-07-08 17:43:42 +02:00
|
|
|
$(selector).focus();
|
2012-08-29 17:45:15 +02:00
|
|
|
});
|
2017-06-22 22:08:43 +02:00
|
|
|
};
|
2013-04-03 22:30:36 +02:00
|
|
|
|
2013-04-08 20:21:20 +02:00
|
|
|
// Return a boolean indicating whether the password is acceptable.
|
|
|
|
// Also updates a Bootstrap progress bar control (a jQuery object)
|
|
|
|
// if provided.
|
2013-04-03 22:30:36 +02:00
|
|
|
//
|
|
|
|
// Assumes that zxcvbn.js has been loaded.
|
|
|
|
//
|
|
|
|
// This is in common.js because we want to use it from the signup page
|
|
|
|
// and also from the in-app password change interface.
|
2017-06-22 22:08:43 +02:00
|
|
|
exports.password_quality = function (password, bar, password_field) {
|
2013-04-04 00:55:36 +02:00
|
|
|
// We load zxcvbn.js asynchronously, so the variable might not be set.
|
2013-08-01 17:47:48 +02:00
|
|
|
if (typeof zxcvbn === 'undefined') {
|
2013-04-04 00:55:36 +02:00
|
|
|
return undefined;
|
2013-08-01 17:47:48 +02:00
|
|
|
}
|
2013-04-04 00:55:36 +02:00
|
|
|
|
2017-07-06 22:51:57 +02:00
|
|
|
var min_length = password_field.data('minLength');
|
passwords: Express the quality threshold as guesses required.
The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
2017-10-03 19:48:06 +02:00
|
|
|
var min_guesses = password_field.data('minGuesses');
|
2017-01-09 18:04:23 +01:00
|
|
|
|
2017-10-03 19:52:38 +02:00
|
|
|
var result = zxcvbn(password);
|
|
|
|
var acceptable = (password.length >= min_length
|
passwords: Express the quality threshold as guesses required.
The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
2017-10-03 19:48:06 +02:00
|
|
|
&& result.guesses >= min_guesses);
|
2017-01-09 18:04:23 +01:00
|
|
|
|
|
|
|
if (bar !== undefined) {
|
passwords: Express the quality threshold as guesses required.
The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
2017-10-03 19:48:06 +02:00
|
|
|
var t = result.crack_times_seconds.offline_slow_hashing_1e4_per_second;
|
|
|
|
var bar_progress = Math.min(1, Math.log(1 + t) / 22);
|
2017-10-03 19:52:38 +02:00
|
|
|
|
|
|
|
// Even if zxcvbn loves your short password, the bar should be
|
|
|
|
// filled at most 1/3 of the way, because we won't accept it.
|
|
|
|
if (!acceptable) {
|
|
|
|
bar_progress = Math.min(bar_progress, 0.33);
|
|
|
|
}
|
|
|
|
|
|
|
|
// The bar bottoms out at 10% so there's always something
|
2013-04-08 20:21:20 +02:00
|
|
|
// for the user to see.
|
2017-10-03 19:52:38 +02:00
|
|
|
bar.width(((90 * bar_progress) + 10) + '%')
|
2013-04-08 20:31:00 +02:00
|
|
|
.removeClass('bar-success bar-danger')
|
|
|
|
.addClass(acceptable ? 'bar-success' : 'bar-danger');
|
2013-04-08 20:21:20 +02:00
|
|
|
}
|
2013-04-03 22:30:36 +02:00
|
|
|
|
2013-04-08 20:31:00 +02:00
|
|
|
return acceptable;
|
2017-06-22 22:08:43 +02:00
|
|
|
};
|
|
|
|
|
2017-06-29 16:26:48 +02:00
|
|
|
exports.password_warning = function (password, password_field) {
|
|
|
|
if (typeof zxcvbn === 'undefined') {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
2017-07-06 22:51:57 +02:00
|
|
|
var min_length = password_field.data('minLength');
|
2017-06-29 16:26:48 +02:00
|
|
|
|
|
|
|
if (password.length < min_length) {
|
|
|
|
return i18n.t('Password should be at least __length__ characters long', {length: min_length});
|
|
|
|
}
|
|
|
|
return zxcvbn(password).feedback.warning || i18n.t("Password is too weak");
|
|
|
|
};
|
|
|
|
|
2017-06-22 22:08:43 +02:00
|
|
|
return exports;
|
|
|
|
|
|
|
|
}());
|
2016-12-04 08:59:56 +01:00
|
|
|
|
|
|
|
if (typeof module !== 'undefined') {
|
2017-06-22 22:08:43 +02:00
|
|
|
module.exports = common;
|
2016-12-04 08:59:56 +01:00
|
|
|
}
|