IP restriction for Secure Token

#1

Hi,

It would be great if an IP restriction for Secure Tokens would also be possible. We can see in our logs that there are downloads for our paid content for someone who isn’t logged into for downloading, which can only mean that a customer is sharing links with friends.

If course, let’s not pretend that piracy doesn’t exist, and let’s not pretend he couldn’t just send the files to his friend. But still, you can grab the links from our site, post them in a piracy forum, and then thousands of pirates get free, premium downloads of our paid content if they act before expiration. And since the files are large, expiration is not immediate.

We had an IP restriction when we hosted paid downloads with Amazon, and the lack of this with KeyCDN was a fear that we eventually rationalized. But it appears that it is really a problem.

This should be extremely simple to implement. The IP would just go in the URL, and then MD5 would sign it as usual.

On that note, are you happy with MD5 as a signing algorithm? Isn’t that considered inadequate?

#2

+1

HLS is pretty weak, even with AES-128 encryption.

even if you add tokens, authorized users could just copy the generated playlist with tokens and post it on the net, and your CDN traffic is screwed.

There is a great way to make it harder for authorized users to share directly, that is to add client IP to secure tokens, let’s say, authorized user with IP A requests the playlist, his IP A will be added to the tokens for the playlist and even for encryption keys, so when this user shares the generated playlist with others with different IP, the playlist and the keys will not be accessable, because IP does not match.

there are people trying to post playlist generated with legit subscription to youtube live stream platform, and it simply works. that is just one example of playlist being stolen. if there could be IP restriction added to the secure token for HLS, youtbue’s live streaming servers won’t be able to fetch the playlist at all, because IP does not match.

Hot link protection does not protect much, because people can find the direct playlist link with tokens easily and just share the link on forums.

please consider this feature urgently.

people who are doing live and on demand streaming is a big client for CDN traffic, because they are easily throwing more than thousands of dollars per month for the CDN traffic, if the playlist got stolen easily, it’s gonna be a huge loss for the keycdn customer, at the end of the day, who is gonna pay for the bill of CDN traffic, it’s keycdn customer.

so instead of considering more POPs (you guys have already have enough PoPs), please work on this feature urgently

Thanks

#3

OP here, just a little bit of additional info. Cloudfront already supports this, so this is what we’ve been doing for a few years. There are very few downsides, and this is a very effective way to stopping lazy piracy. We don’t assume we can stop piracy outright, we only want to stop the casual pirate, or the mostly law-abiding citizen.

1.) MultiWAN has problems. But the only customer we ever had problems with was myself when I was on MultiWAN. I finally stopping routing my traffic that way.

2.) Dynamic IPs change, so it’s necessary to factor a page reload into the web design to update the URLs.

There are basically no problems doing this, and it does deter casual piracy by at least forcing people to download the links themselves, and then physically share the data with peers. Simply grabbing links and posting them to a forum is just too easy.

So an IP limit in the Secure Token is very effective.

If you wanted to outdo Cloudfront, you could make it a subnet. When people are on dynamic DNS, they tend to get new IP addresses in the same /16 subnet. So if you allow people to specific the IP limit as a 123.123.x.x/16 subnet, the links will mostly survive a dynamic IP change.