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 <[email protected]> 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 > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
