I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful.

What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method.

I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.

The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force":

"Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption"

The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so.

The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly":

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers.

And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.

Right, agree with all of that. I would have characterized as "user can shoot themselves on the foot (i.e. by choosing weak password)", rather than "easy to bruteforce"

It's a perspective difference.

Each individual user perspective: "It is possible I can shoot myself in the foot, and also possible I will not. It is not correct to say I will shoot myself in the foot.".

Outside observer perspective: "Empirically, many users shoot themselves in the foot using this system. It is correct to say this system does not make feet safe".

It might be phrased better in terms of safety than security? The safety of the system is left up to the users, and is - to the best of our knowledge - not safe to use _as is_ by most people.

But users choosing a weak password on a standard rate limited service login is significantly different to choosing a poor password in something that the attacker has unlimited, low latency and undetectable attempts against.

I agree with the point about unlimited and undetectable. I think there's nuance to low latency.

Here the latency the attacker is limited by the amount of parallelism they can bring to bear on e.g. PBKDF. Ultimately this is an economic consideration about the cost to protect a secret vs cost to crack it.

> The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous.

Don’t delude yourself. These phishing pages with mirrored login portals happen to podunk organizations all of the time.

If someone manages to get a link to your page and is interesting in the contents, duping it and sending a phishing link to the suspected password holder is a trivial spear phishing attack (with an annoyingly high success rate).

mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.