Première règle de sécurité des applications: toute machine à laquelle un attaquant obtient un accès physique ou électronique illimité appartient désormais à votre attaquant, quel que soit l'endroit où il se trouve réellement ou ce que vous avez payé pour cela.
Deuxième règle de sécurité des applications: tout logiciel qui laisse les limites physiques à l'intérieur desquelles un attaquant ne peut pas pénétrer appartient désormais à votre attaquant, quel que soit le temps que vous avez passé à le coder.
Troisième règle: toute information qui laisse ces mêmes limites physiques qu'un attaquant ne peut pas pénétrer appartient maintenant à votre attaquant, quelle que soit sa valeur pour vous.
Les fondements de la sécurité des technologies de l'information reposent sur ces trois principes fondamentaux; le seul ordinateur vraiment sécurisé est celui enfermé dans un coffre-fort, à l'intérieur d'une cage Farraday, à l'intérieur d'une cage en acier. Il y a des ordinateurs qui passent la majeure partie de leur durée de vie dans cet état; une fois par an (ou moins), ils génèrent les clés privées des autorités de certification racine de confiance (devant une multitude de témoins avec des caméras enregistrant chaque centimètre de la pièce dans laquelle ils se trouvent).
Maintenant, la plupart des ordinateurs ne sont pas utilisés dans ces types d'environnements; ils sont physiquement en plein air, connectés à Internet via un canal radio sans fil. En bref, ils sont vulnérables, tout comme leur logiciel. Il ne faut donc pas leur faire confiance. Il y a certaines choses que les ordinateurs et leurs logiciels doivent savoir ou faire pour être utiles, mais il faut veiller à ce qu'ils ne puissent jamais en savoir ou en faire assez pour causer des dommages (du moins pas des dommages permanents en dehors des limites de cette seule machine). ).
Vous saviez déjà tout cela; c'est pourquoi vous essayez de protéger le code de votre application. Mais c'est là que réside le premier problème; les outils d'obscurcissement peuvent rendre le code un gâchis pour qu'un humain essaie de creuser, mais le programme doit encore s'exécuter; cela signifie que le flux logique réel de l'application et les données qu'elle utilise ne sont pas affectés par l'obscurcissement. Étant donné un peu de ténacité, un attaquant peut simplement désobscurcir le code, et ce n'est même pas nécessaire dans certains cas où ce qu'il regarde ne peut être autre chose que ce qu'il cherche.
Au lieu de cela, vous devriez essayer de vous assurer qu'un attaquant ne peut rien faire avec votre code, quelle que soit la facilité avec laquelle il en obtient une copie claire. Cela signifie, pas de secrets codés en dur, car ces secrets ne sont pas secrets dès que le code quitte le bâtiment dans lequel vous l'avez développé.
Ces valeurs-clés que vous avez codées en dur doivent être entièrement supprimées du code source de l'application. Au lieu de cela, ils devraient être dans l'un des trois endroits; mémoire volatile sur l'appareil, ce qui est plus difficile (mais toujours pas impossible) pour un attaquant d'obtenir une copie hors ligne de; en permanence sur le cluster de serveurs, dont vous contrôlez l'accès avec une main de fer; ou dans un deuxième magasin de données sans rapport avec votre appareil ou vos serveurs, comme une carte physique ou dans la mémoire de votre utilisateur (ce qui signifie qu'il finira par être dans la mémoire volatile, mais il n'est pas nécessaire que cela dure longtemps).
Considérez le schéma suivant. L'utilisateur entre ses informations d'identification pour l'application de la mémoire dans l'appareil. Vous devez, malheureusement, vous assurer que l'appareil de l'utilisateur n'est pas déjà compromis par un enregistreur de frappe ou un cheval de Troie; le mieux que vous puissiez faire à cet égard est de mettre en œuvre une sécurité multifactorielle, en se souvenant des informations d'identification difficiles à truquer sur les appareils que l'utilisateur a utilisés (MAC / IP, IMEI, etc.) et en fournissant au moins un canal supplémentaire en laquelle une tentative de connexion sur un appareil inconnu peut être vérifiée.
Les informations d'identification, une fois entrées, sont masquées par le logiciel client (à l'aide d'un hachage sécurisé) et les informations d'identification en texte brut sont supprimées; ils ont atteint leur objectif. Les informations d'identification obscurcies sont envoyées via un canal sécurisé au serveur authentifié par certificat, qui les hache à nouveau pour produire les données utilisées pour vérifier la validité de la connexion. De cette façon, le client ne sait jamais ce qui est réellement comparé à la valeur de la base de données, le serveur d'application ne connaît jamais les informations d'identification en clair derrière ce qu'il reçoit pour la validation, le serveur de données ne sait jamais comment les données qu'il stocke pour la validation sont produites, et un homme dans le milieu ne voit que du charabia même si le canal sécurisé a été compromis.
Une fois vérifié, le serveur retransmet un jeton sur le canal. Le jeton n'est utile que dans la session sécurisée, est composé de bruit aléatoire ou d'une copie chiffrée (et donc vérifiable) des identifiants de session, et l'application cliente doit envoyer ce jeton sur le même canal au serveur dans le cadre de toute demande faire quelque chose. L'application client le fera plusieurs fois, car elle ne peut rien faire impliquant de l'argent, des données sensibles ou quoi que ce soit qui pourrait être dommageable en soi; il doit plutôt demander au serveur d'effectuer cette tâche. L'application cliente n'écrira jamais aucune information sensible dans la mémoire persistante sur l'appareil lui-même, du moins pas en texte brut; le client peut demander au serveur via le canal sécurisé une clé symétrique pour crypter toutes les données locales dont le serveur se souviendra; dans une session ultérieure, le client peut demander au serveur la même clé pour déchiffrer les données à utiliser dans la mémoire volatile. Ces données ne seront pas non plus la seule copie; tout ce que le client stocke doit également être transmis sous une forme ou une autre au serveur.
De toute évidence, cela rend votre application fortement dépendante de l'accès à Internet; l'appareil client ne peut exécuter aucune de ses fonctions de base sans une connexion et une authentification appropriées par le serveur. Pas différent de Facebook, vraiment.
Maintenant, l'ordinateur que l'attaquant veut est votre serveur, car c'est lui et non l'application / l'appareil client qui peut lui faire gagner de l'argent ou causer de la peine à d'autres personnes pour son plaisir. C'est bon; vous en avez beaucoup plus pour votre argent en dépensant de l'argent et des efforts pour sécuriser le serveur qu'en essayant de sécuriser tous les clients. Le serveur peut se trouver derrière toutes sortes de pare-feu et autres dispositifs de sécurité électroniques, et peut en outre être physiquement sécurisé derrière de l'acier, du béton, un accès par carte / broche et une surveillance vidéo 24h / 24. Votre attaquant devrait en effet être très sophistiqué pour accéder directement à tout type d'accès au serveur, et vous devriez (devriez) le savoir immédiatement.
Le mieux qu'un attaquant puisse faire est de voler le téléphone et les informations d'identification d'un utilisateur et de se connecter au serveur avec les droits limités du client. Si cela se produit, tout comme la perte d'une carte de crédit, l'utilisateur légitime devrait être invité à appeler un numéro 800 (de préférence facile à retenir, et non au dos d'une carte qu'il porterait dans son sac à main, son portefeuille ou sa mallette qui pourrait être volé à côté de l'appareil mobile) à partir de tout téléphone auquel ils peuvent accéder et qui les connecte directement à votre service client. Ils déclarent que leur téléphone a été volé, fournissent un identifiant unique de base et le compte est verrouillé, toutes les transactions que l'attaquant a pu traiter sont annulées et l'attaquant est de retour à la case départ.