Contributing on GitHub requires JS and that creates challenges and some are discouraged

[alzer89]

@qubist

I don’t understand your concern. The server will hash the received password and compare it with a local hash. It will not store it as plain text. What makes client-side hashing more secure? And secure from what exactly? (assuming TLS)

Ok, then go ahead and type your password into my website, and we’ll see if my server “stores it as plain text” or not. Go on. Don’t be shy

Where do you think the server gets that “local hash” from in the first place?

Servers will do exactly what they are told, whatever that may be.

I’m sorry, but this caught me off-guard, and I really did not expect “the server will not store the plaintext password that you just voluntarily gave it, because…it just won’t, ok…?”.

I quote from your StackExchange link:

This answer isn’t really right. It highlights the vulnerability of a naïve approach to client-side hashing. It is certainly true that if the server does no hashing at all and just stores the value that the client sends, this would be no better than storing plaintext passwords. But the simple solution is to hash at both the client and the server. And with this simple solution in place we gain one significant advantage: the cost of resource-intensive password hashing can be shifted from the server to the client, and likely cranked up further than the server might be able to support.

• The client does it’s own hashing/ecrypting/signing of “whatever is entered in the text box” to ensure that it’s in a specific format while in transit
  • If it’s intercepted in transit, even if TLS/HTTPS is poorly implemented/broken/spoofed/hijacked, that means the snoopers have something “less useful/reversible” than a plaintext password
• When it reaches the server, the server hashes it again (with the same method, or a different one), and stores that instead of the plaintext password
  • The server never ever gets the plaintext password, because it starts off with a hash anyway
  • The network infrastructure, even if HTTPS is broken, never gets a plaintext password
  • If the server is breached for whatever reason (physical seizure, remote exploit, curious/bored sysadmin, they sold the hardware and “forgot to wipe the drives”, who knows…), then all they will see is the double-hashed values

Surely you’d agree that there’s a valid reason for doing it this way, at least over blindly sending a server a plaintext password, with no guarantee that they “didn’t store in plaintext”…

@qubist

How is instruction on how to get, install and use an OS not sensitive information? How does the visitor know what site he deals with? Suppose a rogue page tricks a random visitor to enter sensitive info, still claiming the connection is HTTPS. - He won’t know it, you know it. What is even worse - Cloudflare fingerprints users.

Those are all valid points. What would you suggest to rectify/mitigate them?

Potentially a signing key on some sort of distributed blockchain, making the website non-fungible, maybe?

@qubist

Unfortunately that chance is very small, as I am overloaded with lots of stuff. I may try if I find some time but can’t promise when.

It would nice after all this complaining in this thread, we could all be part of the solution. Hopefully some free time comes up so you can try and throw Sourcehut inside a VM and try it out