So my current understanding of this is that he’s telling us, as consumers, not to worry because subscriptions are not taking over the industry like the industry wants it to. It’s working for them, but it’s not taking over.
Ok…someone help me out here, because I must be reading this wrong.
In the first tweet, Mat says “the idea that subs will become dominant is unsupported by data.” Ok, so subs are not helping the industry.
But then in the second tweet, he says “Subs have been more additive than cannibalistic”–so wait, they’re actually good for the industry?–and they offer more choice, and fearmongering is unnecessary?
Yeah, computers have a lot more bells and whistles now, but the basics of how the system and the OS work haven’t really changed that much, until you get out of native apps and into Electron and stuff. It’s honestly remarkable how similar they are. Microsoft has a bunch of documentation about weird and quirky behavior they keep available for backwards compatibility, and most modern software developers take them up on that offer.
“Greg Hastings’ Tournament Paintball Max’D” for the PS2. It had no right being as fun as it was, and it sure wasn’t polished, but it was a fun little title. My roommate and I played it off and on for a couple years.
I’m not really sure how it opens up replay attacks
Put simply, jt allows an attacker with a leaked database to use the hashed password as a password. In your original comment, it seemed like you were suggesting hashing only before transmission, on the client; but hashing both before and after would indeed patch that particular vulnerability. I don’t know if there are potential problems with that strategy or not.
another approach of client side decryption is to handle decryption completely client site
Here’s potentially an opportunity for me to learn: how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? Since you can’t count on a web browser to have the private key, do you send down an encrypted private key that can only be decrypted with the user’s password? Is there some other way to do this that I’m not aware of?
This opens up the possibility of replay attacks in the case of data breaches, though, and those are much more common than http mitm attacks (made even less likely with the proliferation of https).
I’m not entirely sure whether hashing twice (local and server) is wise, having not thought through that entire threat vector. Generally I try to offload auth as much as I can to some sort of oauth provider, and hopefully they’ll all switch over to webauthn soon anyway.