2009-04-21 6 views
9

Existe-t-il un moyen de valider un identifiant d'appareil iPhone? Je souhaite être en mesure d'accepter les ID d'appareil soumis par les utilisateurs de l'iPhone via une requête HTTP et de valider qu'ils sont liés à un appareil légitime.Valider les ID de l'iPhone?

+1

Je n'en connais pas. Avez-vous essayé de demander sur les conseils de développement Apple? –

+0

Je pensais que les notifications push pourraient être un moyen de valider un UDID, mais ce n'est pas: https://devforums.apple.com/message/50658#50658 – bbrown

+0

AFAIK Vous pouvez faire la validation de longueur pour 40 caractères –

Répondre

6

S'il existe un moyen de valider l'ID, il existe un moyen de créer un faux ID réel.


Je suis d'accord avec un commentaire Tyler, il est un moyen de créer Ids (facile) et de les valider (aussi facile) mais de créer un identifiant « faux », il faudra numériser l'ensemble keyspace (dur) ou le vol la clé privée qui a généré la clé (c'est ainsi que fonctionne TLS). certains de mes commentaires initiaux ne sont pas valides.

Jamais moins, ce n'est pas comment l'appareil d'Apple Id fonctionne, autant que je sache qu'ils génèrent l'id de différentes valeurs id du matériel (adresse MAC par exemple)

+2

et s'il y avait un central DB d'IDS valide? –

+2

Probablement il y a, mais Apple ne vous laisserait jamais approcher. Je ne connais aucune entreprise (majeure) qui vous ait jamais permis de parcourir leurs numéros de série. –

+1

Cette affirmation est basée sur un malentendu sur le fonctionnement du crypto moderne. Le crypto moderne repose sur l'idée qu'il existe des fonctions faciles à calculer mais difficiles à inverser. Par exemple, dans la cryptographie à clé publique, n'importe qui peut crypter un message, mais seul le destinataire peut le déchiffrer. Si seulement une petite fraction de tous les UDID sont valides, il serait fastidieux de produire de faux. – Tyler

-1

Si vous prenez directement à l'aide [[UIDevice currentDevice] uniqueIdentifier] plutôt que incitant un utilisateur pour cela alors il n'y a aucune raison pour laquelle ce ne serait pas un identifiant d'appareil légitime.

+3

Je pense que bpapa essaie d'arrêter les clients non-iphone écrits par des utilisateurs hostiles accédant à son service. –

+1

Il pourrait vouloir essayer de générer une sorte de signature pour s'assurer que le message n'a pas été truqué. Par exemple, voir le mécanisme de signature de Flickr (# 8 sur cette page: http://flickr.com/services/api/auth.spec.html) –

+0

Attention à la vulnérabilité dans la méthode de Flickr. Voir ce document pour plus de détails, mais TL; DR doit utiliser quelque chose comme sha1 sur md5 pour éviter toute falsification potentielle. http://netifera.com/research/flickr_api_signature_forgery.pdf –

6

Pour valider une demande provenant de votre application, vous pouvez envoyer l'UUID et un hachage, où hash = SHA1 (UUID + SECRET_KEY_STORED_IN_APP). Faites ensuite la même fonction de hachage côté serveur et vérifiez qu'ils correspondent. Vous pouvez ajouter un horodatage à un nonce, où vous enverriez UUID, timestamp, hash avec hash = SHA1 (UUID + SECRET_KEY_STORED_IN_APP + TIMESTAMP).

Il ne s'agit certainement pas d'une preuve d'échec et de nombreuses limitations, mais cela rend plus difficile l'usurpation d'un UUID.

+0

S'il y a un secret stocké dans le binaire de l'application, il peut être obtenu puis partagé. La seule façon d'obtenir un secret serait le lancement initial, d'appeler un service Web via SSL, d'obtenir une clé et de la stocker dans le trousseau du téléphone. Mais dès que vous faites cela, quelqu'un d'autre peut imiter votre application et obtenir la clé aussi. – bbrown

+0

toute sécurité est un compromis coût-bénéfice. C'est mieux que le texte en clair qui est à son tour mieux que rien. –

+0

La fonction côté serveur ne serait-elle pas SHA1 (UUID + HASH + TIMESTAMP), pas la clé secrète, comment le serveur pourrait-il obtenir cela? @baalexander – Emil

2

En réponse à Martin Gorton, les bibliothèques tierces ne peuvent pas faire confiance à UIDevice uniqueIdentifier - il est trivial de spoofer cela en utilisant la méthode Objective C swizzling.

La méthode swizzling permute deux sélecteurs (uniqueIdentifier et spoofUniqueIdentifier) ​​pour une classe (UIDevice). Après le swizzle, les appels ultérieurs à UIDevice uniqueIdentifier renverront l'UDID usurpé. Cela peut être utile pour tester les bibliothèques à clé UDID pour lesquelles vous n'avez pas d'UDID valide.

ici est un exemple de code de http://marccodes.posterous.com/method-swizzling-uidevice-to-spoof-udid:

#import <objc/runtime.h> 

// swap a class's instance method selectors, we do this to overload existing methods in category declarations 
void swizzleMethodsForClass(Class c, SEL origMethodSel, SEL newMethodSel) 
    { 
    NSLog(@"swizzling %@ instance methods: %@ -> %@", NSStringFromClass(c), 
     NSStringFromSelector(origMethodSel), NSStringFromSelector(newMethodSel)); 

    Method origMethod = class_getInstanceMethod(c, origMethodSel); 
    Method newMethod = class_getInstanceMethod(c, newMethodSel); 

    // check if method is inherited from superclass 
    if(class_addMethod(c, origMethodSel, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) 
     class_replaceMethod(c, newMethodSel, method_getImplementation(origMethod), method_getTypeEncoding(origMethod)); 

    // exchange un-subclassed method 
    else 
     method_exchangeImplementations(origMethod, newMethod); 
    } 

@interface UIDevice (SpoofUDID) 

@end 

#define UDID_TO_SPOOF  @"e0101010d38bde8e6740011211af315301010223" 

@implementation UIDevice (SpoofUDID) 

// swizzle this instance method for UIDevice class 
- (NSString *) spoofUniqueIdentifier 
     { 
     static NSString *spoofUDID = UDID_TO_SPOOF; 
     NSLog(@"spoofing %@ instead of %@", spoofUDID, [[UIDevice currentDevice] 
spoofUniqueIdentifier]); 
     return spoofUDID; 
     } 

@end 

// call this from your app delegate 
- (void) initUDID 
     { 
     NSString *UDID = [[UIDevice currentDevice] uniqueIdentifier]; 
     NSLog(@"this is my old udid: %@", UDID); 

     swizzleMethodsForClass([UIDevice class], @selector(uniqueIdentifier), @selector(spoofUniqueIdentifier)); 

     NSString *UDID2 = [[UIDevice currentDevice] uniqueIdentifier]; 
     NSLog(@"this is my new udid: %@", UDID2); 
     } 
0

Il n'y a pas de documentation de pomme ou de spécification qui spécifie la mise en page à cette chaîne.

AFAIK seul Apple sait quels UDID sont réels et lesquels sont faux. Une supposition éclairée serait qu'ils ont 40 caractères, constitués de caractères alphanumériques. (A-F0-9)

motif de RegEx:

[a-z0-9]{40} 
0

pour valider UDID essayer de suivre regex ^([A-F0-9]{40})$ ou vous pouvez aller here and just paste it.

Si vous utilisez [[UIDevice currentDevice].identifierForVendor UUIDString] (que vous devriez) - alors il est juste un guid, ont a look at this regex est (^([0-9A-Fa-f]{8}[-][0-9A-Fa-f]{4}[-][0-9A-Fa-f]{4}[-][0-9A-Fa-f]{4}[-][0-9A-Fa-f]{12})$) ou vous pouvez paste it here.

Espérons que cela vous fasse gagner du temps.