zxcvbn VS WHATWG HTML Standard

Lightweight is an understatement here.

A client's project (with not necessarily technical customers) has had pretty reasonable success using the Dropbox originated library[1] for this, `zxcvbn`[2], on both frontend via js (for "instant" feedback) and on the backend via php (to enforce the requirements when writing password hashes to the database)

1: https://dropbox.tech/security/zxcvbn-realistic-password-stre...

2: https://github.com/dropbox/zxcvbn

use zxcvbn to check your password strength more thoroughly

source if anyone wants the whole list https://github.com/dropbox/zxcvbn/blob/master/data/passwords.txt

Password strength is evaluated based on the zxcvbn library.

In contrast, let's consider the password "zxcvbn214". How might we assign an entropy to this password? Is it 369? Or 266 * 103? Anyone familiar with a QWERTY keyboard or Dropbox's password strength estimator knows that "zxcvbn" is hardly a random sequence of letters. This same principle applies to "l33t" speak, e.g. replacing all "e"s with 3s and "a"s with 4s. These strategies may "trick" simple entropy calculations into estimating a high entropy, but it won't trick sophisticated attackers. This leads to strength over-estimation, which is, I argue, the worst thing we can do in this context.

> except for ZXCVBN

You mean the Low-Budget Password Strength Estimator?

https://github.com/dropbox/zxcvbn

Yeah, that name is totally legit.

For any part of the password that the zxcvbn cannot match to a known pattern, it uses a brute-force cardinality of 10, i.e., it estimates that the number of guesses required to crack a password or password segment of length N is equal to 10N (equivalent to the number of guesses required to exhaust all possibilities if your password consisted only of numbers).

We took a similar approach to passphrase stretching in EnvKey[1] v1 (EnvKey is a secrets manager, not a passwords manager, but uses end-to-end encryption in a similar way). We used PBKDF2 with iterations set a bit higher than the currently recommended levels, as well as Dropbox's zxcvbn lib to try to identify and block weak passphrases.

Ultimately, I think it's just not good enough. Even if you're updating iteration counts automatically (which is clearly not a safe assumption, and to be fair not something we did in EnvKey v1 either), and even with safeguards against weak passphrases, using human-generated passphrases as a single line of defense is just fundamentally weak.

That's why in EnvKey v2, we switched to primarily using high entropy device-based keys--a lot like SSH private keys, except that on Mac and Windows the keys get stored in the OS keychain rather than in the file system. Also like SSH, a passphrases can optionally be added on top.

The downside (or upside, depending how you look at it) is that new devices must be specifically granted access. You can't just log in and decrypt on a new device with only your passphrase. But the security is much stronger, and you also avoid all this song and dance around key stretching iterations.

1 - https://github.com/envkey/envkey

2 - https://github.com/dropbox/zxcvbn

WHAT-WG HTML

There's a long-standing WHATWG feature request open for it here: https://github.com/whatwg/html/issues/2791

And several userland custom element implementation, like https://www.npmjs.com/package//html-include-element

One of the cool things that you can do with client-side includes and shadow DOM is render the included HTML into a shadow root that has s, so that the child content of the include element is slotted into a shell implemented by the included HTML.

This lets you do things like have the main page be the pre-page content and the included HTML be a heavily cached site-wide shell, and then another per-user include with personalized HTML - all cached appropriately.

The `allow` attribute on iframes is a relatively recent API addition from 2017

https://github.com/whatwg/html/pull/3287

I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.

I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791

And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element

Then HTML could support these elements being targets of links.

> Consider https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/

I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get

to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For

, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373