2020-08-01 03:43:15 +02:00
|
|
|
"use strict";
|
|
|
|
|
2020-11-30 23:46:45 +01:00
|
|
|
const {strict: assert} = require("assert");
|
|
|
|
|
2021-03-11 17:15:31 +01:00
|
|
|
const {set_global, with_field, zrequire} = require("../zjsunit/namespace");
|
2020-12-01 00:39:47 +01:00
|
|
|
const {run_test} = require("../zjsunit/test");
|
2020-12-01 00:02:16 +01:00
|
|
|
|
zjsunit: Remove rewiremock dependency.
We now just use a module._load hook to inject
stubs into our code.
For conversion purposes I temporarily maintain
the API of rewiremock, apart from the enable/disable
pieces, but I will make a better wrapper in an
upcoming commit.
We can detect when rewiremock is called after
zrequire now, and I fix all the violations in
this commit, mostly by using override.
We can also detect when a mock is needlessly
created, and I fix all the violations in this
commit.
The one minor nuisance that this commit introduces
is that you can only stub out modules in the Zulip
source tree, which is now static/js. This should
not really be a problem--there are usually better
techniques to deal with third party depenencies.
In the prior commit I show a typical workaround,
which is to create a one-line wrapper in your
test code. It's often the case that you can simply
use override(), as well.
In passing I kill off `reset_modules`, and I
eliminated the second argument to zrequire,
which dates back to pre-es6 days.
2021-03-06 12:47:54 +01:00
|
|
|
set_global("zxcvbn", require("zxcvbn"));
|
|
|
|
|
2021-02-10 04:53:22 +01:00
|
|
|
const common = zrequire("common");
|
2017-01-09 21:51:22 +01:00
|
|
|
|
2021-03-11 17:15:31 +01:00
|
|
|
function password_field(min_length, min_guesses) {
|
|
|
|
const self = {};
|
|
|
|
|
|
|
|
self.data = (field) => {
|
|
|
|
if (field === "minLength") {
|
|
|
|
return min_length;
|
|
|
|
} else if (field === "minGuesses") {
|
|
|
|
return min_guesses;
|
|
|
|
}
|
|
|
|
throw new Error(`Unknown field ${field}`);
|
|
|
|
};
|
|
|
|
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
run_test("basics w/progress bar", () => {
|
2019-11-02 00:06:25 +01:00
|
|
|
let accepted;
|
|
|
|
let password;
|
|
|
|
let warning;
|
2017-01-09 21:51:22 +01:00
|
|
|
|
2019-11-02 00:06:25 +01:00
|
|
|
const bar = (function () {
|
|
|
|
const self = {};
|
2017-01-09 21:51:22 +01:00
|
|
|
|
2021-02-23 14:37:26 +01:00
|
|
|
self.width = (width) => {
|
2017-01-09 21:51:22 +01:00
|
|
|
self.w = width;
|
|
|
|
return self;
|
|
|
|
};
|
|
|
|
|
2021-02-23 14:37:26 +01:00
|
|
|
self.removeClass = (arg) => {
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(arg, "bar-success bar-danger");
|
2017-01-09 21:51:22 +01:00
|
|
|
return self;
|
|
|
|
};
|
|
|
|
|
2021-02-23 14:37:26 +01:00
|
|
|
self.addClass = (arg) => {
|
2017-01-09 21:51:22 +01:00
|
|
|
self.added_class = arg;
|
|
|
|
return self;
|
|
|
|
};
|
|
|
|
|
|
|
|
return self;
|
2020-07-16 22:35:58 +02:00
|
|
|
})();
|
2017-01-09 21:51:22 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
password = "z!X4@S_&";
|
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
|
|
|
accepted = common.password_quality(password, bar, password_field(10, 80000));
|
2017-01-09 21:51:22 +01:00
|
|
|
assert(!accepted);
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(bar.w, "39.7%");
|
|
|
|
assert.equal(bar.added_class, "bar-danger");
|
2017-06-29 16:26:48 +02:00
|
|
|
warning = common.password_warning(password, password_field(10));
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(warning, "translated: Password should be at least 10 characters long");
|
2017-01-09 21:51:22 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
password = "foo";
|
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
|
|
|
accepted = common.password_quality(password, bar, password_field(2, 200));
|
2017-01-09 21:51:22 +01:00
|
|
|
assert(accepted);
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(bar.w, "10.390277164940581%");
|
|
|
|
assert.equal(bar.added_class, "bar-success");
|
2017-06-29 16:26:48 +02:00
|
|
|
warning = common.password_warning(password, password_field(2));
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(warning, "translated: Password is too weak");
|
2017-05-23 00:53:53 +02:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
password = "aaaaaaaa";
|
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
|
|
|
accepted = common.password_quality(password, bar, password_field(6, 1e100));
|
2017-05-23 00:53:53 +02:00
|
|
|
assert(!accepted);
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(bar.added_class, "bar-danger");
|
2017-06-29 16:26:48 +02:00
|
|
|
warning = common.password_warning(password, password_field(6));
|
|
|
|
assert.equal(warning, 'Repeats like "aaa" are easy to guess');
|
2021-03-11 17:15:31 +01:00
|
|
|
});
|
2017-05-23 00:53:53 +02:00
|
|
|
|
2021-03-11 17:15:31 +01:00
|
|
|
run_test("zxcvbn undefined", () => {
|
|
|
|
// According to common.js, we load zxcvbn.js asynchronously, so the
|
|
|
|
// variable might not be set. This just gets line coverage on the
|
|
|
|
// defensive code.
|
|
|
|
|
|
|
|
const password = "aaaaaaaa";
|
|
|
|
const progress_bar = undefined;
|
|
|
|
|
|
|
|
with_field(global, "zxcvbn", undefined, () => {
|
|
|
|
const accepted = common.password_quality(password, progress_bar, password_field(6, 1e100));
|
|
|
|
assert(accepted === undefined);
|
|
|
|
const warning = common.password_warning(password, password_field(6));
|
|
|
|
assert(warning === undefined);
|
|
|
|
});
|
2018-05-15 12:40:07 +02:00
|
|
|
});
|