S'assurer qu'une rêquete web a été effectuée depuis applic iPhone
Bonjour à tous,
J'aurais besoin pour mon application d'être sûre que requête à été effectuée depuis mon application et qu'un petit malin n'a pas simplement utilisé son navigateur pour effectuer la même requête.
Je m'explique :
Pour s'inscrire au service l'utilisateur à la possibilité de s'enregistrer. Pour cela l'application se connecte à mon serveur de la manière suivante
www.monserveur.com/registration.php?pseudo=toto&password=toto&UDID=UDIDDELIPHONECLIENT
voila c'est très simple l'UDID de l'iPhone est récupérée par l'application et envoyé au serveur.
Le problème est que n'importe qui peut prendre l'UDID de votre iPhone et s'enregistrer au service en envoyant un UDID qui n'est pas le sien et donc voler votre compte.
Comment faire pour sécuriser ça ? J'ai pensé à utiliser du cryptage du style envoyer l'UDID une fois en clair et une fois en crypté avec une clé qui est connue que du serveur et de l'application cliente. Le serveur vérifie avec sa clé que le cryptogramme et bien celui généré par la même clé.
Mais je me pose des questions... est-il possible qu'en décompilant l'application on puisse découvrir quel est la clé de cryptage ? Est-ce secure? Y a-t-il un autre moyen plus simple ?
Mon serveur ne dispose pas de SSL
J'aurais besoin pour mon application d'être sûre que requête à été effectuée depuis mon application et qu'un petit malin n'a pas simplement utilisé son navigateur pour effectuer la même requête.
Je m'explique :
Pour s'inscrire au service l'utilisateur à la possibilité de s'enregistrer. Pour cela l'application se connecte à mon serveur de la manière suivante
www.monserveur.com/registration.php?pseudo=toto&password=toto&UDID=UDIDDELIPHONECLIENT
voila c'est très simple l'UDID de l'iPhone est récupérée par l'application et envoyé au serveur.
Le problème est que n'importe qui peut prendre l'UDID de votre iPhone et s'enregistrer au service en envoyant un UDID qui n'est pas le sien et donc voler votre compte.
Comment faire pour sécuriser ça ? J'ai pensé à utiliser du cryptage du style envoyer l'UDID une fois en clair et une fois en crypté avec une clé qui est connue que du serveur et de l'application cliente. Le serveur vérifie avec sa clé que le cryptogramme et bien celui généré par la même clé.
Mais je me pose des questions... est-il possible qu'en décompilant l'application on puisse découvrir quel est la clé de cryptage ? Est-ce secure? Y a-t-il un autre moyen plus simple ?
Mon serveur ne dispose pas de SSL
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tout est toujours possible, c'est une question de compétences et/ou de moyens.
Toujours plus que de n'avoir aucune validation ou d'utiliser un système d'authentification trivial à imiter (comme par exemple avoir un user-agent perso, mais qui est trivial à sniffer sur un réseau wifi).
Ma réponse va ressembler à une réponse de Normand, mais voila: La meilleure solution de protection est celle offrant le meilleur compromis en terme de sécurité vis à vis du temps de développement...
Concrètement, si tu développes une application d'accès à des comptes bancaires, il faut sortir l'artillerie lourde en terme de protection. Si c'est juste pour éviter que des petits malins foutent le bordel dans ta base de clients, je pense que la solution de chiffrement par secret partagé entre le serveur et l'application cliente est suffisante.
Après, il est toujours possible de faire des trucs plus rigolos, comme par exemple avoir une clé de chiffrement qui change chaque jour (calculée par exemple à partir de la date du jour, hachée avec un algorithme quelconque, mais secret), ce qui a pour avantage de ne pas avoir la clé "en clair" dans l'exécutable et obligeant celui qui veut hacker le système à comprendre l'algorithme de génération de la clé avant de pouvoir faire quoi que ce soit...
J'arrive pas à me représenter la complexité de découverte de la clé ? Genre je télécharge une applic qui me décompile le truc et je lis le code source... ce qui peut être donné a tout le monde.
Autre souci que j'ai c'est que je vais produire un jeu composé de plusieurs applications qui dans la pratique serviront à débloquer des features sur le serveur. Ce que j'ai peur c'est que quelqu'un publie sur le web une liste de 10 URL qui permettront aux utilisateurs de tout débloquer en 5 secondes et compromettre l'équilibre du jeu.
Autrement dit si c'est une bande marginale de hackers c'est jouable mais si il suffit d'un forum pour poster les liens c'est un peu problematique
Bah déjà il n'existe pas de décompilateur pour le language Objective-C. Tout ce qu'on peut obtenir, ce sont les noms des messages envoyés aux objets, et le code assembleur généré par le compilateur, ce qui complexifie énormément la compréhension d'un éventuel algorithme de génération de clé et/ou de chiffrement perso.
Ce genre de pratique deviendra totalement obsolète avec la sortie demain de l'OS 3.0, qui propose le framework "StoreKit" permettant de faire des achats directement depuis les applications...
Mais cela ne règle pas le problème de protection des URLs pour le débloquage des features...
A partir du moment où les URL sont différentes pour chaque client (ce qui est obligatoirement le cas vu qu'il faut pouvoir différencier les clients), et contiennent des infos suffisamment protégées pour qu'on ne puisse pas deviner la bonne URL pour chaque client, il y a peu de chance de se faire hacker, à moins d'avoir sorti le jeu du siècle à un prix injustifiéÂ
Dernière question alors :
Comment faire pour crypter en cocoa ? J'ai exploré la doc je n'ai malheureusement rien trouvé. Hormis l'exemple de code crypto exercice qui semble beaucoup plus complexe que ce dont j'ai besoin. N'existe pas pas une fonction simple du type encrypt(methode, stringACrypter ,Key) ;
Mais ceci dit on trouve des implémentations de la majorité des algo de chiffrement connus en cherchant un peu sur google...
Elle permet de facilement encrypter des données avec les algos d'encryption les plus courants...
Genre au hasard (je sais pas si c'est le plus adapté, j'ai pris le premier qui m'est tombé sous la main permettant de faire de l'asymétrique avec clé publique/clé privée) : http://www.openssl.org/docs/crypto/rsa.html
Il doit y avoir qques exemples d'utilisation qui trainent sur google j'imagine (pour rsa ou pour d'autres)
J'ai pensé à la solution suivante :
le client fait md5 d'une chaine de caractère composé d'une valeur spécifique connue de l'utilisateur concaténée à une clé secrète connue du serveur et du client.
Par exemple "Pseudo"+"CleSecrete"
J'ai cru comprendre sur le net que faire MD5 n'est pas considéré comme de l'encryptage au sens ou Apple pose la question au moment de publier l'application sur iTunes. Je n'aurai donc pas besoin de cocher la case "l'application contient du cryptage" Vous confirmez ?
Par contre, la solution exposée, qui consiste à rajouter du "sel" (salt en anglais) secret à une donnée puis calculer un hash MD5 de l'ensemble est un bon moyen d'obtenir un checksum non reproductible sans connaitre le sel, checksum permettant alors de valider la pertinence des autres paramètres passés dans l'URL.
Et comme c'est du hachage, ce n'est pas du chiffrement
Ensuite, pour rajouter un peu de difficulté, tu peux par exemple, en ce qui concerne l'UDID, le transférer dans le désordre et le remettre dans l'ordre coté serveur. Evidemment l'algorithme du "désordre organisé" doit rester secret.
Une requête POST ne serait-elle pas plus adaptée ?
Ca n'augmente pas le cryptage de tes données, et c'est pas énormément plus dur à contourner, mais au moins c'est pas contournable par juste un simple copier/coller, les utilisateurs ne pourront pas créer un lien dans un forum pour lancer la requête, etc. Donc déjà ça limite beaucoup plus l'envoi de la requête à uniquement depuis l'iPhone via ton appli et pas via un lien cliquable dans un forum.
Après faudrait voir comment fonctionne les "Apple Push Notifications" du SDK 3.0 : les iPhones souhaitant accepter les "notifications push" doivent envoyer une requête à un serveur Apple pour les autoriser à leur envoyer ces notifications, en leur fournissant il me semble le UDID de l'iPhone et genre un identifiant unique de l'appli. C'est donc un peu le même principe que pour ton système... et tu pourrais p'tet prendre modèle dessus ?