Secure Link Expires - URL Signing

[Richard Stanway]

Only the server should be generating the tokens, if the client knows the
secret it can do whatever it wants.

On Wed, Jan 10, 2018 at 10:32 AM, anish10dec <nginx-forum at forum.nginx.org>
wrote:

> Let me explain the complete implementation methodology and problem
> statement
>
> URL to be protected
> http://site.media.com/mediafiles/movie.m3u8
>
> We are generating token on application/client side to send it along with
> request so that content is delivered by server only to authorized apps.
>
> Token Generation Methodology on App/Client
>
> expire = Current Epoch Time on App/Client + 600 ( 600 so that URL will be
> valid for 10 mins)
> uri = mediafiles/movie.m3u8
> secret = secretkey
>
> On Client , MD5 Function is used to generate token by using three above
> defined values
> token = MD5 Hash ( secret, uri, expire)
>
> Client passes generated token along with expiry time with URL
> http://site.media.com/mediafiles/movie.m3u8?token={generated
> value}&expire={value in variable expire}
>
>
> Token Validation on Server
> Token and Expire is captured and passed through secure link module
>
> location / {
>
> secure_link $arg_token,$arg_expire;
> secure_link_md5  "secretkey$uri$arg_expire";
>
> //If token generated here matches with token passed in request , content is
> delivered
> if ($secure_link = "") {return 405;}  // token doesn't match
>
> if ($secure_link = "0") {return 410;}
> //If value in arg_expire time is greater current epoch time of server ,
> content is delivered .
> Since arg_expire has epoch time of device + 600 sec so on server it will be
> success. If someone tries to access the content using same URL after 600
> sec
> , time on server will be greater than time send in arg_expire and thus
> request will be denied.
>
>
> Problem Statement
> Someone changes the time on his client device to say some future date and
> time. In this case same app will generate the token with above mention
> methodolgy on client and send it along with request to server.
> Server will generate the token at its end using all the values along with
> expire time send in URL request ( note here expire time is generated using
> future date on device)
> So token will match and 1st check will be successful .
> In 2nd check since arg_expire has epoch time of future date + 600 sec which
> will be obviously greater than current epcoh time of server and  request
> will be successfully delivered.
> Anyone can use same token and extended epoch time with request for that
> period of time for which future date was set on device.
>
> Hopefully now its explainatory .
> Please let know if there is a way to protect the content in this scenario.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,278063,278088#msg-278088
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180110/cb5a4c7f/attachment.html>