Je travaille sur mon premier site de shopping sécurisé. Nous ne stockons pas les données de carte de crédit, ce n'est pas un problème. Cependant, nous avons une clé de transaction et une clé de connexion API pour notre passerelle de paiement (Authorize.net) que je préférerais conserver dans une base de données, plutôt que de codage dur dans mon PHP. Je ne sais pas que nous avons besoin d'une sécurité formidable, mais je préférerais ne pas la stocker en texte clair. Je sais sur Sha, mais c'est un moyen. J'ai besoin d'un moyen de stocker la valeur dans la base de données dans un format semi-sécurisé, mais pour pouvoir "déchiffrer" le "déchiffrer" de manière programmatique pour une utilisation dans ma fonction.
Une mise en garde supplémentaire à ceci est que mon site est hébergé, ce qui signifie qu'il y a une limite très serrée à quel type de choses que je peux installer, donc idéalement toute solution compterait sur quelque chose qui est inclus avec une installation PHP standard.
Quelqu'un peut-il me dire dans la bonne direction? Je suis très nouveau pour sécuriser les données.
édité pour ajouter: j'ai vérifié avec mon hôte et McRypt est installé. Est-ce la bonne direction à regarder?
3 Réponses :
Dans une perspective de sécurité, il n'y a pas de différence en le stockant dans les fichiers PHP ou dans la base de données, si une personne a accès à vos fichiers PHP, il a également accès à la base de données.
Travailler avec McRypt ne signifie pas que vous aurez plus de sécurité (s'ils peuvent lire vos fichiers PHP, ils peuvent aussi lire la clé) afin ...
Si j'étais vous, je stockais la clé API en texte brut sur un fichier en dehors du répertoire du serveur Web.
Écrivez simplement un bon code, vous devriez aller bien.
Nous ne le stockons pas dans la base de données pour la sécuriser; Nous le faisons afin que nous puissions écrire un front-end pour permettre à un non-codeur de modifier la valeur si nécessaire. Cela dit, nous préférerions qu'il ne soit pas stocké en texte clair. Et encore - ce site est hébergé dans le cloud; Nous n'avons pas accès à des annuaires en dehors de l'espace du serveur Web que nous sommes donnés.
En fait, vous devez toujours supposer que différents composants d'un serveur distant sont des risques de sécurité individuels. Il est possible à travers des injections SQL ou de simples requêtes mal formées pour renvoyer des lignes d'une base de données sans compromettre le code PHP. C'est pourquoi vous avez toujours des mots de passe hachaux - juste au cas où quelqu'un a eu votre base de données. Les sels ont été inventés pour empêcher les attaques de table arc-en-ciel et comme une clé McRypt - si quelqu'un a eu le sel, ils pouvaient contourner cela et toujours utiliser une table arc-en-ciel.
Je ne comprends pas pourquoi les gens descendent ce que j'ai dit, si vous croyez que vous serez plus en sécurité par hasard, cela ne changera rien. Pour traiter ce type de sécurité, vous devez avoir une infrastructure très différente, vous stockez une clé API, vous aurez la même "sécurité" avec un hachage comme avec un code TXT uni. Où stockez-vous vos fichiers de connexion DB: P? Vous devriez vérifier très bien ce que cette clé API est autorisée à faire à la place. Je veux dire, cette clé API doit pouvoir ne faire que certaines choses d'une adresse IP définie etc.
Supposons que vous stockiez la clé API dans la base de données et que quelqu'un utilise l'injection SQL théorique suivante: '- obtenir * de API_KEY . Maintenant, ils ont votre clé API. Supposons que vous stockiez la clé API dans un fichier de configuration PHP. Maintenant, que si quelqu'un brute a forcé votre mot de passe FTP et téléchargé le script? Ils ont votre clé API. Supposons que vous crypytez la clé API, stockez la clé de cryptage dans un fichier de configuration PHP et stockez la clé d'API cryptée dans la base de données. Vous êtes en sécurité de toute façon.
J'aime comment vous dites «de toute sécurité de toute façon» alors que vous avez votre base de données ou votre FTP. Je vois votre point, mais si quelqu'un peut craquer Ouvrir votre FTP, vous êtes Toast (Secure Server n'aurait pas du tout FTP), peu importe quoi. Quoi qu'il en soit, je vois ton point mais c'est très faible en termes de sécurité. Après tout, l'OP voulait juste cacher une touche API, bien sûr, je ne serais pas heureux de partager une clé API avec un craqueur, mais une clé API ne devrait pas être autorisée à faire de rien de méchant. Habituellement, ces touches API sont utilisées pour créer un jeton pour obtenir des appels http / poster
hmm, vous pouvez essayer le cryptage AES. Le problème est que vous devez sauvegarder le hachage de sel (98sdfx9c6v5c) quelque part dans votre php.
Insérer configuration: p> Sélectionnez Config: P> SELECT AES_DECRYPT(secret_key,'98sdfx9c6v5c') AS secret_url FROM config
mcrypt peut être votre ami ici. Ce que vous avez besoin de prendre en compte, cependant, est que chaque méthode de cryptage disponible (et utile) au public nécessite une clé. Si le cryptage AES ou le cryptage 3DES n'avait pas besoin de clé pendant le processus de cryptage, le cryptage serait simplement une question d'essayer chaque méthode de déchiffrement standard jusqu'à ce que vous obteniez un résultat significatif. Ainsi, le stockage de la clé de votre passerelle de paiement entraîne les mêmes risques que de stocker la clé de votre cryptage. Peu importe le nombre de couches de cryptage que vous souhaitez ajouter, à un certain niveau, il devrai y avoir une clé stockée en texte brut, généralement codée dur dans le PHP et souvent dans un fichier La seule option pour stocker en toute sécurité les informations sans besoin d'une clé serait d'inventer votre propre méthode de cryptage. La sécurité de cette méthode réside uniquement dans le fait que personne ne connaît les moyens par lesquels vous crypterez la chaîne. Ils n'ont donc pas de motif étape par étape pour simplement marcher à l'envers. Si vous avez déjà dit à quelqu'un comment votre cryptage a fonctionné, la sécurité serait perdue. En outre, il existe de nombreuses méthodes algorithmiques de casser des cryptage simples (remplacement des lettres, par exemple). C'est pourquoi les mathématiciens obtiennent beaucoup d'argent pour développer des choses comme AES.
Votre meilleur meilleur est de regarder mecrypt chiffrer et mecrypt décrypt . De cette façon, si juste votre PHP est compromis, ils connaissent la clé que vous avez utilisée pour chiffrer, mais elles n'ont pas les données. Si juste la base de données est compromise, ils ont les données mais pas la clé que vous avez utilisée pour chiffrer. Si les deux sont compromis, vous êtes vissé. Mais si les deux sont compromis, vous êtes vissé, peu importe ce que vous faites, c'est donc un itinéraire assez sûr. config.php inclus. rendre facile de changer à l'avenir.
Merci, Steven. Je suis conscient que si le code et la base de données sont piratés, nous sommes à la suite d'une crique. Mais c'est à peu près le cas partout, non? Il n'y a que tant que vous pouvez faire.
Il y a une façon de savoir ce problème, mais cela implique beaucoup de code et beaucoup de frais généraux. J'ai fait un système une fois utilisé trois ordinateurs. L'un était le "PHP Master", l'un était le "Master de la base de données", et l'un était le "Master Key". Le maître PHP avait la clé du maître de la base de données, le maître de la base de données avait la clé de la clé principale et que la clé de clé avait une base de données de clés (une pour chaque ligne de données) pour les données de la base de données. J'ai également eu tout PHP sur le disque dur crypté et il a été déchiffré à un lecteur de RAM lorsque l'ordinateur a démarré.
Oui, je ne suis pas sûr que notre client serait disposé à payer pour la quantité de travail qui prendrait. De plus, à nouveau - le site est hébergé dans le cloud, nous devons donc garder les choses à peu près un seul endroit. (Et je ne peux pas m'empêcher de rigoler et de penser, "Il n'y a que zul" chaque fois que vous mentionnez Key Master ...)
Vous ne pouvez pas protéger vos données de l'administrateur de la société hôte. Tout simplement pas possible en théorie.
Nous n'essayons pas de protéger les données de l'administrateur hôte; Nous voulons simplement nous assurer qu'ils sont piratés et notre base de données est compromise, les clés de notre passerelle de paiement ne sont pas un texte brut.