Ben Adida is a cryptographer who writes about web security, cryptography mistakes, voting, and engineers' responsibility.
HN commenters cite his explanation of why not to hash secrets, recommending HMAC, and his three kinds of crypto essay.
I think the difference between you and tptacek here is basically about this:
http://benlog.com/2014/01/03/there-are-3-kinds-of-crypto/
Google has done an enormous amount to improve and deploy what Ben Adida called "b2c crypto" -- typically turning it on months to years ahead of its main competitors, and actively supporting work on making it stronger. But they've done almost nothing to encourage the use of "p2p crypto" in Adida's sense, at least not as a product feature.
I support the widespread routine use of p2p crypto, but I think Google deserves credit for what it has done. That includes making b2c crypto "routine" for most products, which does have direct effects on dragnet surveillance.
To put this in short-hand: "We bank online, we buy all sorts of stuff online, why not vote?"
The biggest reason is that banking and other financial transactions have a very different threat model from voting.
In particular, voting requires a secret ballot. In addition to preventing an adversary from learning how you voted, a secret ballot requires you to be unable to prove how you voted, to prevent vote selling and coercion.
So, unlike financial transactions, how you do validation / remediation of failures is very unclear. Ben Adida has a blog post with further thoughts here (https://benlog.com/2007/03/02/on-voting-banking-and-bad-analogies/).
> The only solution to a private internet is to fully embrace cryptography for all our communications.
Mozilla (or at least the Mozilla employee that wrote the OP) does not believe that: http://benlog.com/articles/2012/04/30/encryption-is-not-gravy/
Personally, I think that argument is right. "Complete" encryption has usability tradeoffs many people will refuse to make. And I get that. Emotionally, it frustrates me that I can't store my Google Authenticator key in Google Drive even though I understand exactly why that would break two-factor authentication.
But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :)
Yes you can, if you believe this: http://benlog.com/articles/2008/06/19/dont-hash-secrets/
This is exactly why HMAC is more complicated than just:
hash(message+secret)
How does the server verify that the salt it receives in the second request is the same salt it generated in the first response? Does the server have to retain state?
Also you should maybe read https://benlog.com/2008/06/19/dont-hash-secrets/
It's a commentary on the Comodo hack and the sad state of SSL CAs that led to it: there are too many CAs and their processes are too weak, so what's the harm from one more?
http://benlog.com/articles/2011/03/30/intelligently-designing-trust/