2009-04-21 8 views
9

Gibt es eine Möglichkeit, eine iPhone-Geräte-ID zu validieren? Ich möchte Geräte-IDs akzeptieren, die von iPhone-Benutzern per HTTP-Anfrage übermittelt wurden, und bestätigen, dass sie an ein legitimes Gerät gebunden sind.iPhone-Gerät-IDs validieren?

+1

Ich bin mir nicht bewusst. Hast du versucht, auf den Apple-Entwicklungsboards zu fragen? –

+0

Ich dachte, Push-Benachrichtigungen könnte eine Möglichkeit sein, eine UDID zu validieren, aber es ist nicht: https://devforums.apple.com/message/50658#50658 – bbrown

+0

AFAIK Sie können Länge Validierung für 40 Zeichen –

Antwort

6

Wenn es eine Möglichkeit gibt, die ID zu validieren, gibt es eine Möglichkeit, eine echte gefälschte ID zu erstellen.


ich mit Tyler Kommentar einverstanden sind, ist es eine Möglichkeit, Ids (leicht) zu erstellen und sie (auch leicht) zu validieren, sondern eine „Fälschung“ id erfordert das Scannen des gesamten Schlüsselraums (hart) oder Diebstahl zu erstellen der private Schlüssel, der den Schlüssel generiert hat (so funktioniert TLS tatsächlich). einige mein erster Kommentar ist nicht gültig.

Nie weniger, das ist nicht, wie das Apple-Gerät Id arbeitet, AFAIK sie die ID von verschiedenen Werten ID der Hardware (MAC-Adresse zum Beispiel)

+2

was tun, wenn es eine zentrale gab DB gültiger IDS? –

+2

Wahrscheinlich gibt es, aber Apple würde dich nie in die Nähe bringen. Ich kenne keine (große) Firma, die jemals die Seriennummern durchsuchen ließ. –

+1

Diese Aussage basiert auf einem Missverständnis darüber, wie moderne Kryptografie funktioniert. Das moderne Krypto basiert auf der Idee, dass es Funktionen gibt, die leicht zu berechnen sind, aber schwer zu invertieren sind. Zum Beispiel kann in der Kryptografie mit öffentlichen Schlüsseln jeder eine Nachricht verschlüsseln, aber nur der Empfänger kann sie entschlüsseln. Wenn nur ein kleiner Bruchteil aller UDIDs gültig ist, wäre es zeitaufwendig, gefälschte zu erzeugen. – Tyler

-1

erzeugen Wenn Sie es direkt greifen [[UIDevice currentDevice] uniqueIdentifier] mit eher als Aufforderung ein Benutzer dafür dann gibt es keinen Grund, warum es keine legitime Geräte-ID wäre.

+3

Ich denke, bpapa versucht, Nicht-iphone-Clients zu stoppen, die von feindlichen Benutzern geschrieben wurden, die auf seinen Dienst zugreifen. –

+1

Er könnte versuchen, eine Art von Signatur zu erzeugen, um sicherzustellen, dass die Nachricht nicht gefälscht wurde. Sehen Sie sich zum Beispiel den Signiermechanismus von Flickr an (Nr. 8 auf dieser Seite: http://flickr.com/services/api/auth.spec.html) –

+0

Achten Sie auf die Sicherheitslücke in Flickrs Methode. Sehen Sie dieses Dokument für Details, aber das TL; DR soll etwas wie sha1 über md5 benutzen, um potentielle Fälschung zu vermeiden. http://netifera.com/research/flickr_api_signature_forgery.pdf –

6

Um eine Anfrage aus Ihrer App zu validieren, könnten Sie die UUID und einen Hash senden, wobei hash = SHA1 (UUID + SECRET_KEY_STORED_IN_APP). Führen Sie dann die gleiche Hash-Funktion auf der Serverseite aus und verifizieren Sie, dass sie übereinstimmen. Sie könnten einen Zeitstempel als Nonce hinzufügen, wo Sie UUID, timestamp, hash mit hash = SHA1 (UUID + SECRET_KEY_STORED_IN_APP + TIMESTAMP) senden würden.

Dies ist sicherlich nicht ausfallsicher und hat viele Einschränkungen, aber macht es schwieriger, eine UUID zu fälschen.

+0

Wenn in der Binärdatei der Anwendung ein Geheimnis gespeichert ist, kann es abgerufen und geteilt werden. Die einzige Möglichkeit, ein Geheimnis sicher zu bekommen, wäre beim ersten Start, einen Web-Service über SSL aufrufen, einen Schlüssel abrufen und im Schlüsselbund des Telefons speichern. Aber sobald du das tust, kann jemand anderes deine App nachahmen und den Schlüssel auch bekommen. – bbrown

+0

alle Sicherheit ist ein Kostenvorteil Kompromiss. Das ist besser als Klartext, der wiederum besser ist als nichts. –

+0

Wäre die serverseitige Funktion nicht SHA1 (UUID + HASH + TIMESTAMP), nicht der geheime Schlüssel, wie könnte der Server das bekommen? @baalexander – Emil

2

Als Antwort auf Martin Gorton können Bibliotheken von Drittanbietern UIDevice uniqueIdentifier nicht vertrauen - es ist trivial, dies mit Objective-C-Methoden-Swizzling zu verfälschen.

Methode Swizzling tauscht zwei Selektoren (uniqueIdentifier und spoofUniqueIdentifier) ​​für eine Klasse (UIDevice). Nach dem Swizzle werden nachfolgende Aufrufe von UIDevice uniqueIdentifier die gefälschte UDID zurückgeben. Dies kann beim Testen von UDID-codierten Bibliotheken hilfreich sein, für die Sie keine gültige UDID haben.

hier ist ein Beispielcode aus 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

Es gibt keine Apple-Dokumentation oder Spezifikation, die das Layout dieser Zeichenfolge angibt.

Nur AFAIK Apple weiß, welche UDID real sind und welche falsch sind.

Eine begründete Vermutung wäre sie sind 40 Zeichen lang, bestehend aus alphanumerischen Zeichen. (A-f0-9)

regulärer Ausdruck:

[a-z0-9]{40} 
0

zu validieren UDID ^([A-F0-9]{40})$ folgenden regex versuchen oder Sie könnten here and just paste it gehen.

Wenn Sie [[UIDevice currentDevice].identifierForVendor UUIDString] verwenden (die Sie sollten) - dann ist es nur eine guid, haben a look at this regex ist (^([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})$) oder man konnte paste it here.

Hoffe das spart Ihnen etwas Zeit.