Afin d'empêcher les données personnelles de vos clients (US: PII) d'être conservées dans notre infrastructure cloud, nous exigeons l'usage d'indentifiants de contact uniques, non-devinables et immuables, plutôt que des identifiants facilement devinables comme les adresses email ou les numéros de téléphone. Utiliser les données PII comme identifiant de contact principal pour les appareils mobile n'est pas compatible.
Si le nom d'utilisateur n'est pas sécurisé (par exemple, s'il est visible d'autres utilisateurs, ou que d'autres utilisateurs peuvent le deviner), il représente alors un risque de sécurité, car n'importe qui peut se faire passer pour l'utilisateur et recevoir des messages personnalisés qui ne lui sont pas destinés.
Nous vous conseillons d'utiliser un nouveau champ personnalisé contenant à la fois le hachage de ce nom d'utilisateur et une question secrète. Ce champ personnalisé doit être généré de votre côté du serveur.
Vous pouvez utiliser l'identifiant unique, non-séquentiel et non-devinable de votre choix. Si vous en utilisez déjà un pour identifier les clients de manière unique en interne, vous pouvez l'utiliser.
Ou si vous voulez utiliser l'email, vous pouvez alors prendre l'email, lui ajouter une longue chaîne (secrète) existant seulement dans votre serveur, puis utiliser une fonction de hachage sur cet email, la longue chaîne secrète que vous êtes le seul à connaître.
Vous devrez créer un nouveau champ de suite dans votre éditeur de champ, incluant une valeur de chaîne. Vous devrez importer les valeurs hachées de vos clients dans notre base de données (elles serviront ensuite d'identifiant unique).
Vous n'avez pas besoin de conserver cette valeur hachée dans votre serveur dorsal, car quand un utilisateur se connecte avec son mot de passe, il peut utiliser son email+question secrète à ce moment-là pour créer la valeur hachée, puis utiliser cette dernière dans l'appel de connexion SDK au serveur dorsal Mobile Engage.
A des fins de performance, nous vous conseillons de conserver ce hachage plutôt que de le calculer à chaque connexion, mais ceci demeure une implémentation optionnelle pour l'optimisation de la performance.
Grâce à l'universalité de SHA-1, nous pouvons fournir les codes exemples spécifiques suivants :
PHP
<?php function nonGuessableUniqueID($guessableUniqueID, $salt) { return hash('sha1', $guessableUniqueID. $salt); } ?> Ruby
require 'digest' def nonGuessableUniqueID(guessableUniqueID, salt) Digest::SHA1.hexdigest(guessableUniqueID + salt) end
Python
import hashlib def nonGuessableUniqueID(guessableUniqueID, salt): return hashlib.sha1(guessableUniqueID + salt).hexdigest();
Node.js
var crypto = require('crypto'); function nonGuessableUniqueID(guessableUniqueID, salt) { var sum = crypto.createHash('sha1'); sum.update(email + salt); return sum.digest('hex'); } ];