• # Adapter la sécurité à la criticité

    Posté par (site web personnel) . En réponse au journal Compromission de code source.. Évalué à 4.

    Sans vouloir te rabaisser, tu développes une appli qui est au 5000è rang de SF, avec environ 1 téléchargement par jour, ça n'interresse aucun pirate.

    Une mauvaise sécurité est de mettre trop de sécurité perçue comme gavante par les utilisateurs.

    Dans ton exemple, une personne ayant ton login/password ne pourra pas faire de mal à beaucoup de monde, il ne s'y intéressera donc pas. Reste alors les scripts, qu'on bloque avec un minimum de sécurité chez soi.

    En conclusion , SF offre une grande facilité pour le développement et la publication de logiciel libre mais il pose un réel problème de sécurité.

    SF pose un réel problème de sécurité? vraiment? tout est en SSL (du web à l'upload des fichiers en passant par le SVN), reste alors ta machine. Si elle est compromise, quoique fasse SF tu perdras (ben oui, si ta machine est compromise ta clé SSH serait elle aussi compromise en mémorisant ta passphrase)
    Reste à utiliser des codes uniques, mais on revient au problème initial : trop de sécurité tue la sécurité (déja que pour ma banque ça me gave et donc que je tue leur sécurité en stockant leur codes uniques à des endroits "pas biens"... Alors pour "juste" SF!)

    SF a beaucoup de défauts (put**** de mises à jour ces temps-ci, qui cassent une tonne de choses), mais je ne pense pas mettre la sécurité dans ses défauts.

    Reste de ton côté à maitriser ta sécurité, tout en ayant en tête de ne pas en faire trop au risque que tes utilisateurs contourne la chose : a chaque niveau de sécurité sa politique de sécurité, et j'ai l'impression que tu veux être plus sécurisé que les développeurs de Azureus à 300 000 downloads par jour.