Before I go into your points here, I’d like to say that while I understand the idea where if you don’t know what might happen doesn’t mean you shouldn’t be concerned… I also have to point out that you’re free to go into the code, or even ask here, on what Discourse tracks and why. Calling Discourse spyware or viewing as spyware because they track what you’ve read, when you’ve logged in, how often you post, and what is linked back to your posts / what you’ve linked back to other posts… I have yet to hear anyone tell me — even conceptually — where that would go bad for anyone. If you’re that concerned, look at the code for Discourse, it is all there. These guys do a great job of being transparent. There’s a lot to learn here about how the “modern web” (as you call it later) works and most of us here are readily willing to help you out.
On to your points about login methods…
• Browsers should support key derivation from username/password combos.
That isn’t the fault of Discourse, you purported this to be a flaw in Discourse, as far as I know, there are no Browsers that have this capability for built in public key cryptographically generated login credentials.
• Since it’s key derivation, it can take as long as you want, maybe you need some sort of preset for setting up some stuff but w/e it’s just keys at the end of the day. Also, since it’s keys, the other side would be forced to attack your username/password combo (oh hey look, it’s no longer just password), which should be a lot harder than plain old password cracking.
See above, this is not implemented anywhere that I know of.
• Username and password are never sent to servers, only public key. Websites implement display names separate from username, altho I suspect a lot of users would just have them be the same. Anyway, it’s keys, no MITM or server-side hack can break this. With a few extra steps it’s even physically impossible to trick someone into logging into a different service through this mechanism. This pretty much defeats 90% of modern phishing attacks. Maybe more. If only websites would stop with their custom login pages and just use a browser-provided thing. Imagine if phishing attacks had to go an extra length to try and emulate the user’s desktop environment (impossible on linux), browser, etc! A small tweak to how we do logins would eliminate ALMOST ALL PHISHING ATTACKS!
Well, I get the impression that perhaps you would benefit from reading some books but, if you don’t have time for that I highly recommend the Security Now Podcast and there are a multitude of books on the subject. Computer security is an incredibly fascinating but also incredibly complicated field. To be fair, a server-side attack could certainly hack your credentials, once you’re into a server you can pretty much do what you want with the site as you then have access to the source code.
“A Few Extra Steps” also kind of shows how much you might benefit from reading about how complicated the issue of providing identity online truly is. I don’t say that to be mean or insulting, you’re clearly passionate about this subject I highly encourage you to read about it. It may become easier or harder to trick someone into providing login credentials to sites but the human factor will always be the weakest leak. You’re just assuming that this public key credential plan would end most of modern security attacks, which is not really true. The situation would change of course.
Also, a Linux based desktop environment is impossible to emulate? Can you go into more detail over this issue in particular? I’m afraid that I don’t know what you mean by that in this context. Certainly, if I gather what you mean correctly, personal computer logins would benefit from some kind of public key cryptographic requirement; you can get that now in the form of Smart Card based logins, but that would require the technology be implemented on a wider basis than it is.
Again, none of this has anything to do with Discourse, and you original message made it sound like Discourse has a bad login interface.
• Additionally, since you have a whole key-based system with some automated tool access, you can additionally put QR codes on top of it. So if you’re on a device, you can generate a QR code which contains a derived (or even random) key, and the user can scan it on another device and automatically share the login. This would be a huge win for convenience, and using the key mechanism there’s very little to go wrong! Arguably if you already have access to a logged in account, well, you already have access to it! As such, being able to clone that access (especially with a temporary, short-lived key) shouldn’t be a big deal! And ofc this all assumes browser support.
Something like this is done on Keybase, which is an interesting idea. If you want to share logins between devices. Session keys are widely used for this purpose, however, still many less technically savvy users may have issues with it. On computers you could certainly generate a code to share with a mobile but the other way is a bit more problematic or sharing between computers without a mobile device to act as a conduit. Of course being able to clone login credentials defeats the purpose of having public key cryptographic logins, as someone (once they had access from a server side or cross-site attack) they could just copy your login information. This could be mitigated in some ways, the use of OTP’s and the like, but that gets beyond the scope of what you’ve discussed.
• I definitely hate the modern web. We moved away from the ability for users to easily distinguish a phishing page from a legit page, and we’re still using the old flawed system where phishing pages with the same interface as the legit pages allow the attackers to login on the legit pages as you (something that would be impossible with keys, as the keys would be locked down to specific websites - and the phishing websites aren’t the legit websites unless you go as far as DNS hijacking and somehow coming across a valid TLS certificate for it. and good luck with that.). The web is a failure at protecting the users. We still use plaintext passwords in far too many websites. Any properly trained engineer should be capable of looking at this and staying far, far away from anything to do with computers.
Actually this is entirely false and shows your lack of understanding of the “modern web” SSL implementations on browsers have gotten very good at telling people a web site is a potential problem. The problem here is not the technology it is the people. Your disdain for the modern web it really a disdain for people who don’t check things. Anyone can click on the lock symbol in a toolbar and see — Oh… Hey… This company doesn’t match (try it, with Amazon, Google, Apple, etc.) but people don’t. You don’t have to check DNS records, just pay attention to the SSL indicator, make sure it is there and make sure the company matches the certificate. Browsers readily warn if a certificate is invalid and certificates can be made invalid from the issuer relatively easily. Thus a Phishing site whose been caught with an SSL certificate that is using it to con people will be easily discovered and their certificate invalidated by the issuer.
• Seriously, tho. Hacking a forum (i.e. the server) shouldn’t give you access to ppl’s emails. But it does. Phishing pages shouldn’t be possible. But they are. None of this is to blame on the users. Yet we keep blaming the users. “Why did you not check if it was a phishing page?” “Why aren’t you using a password manager?” “Why are you reusing passwords?” well, how about this: “Why are we using a flawed system when there are better systems out there, using modern cryptography, that trivially mitigate all those issues and doesn’t involve changing the user’s workflow at all?” This isn’t about users. It’s not users who are doing it wrong.
Oh well, I think I might’ve gone a little too far with this one. But what I’m really asking for is a rather basic set of security guarantees, which basically boils down to 3 main ones: 1. mitigate phishing attacks 2. mitigate the effects of server-side attacks on login information (hacked servers sending username/password combos to an attacker) 3. mitigate the issues of reusing passwords
I think perhaps you don’t understand what hacking any server, of any kind, does. If you get into the system, you can get anything that server has. Now if you like email notifications, ability to do some kind of password recovery operation, and all that kind of thing; you really have to store emails on the server. This means that if the server is breeched, they can get into it. Period. I can feel your frustration, but if public key cryptography would “trivially mitigate all those issues”, then it would be done already.
To sum up though, the problem with computer security isn’t the technology. It is the people. The problem with people is… People.
I wanted to add one more point I forgot… So these cryptographic key pairs (public and private keys), where would they be stored to make them secure? The server would only get signed data (signed by your private key verified with your public that the server has). However, on your system, how would you keep these secure? How would you keep less informed people from uploading the wrong key? Do you have a key for every site (most secure) but if you do… Where do you keep the keys? Keep them online is insecure, keep them offline is a pain to get them where you need, does every device have its own key for each site? If so, how is that managed? What algorithms would you use? How do you manage killing off all your keys if the device you had them on is stolen?
There are a number of issues.