> The password list to check against is at worst a few megabytes.
People stuck on a slow mobile network would tend to disagree.
> Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data.
The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims.
> If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model.
That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden. If users don't like the idea of sending passwords to a remote server, they should request that the service implements a two-factor authentication solution instead.
People stuck on a slow mobile network would tend to disagree.
That is picking my comment out of context. Fortunately we don't change passwords all that often. But that was not my point - rather that we already accept so much JS bloat on the web, that doing the same for password change is no different except it provides some actual benefit.
The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims.
Not true. Zero-knowledge proofs can prove that "This hash comes from a password that meets all requirements", without providing the password to the server, yet it knows that it is good.
That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden.
Not at all. This is security best practice; lock things down as much as you can, and only open up for attack vectors when you have to.
People stuck on a slow mobile network would tend to disagree.
> Besides we already know how to encrypt such that I can send an encrypted password to you, where you can, without knowing the key, can verify simple claims about the data.
The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims.
> If we accept your thesis that we must send the password to the server upon changing it, we could still use client side hashing for a marginally improved security model.
That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden. If users don't like the idea of sending passwords to a remote server, they should request that the service implements a two-factor authentication solution instead.