Closed GoogleCodeExporter closed 8 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
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
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
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
Original comment by teixeira...@gmail.com
on 23 Jun 2010 at 7:53
>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
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
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
Original issue reported on code.google.com by
iphone.h...@gmail.com
on 4 Jun 2010 at 7:21