You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Voilà mes réflexions pour le système de protection du boting pour l'API pour l'appli mobile :
Chaque paquet envoyé contient un hash + un timestamp + un tag de version
Le tag de version est incrémenté à chaque version de l'API
Le timestamp est celui du client
Le hash est calculé en concatenant les données suivantes :
id unique de l'utilisateur
timestamp
un "secret" correspondant au paquet en question (exemple : 9875114948 pour une commande profile, 19841259447 pour shop etc.). Ce secret est calculé de la façon suivante :
Au moment de la compilation de l'API + appli mobile, on génère un nombre aléatoire pour chaque paquet
On génère également un algorithme avec plein de calculs d'une centaine de lignes par exemple (addition, soustraction, modulo, opération binaires etc)
On applique cet algo à chaque nombre aléatoire et on stocke ça pour le serveur. Ainsi, le serveur connait le secret
Pour l'application mobile, on compile ça nativement (C pour android par exemple), et on refait le calcul entier à chaque paquet envoyé
Ainsi, ceci permet les choses suivantes :
Le timestamp empêche le rejeu
Le fait que ce soit hashé évite un man in the middle
l'id unique évite le partage des données entre utilisateurs
le seul moyen (je crois) de reproduire l'ID attendu consiste à décompiler le package de l'appli, trouver l'algo pour chaque paquet + le nombre aléatoire, décompiler un code compilé (très chiant à lire) etc...
Certes c'est de l'obfuscation, mais la complexité + le fait de devoir le faire à chaque mise à jour découragera un certain nombre de personnes. Combiné avec la surveillance active (ex : grafana) ou encore d'autres choses (captcha), on pourra éviter une partie du boting.
Après de toute façon, il n'y a aucun moyen d'éviter le boting, c'est toujours un jeu du chat et de la souris. Le but est de rendre le boting complexe et dissuadant.
The text was updated successfully, but these errors were encountered:
timestamp : 1734016293 ID utilisateur : 8d4c5e02-03e3-476b-a58e-e835af9f97ad
Calcul du hash d'une commande ping
sha256(timestamp || ID user || nombre paquet) = sha256(17340162938d4c5e02-03e3-476b-a58e-e835af9f97ad2412)
= 699c0ef266dc50800132e76df8bae76d5ca1766eb673eaa4c652c624958a32bd
Voilà mes réflexions pour le système de protection du boting pour l'API pour l'appli mobile :
Ainsi, ceci permet les choses suivantes :
Certes c'est de l'obfuscation, mais la complexité + le fait de devoir le faire à chaque mise à jour découragera un certain nombre de personnes. Combiné avec la surveillance active (ex : grafana) ou encore d'autres choses (captcha), on pourra éviter une partie du boting.
Après de toute façon, il n'y a aucun moyen d'éviter le boting, c'est toujours un jeu du chat et de la souris. Le but est de rendre le boting complexe et dissuadant.
The text was updated successfully, but these errors were encountered: