• La source fermée est plus sécurisée que l'open-source car les attaquants peuvent voir le code source et trouver et exploiter des vulnérabilités. Bien que je ne prétende pas que c'est toujours faux, avec logiciel open source, il est au moins possible pour des experts extérieurs d'examiner le logiciel à la recherche de vulnérabilités / portes dérobées béantes, puis de les corriger publiquement. Avec un logiciel source fermé, ce n'est tout simplement pas possible sans un démontage minutieux du binaire. Et bien que vous et la plupart des attaquants n'ayez pas accès au code source, il existe probablement de puissants attaquants (par exemple, le gouvernement américain) qui pourraient être en mesure d'obtenir le code source ou d'y injecter des vulnérabilités secrètes.

• L'envoi de données sur un réseau est secret si vous cryptez les données . Le chiffrement doit être authentifié pour empêcher un attaquant de modifier vos données. Vous devez vérifier l'identité de l'autre partie à laquelle vous envoyez des informations, sinon un homme du milieu peut intercepter et modifier votre trafic. Même avec l'authentification et l'identification, le cryptage fuit souvent des informations. Vous parlez à un serveur via HTTPS? Les écouteurs du réseau (n'importe qui chez votre FAI) savent exactement combien de trafic vous avez envoyé, à quelle adresse IP et quelle est la taille de chacune des réponses (par exemple, vous pouvez empreinte digitale de diverses pages Web en fonction de la taille de toutes les ressources transférées). De plus, en particulier avec les sites Web AJAX, les informations que vous saisissez conduisent souvent à une réponse du serveur identifiable par ses modèles de trafic. Voir Fuites de canaux secondaires dans les applications Web.

• Questions de réinitialisation de mot de passe faible - Comment était le courriel de Sarah Palin piraté? Une personne a suivi la procédure de réinitialisation du mot de passe et a pu répondre correctement à chaque question à partir des informations accessibles au public. Quelles questions de réinitialisation de mot de passe une connaissance de Facebook pourrait-elle résoudre?

• System X est incassable - il utilise un cryptage AES 256 bits et il faudrait probablement un milliard d'ordinateurs ordinaires un million de milliards de milliards de milliards d'années pour se fissurer. Oui, c'est possible ». t être forcé brutalement car cela nécessiterait ~ 2 ²⁵⁶ opérations. Mais le mot de passe pourrait être réutilisé ou dans un dictionnaire de mots de passe courants. Ou vous avez bloqué un keylogger sur l'ordinateur. Ou vous avez menacé quelqu'un avec une clé à 5 $ et il vous a donné le mot de passe. Il existe des attaques par canal secondaire. Peut-être que le générateur de nombres aléatoires était défectueux. Les attaques chronométrées existent. Les attaques d'ingénierie sociale existent. Ce sont généralement les liens les plus faibles.

• Cette faible pratique nous suffit, nous n'avons pas le temps d'attendre pour faire les choses en toute sécurité . Le gouvernement américain n'a pas à se soucier de crypter les flux vidéo de ses drones - qui saura écouter les bonnes fréquences de porteuse; outre les boîtes de cryptage seront lourdes et coûteuses - pourquoi s'embêter?

• Les ordinateurs quantiques peuvent résoudre rapidement des problèmes de temps exponentiels et casseront toutes les méthodes de chiffrement . Les gens lisent des articles de vulgarisation scientifique sur les ordinateurs quantiques et apprennent qu'ils sont ces entités mystiques super-puissantes qui exploiteront la puissance de calcul d'un nombre presque infini d'univers parallèles pour faire n'importe quoi. Ce n'est qu'en partie vrai. Les ordinateurs quantiques permettront d'effectuer la factorisation et les logarithmes discrets en temps polynomial O (n ³ ) via l'algorithme de Shor rendant RSA, DSA et chiffrement basés sur ces fonctions de trappe facilement cassables. De même, les ordinateurs quantiques peuvent utiliser l'algorithme de Grover pour forcer brutalement un mot de passe qui devrait prendre O (2 ^N ) temps en seulement O (2 ^{N / 2} ) temps; réduire de moitié efficacement la sécurité d'une clé symétrique - L'algorithme de Grover est connu pour être asymptotiquement optimal pour les ordinateurs quantiques, alors ne vous attendez pas à une amélioration supplémentaire.

Quelques exemples:

• Des touches plus grandes. RSA 4096 bits, AES 256 bits ... plus de bits sont toujours meilleurs. (Voir les commentaires: il ne sert à rien d'avoir des clés plus grandes que la taille qui garantit le statut "ne peut pas le casser du tout"; mais des clés plus grandes impliquent une surcharge du réseau et du processeur, parfois en grande quantité.)

• Application automatique de "fonctions sûres" comme snprintf () au lieu de sprintf () (cela ne fera pas grand-chose à moins que le programmeur ne teste la possibilité de tronquer, et cela n'empêchera pas d'utiliser une chaîne fournie par l'utilisateur comme chaîne de format). Des points supplémentaires pour strncpy () qui ne fait pas ce que la plupart des gens semblent supposer (en particulier, cela ne garantit pas un '\ 0' final).

• "Pureté du gestionnaire de sécurité". En application de la séparation des tâches et des rôles, toutes les décisions «liées à la sécurité» devraient être prises par un spécialiste de la sécurité, distinct des concepteurs et développeurs du projet. Souvent poussé à l'extrême malavisé, où le gars qui décide quels ports réseau doivent être laissés ouverts sur un pare-feu n'a aucune connaissance du projet, et refuse délibérément d'apprendre quoi que ce soit à ce sujet, car une décision indépendante est plus importante qu'une décision éclairée .

Je vais ajouter mes propres exemples appsec que j'ai vus lors de la consultation:

• "Je vais vous envoyer un zip chiffré et inclure le mot de passe dans le même e-mail ..." m'est arrivé plus d'une fois. Une porte verrouillée ne restera pas verrouillée si vous laissez la clé dans la porte.
• "Mais vous n’avez pas pu obtenir l’injection SQL et SMTP , nous avons appelé sanitize () sur tout! ". Il n'y a aucun moyen de sécuriser les variables pour chaque utilisation, vous devez utiliser la routine d'assainissement pour le travail.
• "Nous ne pouvons pas être piratés car nous utilisons uniquement la plate-forme / langue / OS XXX". Chaque plate-forme a des problèmes de sécurité, période↑.
• "Nous avons une évaluation de sécurité annuelle, vous ne pourrez rien trouver." Fréquence! = Qualité . Avoir des évaluations fréquentes est une bonne chose, mais cela ne garantit rien!
• "Nous avons un WAF, ce qui signifie que nous n'avons pas besoin de patchanything." Ouais, alors cela se produit ... J'avais un client qui ne corrigeait pas les vulnérabilités CSRF connues, car ils supposaient que le WAF serait capable d'arrêter ces attaques. (Aucun WAF ne peut le faire. J'ai trouvé un jour un WAF qui prétendait pouvoir "empêcher tout le top 10 de owasp", et l'interface de gestion HTTP du WAF était vulnérable au CSRF.)

• Les mots de passe doivent être salés et hachés avant d'être stockés dans la base de données. SHA-1 est un bon ajustement, SHA-512 est parfait.

J'entends encore celui-là de la part de nombreux professionnels de la sécurité, de la formation à la sécurité et des guides de sécurité actuels.

Utiliser SSL uniquement pour la page de connexion plutôt que pour toutes les zones authentifiées d'un site Web.

Juste un, mais c'est un gros problème: "La sécurité de l'information est un problème technologique, qui peut être résolu avec la technologie."

Afin d'empêcher les gens de découvrir si certains utilisateurs existent dans le système - en masquant si le mot de passe était incorrect ou le nom d'utilisateur était invalide lors d'une tentative de connexion infructueuse, ... tout en offrant en même temps un formulaire de réinitialisation de mot de passe qui perd cette information.

"Notre site Web ne peut pas être piraté car nous utilisons SSL". Monsieur, cela le rend plus facile à exploiter s'il est vulnérable, car même votre IDS / IPS est rendu inutile par le flux SSL.