If an adversary can send a cookie from the same IP-address, or make it look like it is sending from the IP-address, then the server will try to block the IP-address. It does not have to decrypt a cookie from some other party, it can trick an admin to block the adversary.

Could be I'm wrong, I just looked around, I have not tested this. Actually I hope I'm wrong! ;P

You could probably already do the same attack by forging session cookies. I dont think this change increaseses the risk of this attack scenario.

Or more directly, evil isp could just vandalize from those ips forcing an admin to block them

Also i dont think cookie blocks spread autoblocks (might be wrong) (?)

The attacker would also have to replay an existing block cookie since the cookies have hmac tags on them, they would not be able to simply specify an arbitrary block

@Samwilson: Can you verify whether or not a cookie block creates a new autoblock? In other words, do cookie blocks propagate to new IP addresses or just enforce existing autoblocks?

FWIW, I agree with Bawolff that there are much easier ways for evil ISPs to prevent someone from editing an article (or accessing Wikipedia at all for that matter). If there is a scenario where someone could be maliciously blocked without actually controlling their internet access, that would be a much more relevant security concern.

The session should guard against changed IP-address, if it is not, then it is an implementation error. If it does not guard against this, then it allows cookie theft. Just checked by switching to a mobile hotspot and reloading, and it does not guard against this.

The blocking cookie is different, as it can't guard against changed IP-address, and thus always allows cookie theft.

The cookie for "keep me logged in" has the same problem.

(You can rely on the com channel to guard against cookie theft, if the channel itself can't be replicated or played back.)

In T162096#3153425, @jeblad wrote:

The session should guard against changed IP-address, if it is not, then it is an implementation error. If it does not guard aginst this, then it allows cookie theft. Just checked by switching to a mobile hotspot and reloading, and it does not guard against this.

We have users that change ip address very quickly. It would make it almost impossible to edit for these users if we tied sessions to ips. We rely soley on https to prevent someone from stealing session cookies. I think most other major websites are similar in this regard, although i havent tested them.

I believe the scenarios where an attacker is able to passively monitor an https connection, but is not able to masquerade as the IP address in question, are very few. What sort of attack scenario are you imagining?

This is f***ing unbelievable!

In T162096#3159167, @jeblad wrote:

This is f***ing unbelievable!

And this is unacceptable. If you can't have the conversation civilly you are not welcome to have the conversation here at all. Your concerns have been and are being considered at all levels responsible both in tech and in legal, they are not being ignored. I understand you may not agree with the decisions made but please keep those disagreements civil.

In T162096#3153249, @kaldari wrote:

@Samwilson: Can you verify whether or not a cookie block creates a new autoblock? In other words, do cookie blocks propagate to new IP addresses or just enforce existing autoblocks?

After the block is loaded from the cookie it behaves exactly the same as it would have if the user hadn't changed IP addresses. So, yes, the new IP will be blocked, because it becomes just like the original IP address. It's pretty much the same as if a blocked user stays logged in and changes their IP address (in a way, the block cookie is just another way of maintaining a session).

@jeblad: If you have a specific attack scenario in mind that does not involve control of someone's internet access as a pre-requisite, we'll be happy to re-open the ticket. If you're accessing Wikipedia through an evil ISP, there are dozens of different ways your access can be compromised, most of which are more practical and effective than cookie manipulation.

[offtopic] In addition to what JAlexander already wrote, please check the Phabricator etiquette for communication expectations. Thanks!

In T162096#3159167, @jeblad wrote:

This is f***ing unbelievable!

Im sorry you feel that way. In order for the threat you have stated to be a concern, there would have to be an adversary capable of adding cookies to arbitrary users (in an HSTS includeSubdomain world) but weak enough that they cant simply masquarade as someone's IP and directly mass vandalize. I dont believe such adversaries exist. And even if they did, the threat would not be new to this feature.

@jeblad: I tested this out locally to investigate the propagation issue. When a user is blocked from editing due to a block-cookie, it does not create a new block record for the new IP address. In other words, you can always work around a block-cookie by deleting the cookie, as the block does not propagate via cookie blocking. The only time a block propagates is when an autoblocked user tries to edit from a new IP address with a blocked user account. That behavior hasn't changed.