BlogBang

JCryption – Sécuriser ses formulaires sans SSL

lock JCryption   Sécuriser ses formulaires sans SSL

jCryption est une librairie javascript qui permet à n’importe qui de chiffrer les envois de formulaire de ses sites, d’une manière similaire à SSL mais sans SSL. La librairie est bâtie sur JQuery et les librairies de Multiple Precision et de Barrett (RSA en javascript).

Evidemment, ça ne remplacera pas le SSL car il n’y a pas la couche d’authentification, mais ça permet déjà d’avoir un chiffrement de base sur son site (RSA 2048 bits). Ça fonctionne avec IE 6, IE 7, IE 8, Firefox 3.x, Opera 9 et Chrome et bien sûr, comme toutes les bonnes choses, c’est open source :-) .

A télécharger ici et pour voir plein de démo, c’est par là

[photo]

Publicité

Je vous recommande aussi la lecture des sujets suivants


Faites un lien vers cette news sur votre site



14 commentaires

  1. Lenezir Reply to this comment


    Sympa ça.
    Mais ça marche quand même quand on a NoScript ? :s

    Posté le 11 août 2009 à 10:49:15

  2. bla Reply to this comment


    Ça ne fonctionne pas avec Safari ?

    Posté le 11 août 2009 à 11:26:57

  3. PoP Reply to this comment


    Je serai curieux de voir comment ça se comporte si on lui demande de chiffrer un très gros textarea…
    Comme mentionné, il manque le service d’authentification que fourni le SSL. Là, à part donner l’impression à l’utilisateur final que ses données sont entre de bonnes mains, c’est pas glop glop. Il suffit de se mettre en coupure, choper la clef publique délivrée par le site, fournir une autre clef publique, rechoper le flux remontant et déchiffer avec notre clef privée, rechiffrer avec la clef publique précédemment interceptée et youpla.

    Posté le 11 août 2009 à 11:32:58

  4. hart Reply to this comment


    @bla:
    Suffit d’aller voir le site officiel
    « jCryption was tested with Internet Explorer 6 +, Mozilla Firefox 3+, Safari 3, Opera 9+, Google Chrome. »

    Posté le 11 août 2009 à 11:33:38

  5. Dominique Rabeuf Reply to this comment


    Sécurisation bidon. Encore un truc fait par des gamins.

    Posté le 11 août 2009 à 11:53:20

  6. PoP Reply to this comment


    +1.
    le chiffrement ça sert à fournir un service d’authentification, de confidentialité, de non-répudiation et d’intégrité. S’il manque ne serait-ce qu’un des service, ça n’est pas du chiffrement, c’est juste de la merde.

    Cette librairie est au chiffrement ce que mettre la clef sous le paillasson est à la fermeture d’une porte : inutile pour qui prend le temps (2 minutes) de chercher la clef.

    Posté le 11 août 2009 à 12:10:37

  7. Sid Reply to this comment


    Oh… My… God…

    Sans déconner, de la crypto en JS ?! Ça a peut-être l’air sympa pour dépanner la gars qui a pas accès à du SSL sur son hébergement mutualisé et qui a besoin d’un petit bout de truc, mais franchement…
    Non pas que je crache sur le JS, mais sur le fait qu’un pauvre CRSF ou une XSS, et poupouf la crypto…

    One should read/watch this:

    http://rdist.root.org/2009/08/06/google-tech-talk-on-common-crypto-flaws/

    Posté le 11 août 2009 à 12:37:37

  8. ZePRiNCE Reply to this comment


    Bah ca fait que votre sessionID (par exemple) ne se trimballe pas en clair.
    C’est toujours mieux que rien, non ?

    Posté le 11 août 2009 à 13:25:28

  9. PoP Reply to this comment


    mais…il se trimballe en clair aussi, c’est la le problème. Il n’est pas chiffré si tu peux intercepter le message et le déchiffrer sans qu’aucune des parties ne s’en rende compte. il est juste écrit d’une façon qui ne le rend pas lisible par l’homme à la volée, c’est la seule chose qu’il est.
    Donc c’est pas mieux que rien, C’EST rien.
    Après si vous pensez que c’est effectivement une solution de chiffrement, c’est votre problème :-p

    Posté le 11 août 2009 à 14:28:09

  10. Galdon Reply to this comment


    Je ne vois pas trop l’intérêt quand même, sauf si on a un site de vente en ligne qui manipule des données hyper confidentielles.

    Posté le 11 août 2009 à 16:35:31

  11. PoP Reply to this comment


    Si tu te sers de ça sur un site de vente en ligne, préviens moi, que je n’y achète absolument rien.
    Faut le dire en Klingon que ça ne sécurise rien du tout?

    Posté le 11 août 2009 à 16:43:45

  12. Mousse Reply to this comment


    Encore un truc inutile en JS.

    Comme dis plus haut, si on a NoScript, ou JavaScript de désactiver, y’a plus de protection, tout est en clair.
    Et rien que le fait que tout sois géré par l’utilisateur, c’est une grosse faille.

    Never Trust User Input

    Posté le 12 août 2009 à 10:01:12

  13. RBXIII Reply to this comment


    +1.

    Le fait de mettre de la « sécurisation » côté utilisateur n’est pas une idée franchement brillante ^^
    Dans Firefox : Outils (Edition sous Linux/Mac) > Paramètres > désactiver le JS > OK, et voilà, plus de sécurité ^^
    Même combat avec les contrôles de saisie en JS ^^

    Posté le 13 août 2009 à 16:07:27

  14. Yoha Reply to this comment


    Je pense que ça peut être un petit plus au niveau de la sécurité, mais pas en remplacement du SSL. Il faut aussi que l’implémentation permette l’envoi des données sans cryptage Javascript. Pas comme moyen de sécurisation donc mais plutôt comme un petit plus contre d’éventuelles techniques pour bypasser le SSL qui seraient basées sur la prédiction de bloc de données en clair. Mais cela relève plus de la science-fiction au final…

    Sans compter le temps est la lourdeur que pourrait utiliser une tel chiffrement supplémentaire. Pour finir, son implémentation et son utilisation, ou la lecture de ses sources peut toujours constituer un exercice d’entraînement au JS.

    Posté le 15 août 2009 à 13:10:10