If you watched my linked video it explained how the entire HTTPS system is compromised, has been compromised many times, and is a threat to actual security due to lack of trust agility.

The server initially does know the user's plaintext password during account creation. This is how the hash is created in the first place. It doesn't trust the user end to hash the password because that's just the same as sending a plaintext password, eh?

I explained the most simplest method so that webdevs could see that........................

There is nothing stopping you from creating a SALT during user account creation. Then you store: salt, HMAC( salt, pass_phrase ) = pass_hash on both ends of the wire.

Rather than store this salt I would propose generation of the salt using a single private userID token that stays on the user's system. let's call it "profile_id".

Now the browser uses this to generate the salt that will be used for the password hashing on user and database end: HMAC( user_name + pass_phrase, domain_name ) = profile_id

Now the user can use a single user name and password to access the entire internet, securely and anonymously. The profile ID is different for every site they visit.

Trust me, there are zero criticisms of my methods that I do not have an answer for which proves how ridiculously easy it is to recognize and implement, and therefore demonstrating that the entirety of all webdevs........................

Now, it could be that no one gives a damn about whether HTTPS is secure or not. In that case why have it as it wrecks havoc with caching systems, and "mixed content" is not secured? Could it be that....................

If you would like to see an implementation using the above techniques with elliptic curve crypto rather than hashes then check out SQRL.

However, rather than send this authentication token back and forth, the final step of SQLR could instead feed it into a cipher suite and it would create secure end to end encryption without requiring a CA system. See, there are people trying to solve the stupidity of the web, but even still most are not going the rest of the way to provide security. I have a theory as to why this is................

Read this https://en.wikipedia.org/wiki/Digest_access_authentication

Then realize, rather than share the proof of knowledge you can use it as the key for the TLS cipher suite and be done.

Ah, but that would mean HTTP would have to know something about TLS -- and that's verboten, but why? Isn't that essential, and don't cookie protocol know about TLS (SSL)? Well, if it's not forbidden for TLS and HTTP to know about each other, then why don't webdevs provide "strong end to end encryption" without any 3rd party required? It's such a simple thing to implement, hell, it's already 99% implmented. Perhaps..................

It's called: Crypto 101.

Seriously. "Proof of Knowledge" is the concept.

TL;DR: Use a proof of knowledge as the key for a cipher. DERP. easybutton.

Already used in thousands of security systems world wide.... not in the web though, because........... webdevs are stupid.

"Hashed Message Authentication Code" - another key term, very very basic crypto method used for decades.

HMAC turns any hash algo into a keying system where two inputs, such as ( NONCE, Passphrase ) = gibberish (in such a way that it's not easy to fuck with, learn more crypto for why this is needed).

You still need a good way to create the account -- to share the initial password. This can be done using Diffie-Hellman key exchange. OR optionally in person, in the mail, over the phone via voice, whatever. This gives you the OPTION to have the key exchanged offline, but TLS CA system removes that option, requiring you to trust a 3rd party for every secure connection. If that sound ridiculous to you, then you'll realize that.................

If I told you, you wouldn't believe me, unless you did some research.

Basically, HTTPS is not secure. It has never been secure, and is a full on farce. It is a system which places a mandatory MITM point of failure into the middle of all "secure" connections. Any single CA gets compromised and they can create certs for every domain on the planet without permission. Your trusted root list in your browser has the fucking Hong Kong Post Office in it. Really? Why the shit should you trust that the Hong Kong Post Office or Iranian root CAs or even USG roots, etc. if you cared about security?

HTTPS is more than just a giant single point of failure. It is a giant VULNERABLE single point of failure aggregated from THOUSANDS of smaller single points of failure and only a single one of them being compromised results in the compromise of security of the entire fucking web. Does that sound far fetched? If so you haven't researched the topic enough. If you believe this, then it must sound ridiculous to you... Diginotar. Nevar Forget.

However, even if webdevs believe HTTPS is secure, then there's no reason not to use plaintext user/pass in secure cookies, except to prevent malware on the end user machine getting a copy of the cookie -- but if there is malware munching on the drive data or scanning RAM of a browser process, then that user is fully compromised anyway, so it's a moot point.

The truth is that most webdevs are just fucking dumb. There, I said it. It doesn't apply to you because you realized this yourself.

There is a solution and it's simple: You have the password already shared with server: User enters password. browser contacts server sends user-ID, gets a NONCE (random gibberish). Browser HMAC's (hashes) the NONCE with the user password. The result is gibberish, and you drop that gibberish into your crypto suite as the key for the connection. The server already knew the users password, it HMAC's the NONCE it generated with the user's password. It drops that gibberish into the crypto suite, it's the same key as the server side. Now the connection continues securely.

The only time you need CA authentication is in the initial account creation. With the above system I mentioned you could go to your bank in person, set a PW, then securely connect to the bank without using the broken HTTPS CA system. With the current CA system, you MUST allow a MITM attack potentially from a compromised trusted CA.

"Authentication" is also 100% bullshit. Oh look, this cert is valid for google.com. Lemme check the trusted root... It says, Verisign. Hmm, is that different than the one they normally use? I dunno." The problem of "are you really who you say you are" has just been moved to "which CA is this site SUPPOSED to be using?" and there is no way to find out easily -- what, check online, on your compromised connection? Puhlease.

How the system above would work, is that the browser would pop up a dialog just like it does when you access the Password Protected secure pages, asking user name and password OUTSIDE THE WEB PAGE. This is important because it prevents phishing attacks where a site appears to be yourbank.com or facebag.com, etc. In fact, the "proof of knowledge" that hashed PW protected HTTP assets use is already in the browser. Rather than send that resultant "proof of knowledge", the server and client could just key the ciphers with that "proof", and done, start talking securely.

The reason why this simple change to HTTPS is not already done is............ webdevs are fucking stupid.

HTTPS should solve that. Any MITM would have to break TLS, and if they're doing that, then nothing sent over the wire is secure...............................................................

This is more about the lack of proper security and audits than whether e voting can be secure.

There's a documentary about where a SIGNED INTEGER is used for a variable to tally votes. When the fuck would you ever need a vote to be negative? On, well that's not supposed to be a problem because the software can only increment data fields read from a memory card.

Ah, but if you have a signed value field then you can pre-load the memory cards with negative vote counts for the candidates you don't like. We know this happened because in some places the vote count for candidates came up negative. The machine / software can only increment the counter... so that means the memcards were hacked. over half the planet's population voted on a few machines and caused an integer roll over to negative (which was also not checked for in the software, BTW).

Hacking Democracy - good documentary, look it up on archive.org.