search

TheGU / mod-auth-token

This module uses token based authentication to secure downloads and prevent deep-linking. Have your script or servlet generate a token to authenticate the download and let Apache handle the file transfer without having to pipe it through a script for security.
Apache License 2.0
0 stars 0 forks source link

Authorize download restricted to an identified client #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hello,

I need the feature to authorize specific clients (at the moment only iphones). 
I suggest to extend 
your mod-auth-token to retrieve a client-identification (iphone: UDID) which is 
also used to 
generate/check the token:

/downloads/UDID/dee0ed6174a894113d5e8f6c98f0e92b/43eaf9c5/file_to_protect.txt

To do this is pretty easy and I would like to provide this extension back to 
the project. So my 
questions are:

- Do you like the extension?
- Is the suggested way proper?
- Should I extend the project or do you prefer to do it by yourself?
- Any suggestions in general?

Thanks,
Stephan

Original issue reported on code.google.com by iphone.h...@gmail.com on 4 Jun 2010 at 7:21

GoogleCodeExporter commented 9 years ago 
Sorry to mark it as "Type-Defect" but I didn't know how to change.

Original comment by iphone.h...@gmail.com on 4 Jun 2010 at 7:22

GoogleCodeExporter commented 9 years ago 
If you want to secure a specific directory / file for a specific UDID, you 
could use
the udid as secret, and you are done.

If the UDID is part of the path of the requested file, than it is part of the
signature anyway. 

In any other usecase I do not see how adding and ID from the callers side will 
add
any security? Unless you want the module to do a database request to check the 
UDID.
Because the mod can not guarantee, that the given UDID is really from the device
initiating this request. If the device knows the secret, it can verify any 
link.

Original comment by oli9...@gmail.com on 4 Jun 2010 at 2:53

GoogleCodeExporter commented 9 years ago 
I'm sorry it seems I did not make by point clear enough:

Same procedere as you did with the client's IP address! The UDID is added to 
the plain text which is the 
base for building the token. In case of the IP address this is given by the 
connection information but in 
case of UDID it is transported by a virtual directory (as you did with the 
timestamp). In this way the 
access can be permitted to every file for a specific client identified by any 
id (in my case the iPhone's 
UDID).

Do you now know what I am thinking of?

Stephan

Original comment by iphone.h...@gmail.com on 4 Jun 2010 at 3:39

GoogleCodeExporter commented 9 years ago 
I do not understand, the UDID depends on the iphone being used and can't be 
retrieved by network (if i'm not wrong, an app must generate the link), so 
basically, you want to have a pattern to detect if the connection comes from an 
iphone ?

Since we can't retrieve the UDID  by network (in a header for example) , we 
can't trust the client. Anyone could fake it. Remember to never trust the 
client.

Original comment by teixeira...@gmail.com on 23 Jun 2010 at 7:53

GoogleCodeExporter commented 9 years ago

Original comment by teixeira...@gmail.com on 23 Jun 2010 at 7:53

GoogleCodeExporter commented 9 years ago 
>Since we can't retrieve the UDID  by network (in a header for example) , we 
can't >trust the client. Anyone could fake it. Remember to never trust the 
client.

This is correct but in our case the token is generated by an app-server (which 
talks to the client) an the request is made by the iphone.

so procedure is:

1. client says hello (by udid) to the app-server any day before we need it
2. client wants to download informations yet, so app-server generates the token 
and
   submits the url-template to the iphone
   http://anyserver.com/downloads/?/dee0ed6174a894113d5e8f6c98f0e92b/43eaf9c5/file_to_protect.txt
3. the iphone calls the url extended by its own udid.
   http://anyserver.com/downloads/udid/dee0ed6174a894113d5e8f6c98f0e92b/43eaf9c5/file_to_protect.txt
4. the mod-auth-token takes the udid and checks the token.

If an url is sniffed and forwarded than the next step would be to use a 
blacklist to deny requests by this udid. Because you need an iphone-device to 
sniff urls the damage caused by such an intrusion is limited.

I known this is not perfect but it prevents me from 95% damage.

Original comment by iphone.h...@gmail.com on 23 Jun 2010 at 1:49

GoogleCodeExporter commented 9 years ago 
Okay, now i do understand, since mobiles phones  access internet by the 
operator proxys (at least in my country) , Limitation by ip does not offer 
enough protection, since the ip would be the same if the sniffer has the same 
operator.

However i don't see how useful would be to have the udid on the url ?
If you have to blacklist udid's , then do it at step 1 (client says hello 
[...]) and deny download for the user session.

I think for this kind of security approach you should use a kind of 
challenge-response scheme because the ecosystem is not the same as internet 
(the client lives on the operator LAN and then is natted by the proxys, and 
that Proxy is shared between undreds of clients.)

Also when I was working in the Telco (orange btw) we used the client MSISDN 
since it is uniq.

Original comment by teixeira...@gmail.com on 29 Jun 2010 at 9:52

GoogleCodeExporter commented 9 years ago 
i'm closing this issue since we don't have news from the reporter.

Original comment by teixeira...@gmail.com on 12 Nov 2010 at 6:47