IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre averti
    Homme Profil pro
    Lycéen
    Inscrit en
    décembre 2014
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : décembre 2014
    Messages : 106
    Points : 322
    Points
    322
    Par défaut
    Citation Envoyé par BenBout62 Voir le message
    Je n'y vois rien de stupide personnellement, il y a encore quelques décennies le chiffrement était limité à une longueur de clé de 128 bits dans le domaine civil (il me semble, je n'ai pas de source donc je n'en fais pas un argument solide, je l'admet volontiers je reste très objectif à chacun de mes messages pour ma part).
    Je ne trouve pas cela normal que, selon le droit public, donc parfaitement légal, la force publique puisse défoncer la porte d'une propriété privée pour y arréter un suspect mais que tout en étant autorisé à casser un système crypté pour appréhender un crime en préparation, il soit impossible de le faire dans un délai relativement court pour empêcher ce dit crime. Alors oui peut etre que ce serait innéficace car comme vous le dites des sources sont disponibles sur internet, des couteaux de toute taille sont aussi disponibles à vente en magasin, pourtant, la loi définit quel type de couteau peut être porté dans l'espace public, sa longueur de lame, son cran d'arret, etc, et c'est tout à fait normal, pourquoi en serait il autrement pour un système de cryptage qui dispose d'un meme niveau d'accessibilité ? C'est avant tout une question de fond, on ne fait pas de droit sur la forme, et il est parfaitement normal que la question soit posée et qu'il puisse y avoir légifération le cas échéant.
    Les terroristes n'utilisent pas toujours de chiffrement, sont quasi tous repérés, donc il est totalement inutile de limiter le chiffrement pour une sécurité illusoire. De plus, comment vérifier que les echanges chiffrés sont tous aux normes ? En les cassant tous ? En imaginant qu'il soit possible de restreindre le chiffrement, c'est rendre vulnérable toutes les entreprises à l'espionnage industriel, ce qui risque d'entrainer un exode massif des entreprises. Et pendant ce temps les terroristes utiliseront toujours des SMS en clair ou Telegram via... les messages de groupes qui sont actuellement non chiffrés et on ne saura toujours pas les arrêter, mais Mme Michu sera rassurée.

    Et je ne trouve pas normal au contraire que l'état nous interdise de porter un couteau de la taille que l'on veut sur soi.

    Citation Envoyé par BenBout62 Voir le message
    Et je n'ai pas dit que ceux qui chiffrent sont ceux qui vendent vos informations, j'ai pointé du doigt les sociétés qui mettent en avant la pseudo sécurité de leur plateforme ou encore des clauses mettant en avant la protection de la vie privée de leurs utilisateurs, alors qu'il n'en est nullement le cas et que les informations sont vendues à des Etats ou d'autres organisations privées commerciales. Les exemples ne manquent pas pourtant.
    D'accord sur ce point.



    Citation Envoyé par BenBout62 Voir le message
    Quel corrélation entre le pourcentage des dépenses publiques par rapport au PIB et la capacité de "nuisance" de l'Etat ? Rien qu'en parlant de "capacité de nuisance", on sent tout de suite l'emprise idéologique qui doit influer sur votre objectivité. Autant, j’admets volontiers que mes connaissances en systemes de cryptographie ne sont surement pas assez élevés pour poser un argumentaire technique pointu, autant le votre à ce sujet est vraiment un non sens.

    Ca me fait quand même sourire, parce que si vous venez débattre avec un ultra libéraliste, il va doucement rire en vous disant que la plupart des dépenses sont relatives aux dépenses dites "sociales". J'aurais bien utilisé le mot stupide pour cet argument moi aussi mais je fais preuve de respect pour votre point de vue, mème si je le trouve pour le coup vraiment fantasque et absolument non fondé. Donc cet argument fait de la norvège et de son gouvernement la puissance la plus nuisible d'Europe ...

    http://www.lemonde.fr/les-decodeurs/...4_4355770.html

    Rajoutez le budget de l'éducation nationale, de la justice, des subventions aux régions et aux autres collectivités territoriales, il vous reste quoi ? Ou est l'écrasante puissance publique ? Ou se cache donc la nuisance ? Dans une niche fiscale en Irlande ? C'est google ca.
    i.
    Le niveau de dépense de l'État montre à quel point il est important, et ne je jamais oublier qu'au final cet argent qui ne sort pas de nulle part ( C'est gratuit c'est l'état qui paye comme a dit un grand homme d'élection ) est le vôtre et le mien. Les prestations "sociales", sont une redistribution arbitraire ( Injuste diront certains, mais je préfère rester neutre, on pourrait atteindre un point Godwin, Vichy tout ça) des richesses, sans compter le système de retraite obligatoire ( et c'est bien là le problème ), l'éducation que l'on pourrait privatiser etc...

    Je suis pessimiste, je considère que l'état ne nous veut pas du bien, mais n'est qu'un amas de personnes défendant leurs intérêt propres, pouvant être opposés aux miens, et moins ces personnes auront de contrôle mieux cela vaudra.

  2. #22
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 368
    Points
    19 368
    Par défaut
    Citation Envoyé par BenBout62 Voir le message
    Je n'y vois rien de stupide personnellement
    Parce que tu ne comprends ni les enjeux ni de quoi on parle.

    Les chiffrements modernes reposent sur des algorithmes mathématiques connus de tous. N'importe quel développeur disposant de ces algorithmes, et ils sont très faciles à trouver, sera capable de les implémenter. Pire, les implémentations déjà réalisées sont très nombreuses, n'importe quel développeur débutant est capable de réaliser une application permettant d'utiliser ces méthodes de chiffrement. Donc ça n'empêchera en rien quelqu'un de mal intentionné de se protéger s'il s'en donne les moyens.

    Limiter la taille des clefs ou forcer l'implémentation de backdoors c'est diminuer la sécurité pour tous les autres, ceux qui seront contraints de respecter la législation (les SI des entreprises, le business des entreprises qui vendent via internet, et enfin les clients finaux, c'est à dire nous tous).

    Cela signifie :
    - faciliter le travail des criminels qui s'attaquent aux banques et aux transactions sur le réseau, et donc faire peser un risque ultra critique sur l'économie mondiale : Faire perdre la confiance qu'ont les gens sur l'économie numérique.
    - faciliter le travail de l'intelligence économique : En limitant la sécurité tu facilites l'espionnage industriel.

    Bref, ce n'est pas seulement stupide, c'est parfaitement irresponsable car cela fait peser trop de risques sur les infrastructures de communication actuelles.

    Je ne peux pas croire que les entreprises impliquées n'iront pas effectuer un lobbying de malade en emboitant les pas de l'ANSSI pour expliquer à nos gouvernants des conséquences de cette initiative.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #23
    Membre du Club
    Profil pro
    Inscrit en
    août 2009
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2009
    Messages : 9
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par BenBout62 Voir le message
    Je comprend parfaitement le point de vue et j'y adhère sur de nombreux points (pas tous évidemment, nous nous sommes compris). Comme se plaisait à le dire Churchill, la démocratie est le pire systeme politique après tous les autres. Je partage ce point de vue et je terminerais la dessus. Merci d'avoir débattu avec moi.
    Quelle valeur a ce que dit Churchill ou tel ou tel politicien qui pense que la guerre est quelque chose de raisonnable ? Si la démocratie est élire des élitocrates qui pensent tous que la guerre est l'unique solution aux problèmes du monde, qu'il y a des guerres justes, ou que l'intérêt de la nation prime avant le vivre-ensemble de l'humanité, comme c'est le cas actuellement, alors elle n'a pas grande valeur.

    Le problème ne vient pas du système politique mais des individus qui font les systèmes politiques, les citoyens qui votent et ceux qui se font élire. Si les politiciens n'ont aucune bonté, aucun sens pour l'humanité, et ne connaissent que l'ambition, ne pensent qu'à l'enrichissement individuel, des entreprises ou celui de la nation, comment peuvent-ils créer un monde de paix ?

    S'ils ne connaissent que la guerre en réponse aux conflits internationaux, comment peut-il y avoir intelligence ? Et si pour eux "intelligence" signifie surveillance ou espionnage des "étrangers" ou des "citoyens", alors l'on crée nécessairement les fondations d'une dictature qui ne dit pas son nom.

    Vouloir, pour un gouvernement, espionner toutes les communications à l'heure de la communication globale et des machines connectées, c'est vouloir contrôler les citoyens, et non pas les défendre. Si c'est ce que vous voulez, être contrôlé pour votre sécurité, qu'à cela ne tienne, mais cela ne réglera jamais les problèmes de sécurité étant donné que l'insécurité est créée par cette même manière de vivre, issue d'une pensée étroite et limitée.

    Il n'y a aucun problème avec le chiffrement, qui relève de la simple communication privée des citoyens entre eux, de manière locale ou mondiale, par contre, il y a problème avec l'autoritarisme étatique, la surveillance de masse, l'industrie de l'armement, les politiques guerrières et l'uniformisation politique qui relève plus du sectarisme de pensée nationaliste et communautaire que de la démocratie ouverte dans un monde qui est commun à tous les êtres humains.

  4. #24
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Il y a des lois limitant la taille des clés de chiffrement. Mais il suffit d'imbriquer les algos légaux ou d'en créer de nouveau. Le chiffrement peut s'effectuer coté client avec une clé générée dynamiquement ce qui empêche l'interception d'une clé par un tiers et la non possibilité de connaitre les données coté serveur.

    Un chiffrement avec du Javascript obfusqué a mort (en bytecode par exemple) via une clé se basant sur une adresse MAC, ca peut le faire.

    Soit tu deviens liberticide en interdisant tout chiffrement ou en imposant la création de backdoors (2 aveux d'incompétence), soit tu mets les moyens pour avoir des supercalculateurs et de bons hackers qui progresseront sans cesse.

  5. #25
    MikeRowSoft
    Invité(e)
    Par défaut
    C'est comme les immatriculation des automobiles.
    Soit pair, soit impair. (zéro étant ?)
    Cela dit se n'est pas la période ? (il fait chaud, c'est pollué et en plus c'est valable tous les jours.)
    Bonne vacances à ceux qui y sont encore et bon courage à ceux qui travail.

  6. #26
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    9 465
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 465
    Points : 13 463
    Points
    13 463
    Par défaut
    Citation Envoyé par MikeRowSoft Voir le message
    C'est comme les immatriculations des automobiles.
    Soit pair, soit impair. (zéro étant ?)
    Moi je dirais pair, car comme il n'est jamais tout seul dans ce contexte, il est obligatoirement précédé d'un autre chiffre et l'ensemble forme un nombre pair et voilà.
    En plus ça équilibre la balance : 5 nombres impairs et 5 nombres pairs, du coup, même si, d'un pur point de vue mathématique, ça (avec un c cédille) n'est pas vraiment vrai.

    Citation Envoyé par MikeRowSoft Voir le message
    [...] bon courage à ceux qui travail.
    À ceux qui lisent à la va-vite, merci de ne pas reproduire ce genre d'abomination qui, hélas, se répand comme une traînée de poudre...
    ceux qui travaillent , du verbe travailler, et oui...


    Citation Envoyé par MikeRowSoft
    Les principes exactes et naturels des matériaux étant régis par des comportements physiques et chimiques, les principes exactes et naturels de la biologie ne sont pas forcément les principes exactes et naturels de l’ingénierie.
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  7. #27
    Membre actif
    Inscrit en
    décembre 2005
    Messages
    251
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 251
    Points : 267
    Points
    267
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Il y a des lois limitant la taille des clés de chiffrement. Mais il suffit d'imbriquer les algos légaux ou d'en créer de nouveau. Le chiffrement peut s'effectuer coté client avec une clé générée dynamiquement ce qui empêche l'interception d'une clé par un tiers et la non possibilité de connaitre les données coté serveur.

    Un chiffrement avec du Javascript obfusqué a mort (en bytecode par exemple) via une clé se basant sur une adresse MAC, ca peut le faire.

    Soit tu deviens liberticide en interdisant tout chiffrement ou en imposant la création de backdoors (2 aveux d'incompétence), soit tu mets les moyens pour avoir des supercalculateurs et de bons hackers qui progresseront sans cesse.
    Quel limite ?

    La LCEN a libéré l'usage du chiffre il y'a 10 ans il est possible de chiffré avec une clé de n'importe quel longueur. La seule contrainte est qu'il faut fournir la clé aux autorités si nécessaire.

    Je ne comprend pas ce protocol cryptographique et cette histoire de chiffrement côté client. Comment l'interlocuteur peut il déchiffrer le message ?

  8. #28
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par sneb5757 Voir le message
    Quel limite ?

    La LCEN a libéré l'usage du chiffre il y'a 10 ans il est possible de chiffré avec une clé de n'importe quel longueur. La seule contrainte est qu'il faut fournir la clé aux autorités si nécessaire.

    Je ne comprend pas ce protocol cryptographique et cette histoire de chiffrement côté client. Comment l'interlocuteur peut il déchiffrer le message ?
    On peut dépasser le 2048 bits pour les clés ? On m'avait dit que sinon c'était considéré comme un cryptage de guerre.

    Un petit exemple de cryptage côté client (y a mieux mais je ne trouve plus) :

    https://jscrambler.com/fr/how-it-works


    Il suffit d'utiliser du cryptage côté Javascript avec des infos côté client, de le transmettre via une interface sécurisée (style WebSocket Secured), et d'obfusquer le code Javascript.
    Les données sont encodées au niveau client, avec une clé que toi seul connais, le serveur reçoit du déjà crypté (mot de passe crypté en amont + SSL) sans savoir comment le décrypter et le stocke donc tel quel, et on ne sait pas ce que ton Javascript a fait.
    Ca c'est le cadre d'un site web.

    Dans le cadre d'un Chat, il suffit de s'échanger sa clé secrète de la même manière, mais encryptée (c'est à dire qu'il faudrait faire "if SHA256('clé') pour tester la validité de la clé (ou te connecter) côté serveur. Cette clé cryptée d'après ton matos (par exemple) est quasiment inviolable, puisqu'elle est cryptée avant même d'être envoyée au serveur pour contrôle et ne repose sur aucune vraie logique.

  9. #29
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 014
    Points : 22 975
    Points
    22 975
    Par défaut
    Chiffrement* chiffrer* chiffrée*

    Citation Envoyé par LSMetag Voir le message
    On peut dépasser le 2048 bits pour les clés ? On m'avait dit que sinon c'était considéré comme un cryptage de guerre.
    Non, cela fait un petit bout de temps qu'il n'y a plus de limitations pour un usage "normal".

    et d'obfusquer le code Javascript
    La sécurité par l'obscurité ne vaut pas grand chose.

    mais encryptée (c'est à dire qu'il faudrait faire "if SHA256('clé') pour tester la validité de la clé
    Hein ?

    Cette clé cryptée d'après ton matos (par exemple) est quasiment inviolable, puisqu'elle est cryptée avant même d'être envoyée au serveur pour contrôle et ne repose sur aucune vraie logique.
    .

    Ou plus simplement, tu utilises des algorithmes connus et éprouvés de chiffrement symétriques avec échanges de clés basés sur du chiffrement asymétrique. Du TLS en quelque sorte, possiblement étendu pour ajouter le support d'autres algorithmes si besoin.

  10. #30
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Chiffrement* chiffrer* chiffrée*
    J'accepte la flagélation


    Citation Envoyé par Neckara Voir le message
    Non, cela fait un petit bout de temps qu'il n'y a plus de limitations pour un usage "normal".
    Tant mieux mais ça ne change pas grand chose vu qu'ils ont déjà du mal avec du 1024 bits.

    Citation Envoyé par Neckara Voir le message
    La sécurité par l'obscurité ne vaut pas grand chose.
    Ce n'est qu'une couche par dessus les autres. Si je fais quelque chose d'un peu sensible côté client, j'ai envie de le cacher, et bien. Il y a maintenant des solutions vraiment efficaces. Elles ne font pas que chiffrer le code de différentes façons, elles ajoutent des morceaux de code inutiles (leurres) ou qui font planter en cas de tentative de modification,... Bref, de quoi faire cogiter énormément. J'attends bien sûr Web Assembly pour avoir du vrai ByteCode.

    Après de toute façon dans ton Javascript, tu peux par exemple créer statiquement (par l'utilisateur) ou dynamiquement un "mot de passe maître". Tu utilises ensuite une bibliothèque pour chiffrer ce mot de passe maître + autres infos (login) que tu envoie (https://github.com/emn178/js-sha256). Le serveur reçoit les données chiffrées via le protocole SSL (d'où les WebSocket Secured), surcouche je sais. Le serveur a dans sa base uniquement des données chiffrées. Tout ce qu'il sait, c'est quel algorithme de chiffrage a été utilisé côté client (via des specs). Et donc, quand le client tape son id et son mot de passe, les chaînes chiffrées sont envoyées au serveur, qui va les comparer avec les chaînes chiffrées dans la base de données. Il n'y aura aucune donnée stockée en clair, qui circulera en clair, et qui ne pourront, au retour chez le client n'être déchiffrées que derrière un Javascript obfusqué à mort. L'utilisateur ne pourra pas réclamer son mot de passe et son login en cas de perte.

    Citation Envoyé par Neckara Voir le message
    Hein ?

    .

    Ou plus simplement, tu utilises des algorithmes connus et éprouvés de chiffrement symétriques avec échanges de clés basés sur du chiffrement asymétrique. Du TLS en quelque sorte, possiblement étendu pour ajouter le support d'autres algorithmes si besoin.
    Oui tu peux faire plus simple. Moi ça sort de mon cerveau en suractivité qui aime bien avoir des gardes fous dans tous les sens. C'est qu'un exemple parmi d'autres (très probablement meilleurs) de chiffrement de bout en bout. L'utilisateur crée son pass (ou on peut le créer à la Microsoft, selon la signature matérielle), et après plus personne ne sait ce qu'il devient, et seul quelqu'un qui connaît le pass en clair (l'utilisateur de base, ou celui à qui il a transmis le pass (pour un chat par exemple)

    Après tout, si le code Javascript est "éclairci", l'attaquant sait comment est créé le pass. Si le transfert n'est pas sécurisé ensuite, il intercepte la clé chiffrée. S'il connaît et la méthode de chiffrement et la clé chiffrée et certaines habitudes de l'utilisateur, il peut parfaitement récupérer le mot de passe, dont même côté serveur on n'a pas connaissance.

  11. #31
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 014
    Points : 22 975
    Points
    22 975
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Ce n'est qu'une couche par dessus les autres.
    On en a pas vraiment besoin.

    Si je fais quelque chose d'un peu sensible côté client, j'ai envie de le cacher, et bien.
    Non, la sécurité par l'obscurité ne vaut pas grand chose, l'utiliser pour tenter de fournir une quelconque sécurité serait une faille en elle-même.

    elles ajoutent des morceaux de code inutiles (leurres) ou qui font planter en cas de tentative de modification
    Et si on modifie tout simplement le script en entier ? .


    Ce que tu nous montres, c'est plus pour les applications propriétaires qui ne veulent pas que le citoyen voit, copie ou modifie leur code. Rien à voir avec une quelconque sécurité pour des opérations cryptographique.

    Après de toute façon dans ton Javascript, tu peux par exemple créer statiquement (par l'utilisateur) ou dynamiquement un "mot de passe maître". Tu utilises ensuite une bibliothèque pour chiffrer ce mot de passe maître + autres infos (login) que tu envoie (https://github.com/emn178/js-sha256). Le serveur reçoit les données chiffrées via le protocole SSL (d'où les WebSocket Secured), surcouche je sais. Le serveur a dans sa base uniquement des données chiffrées. Tout ce qu'il sait, c'est quel algorithme de chiffrage a été utilisé côté client (via des specs). Et donc, quand le client tape son id et son mot de passe, les chaînes chiffrées sont envoyées au serveur, qui va les comparer avec les chaînes chiffrées dans la base de données. Il n'y aura aucune donnée stockée en clair, qui circulera en clair, et qui ne pourront, au retour chez le client n'être déchiffrées que derrière un Javascript obfusqué à mort. L'utilisateur ne pourra pas réclamer son mot de passe et son login en cas de perte.
    Pour stocker le mot de passe, il vaut mieux utiliser une fonction de hachage. On a même des protocoles encore plus performants à base de 0-knowledge.

    Le fait de stocker les données chiffrées sur un serveur avec une clé seulement connue de l'utilisateur et possiblement dérivée de son mot de passe est en effet une bonne sécurité pour protéger sa vie privée.
    Cependant, utiliser JavaScript sur le navigateur du client me semble quelque peu dangereux, le navigateur pouvant être corrompu. Un client lourd me semble quelque peu plus "sûr".

    Moi ça sort de mon cerveau en suractivité qui aime bien avoir des gardes fous dans tous les sens.
    Je comprend, cependant tes propos ne sont pas toujours très clairs.
    De plus, penser et proposer de nouveaux modèle de sécurités demande de très fortes connaissances dans le domaine.

    Après tout, si le code Javascript est "éclairci", l'attaquant sait comment est créé le pass.
    Si cela pose problème, la méthode de création du pass comporte donc des failles.
    Il convient donc de corriger ces failles plutôt que de vouloir les cacher en offusquant le code.

  12. #32
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par Neckara Voir le message
    ...
    Désolé je sais que je ne suis pas forcément clair. J'écris au kilomètre ce que je pense sur le moment. Et je ne suis pas spécialiste c'est vrai, mais j'essaie de proposer des idées et de progresser.

    Le client lourd c'est mieux en effet pour les applis de chat et tout ça. Après pour un site web, je ne vois pas trop d'autre solution. Je n'ai pas envie de forcer l'utilisateur à installer une extension ou une VM. Je ne suis pas convaincu que l'obfuscation ne soit pas une bonne mesure de sécurité, si la lib utilisée est sérieuse et maintenue. Tu n'es pas non plus tenu d'utiliser une librairie tierce. Il y a des sites où tu t'abonnes et qui fonctionnent un peu comme un cloud dédié à l'obfuscation/chiffrement perpétuel, avec monitoring, d'un code.

    L'attaquant peut bien essayer de modifier le code chiffré ou d'injecter dans l'URL (que tu peux protéger par exemple avec du Base64). Il ne fera que planter l'application localement et momentanément.

    Après oui, le hachage est un très bon moyen aussi. Mais ce qui m'intéresse c'est que le serveur ne puisse pas voir les données en clair. Question de vie privée et de confidentialité en effet ^^

    C'est pour celà justement que les autorités se lèvent pour essayer de "contrer" ce genre de méthodes.

    Je pense qu'il y a peu de méthodes de sécurité inviolables. Comme les algorithmes de chiffrage. Truecrypt (et maintenant VeryCript) a comblé ça en imbriquant les solutions existantes de chiffrage, ce qui l'a fait "interdire" par le FBI.
    Soit tu as une excellente solution, soit tu imbriques d'autres solutions.

  13. #33
    Membre régulier
    Profil pro
    Inscrit en
    mars 2005
    Messages
    129
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2005
    Messages : 129
    Points : 88
    Points
    88
    Par défaut L'ordinateur quantique ?
    Tous les systèmes de cryptage actuels tomberont très prochainement. La NSA, la Chine et sans doute d'autres grandes nations ont déjà (et travaillent encore) sur la conception de supercalculateurs quantiques.

    Voilà ce que la France doit proposer à l'Europe. Au delà de l'enjeux de sécurité, c'est toute notre économie qui est menacée.

    (Les programmes révélés par Snowden montrent que déjà les USA conservent les échanges qui sont actuellement cryptés dans l'objectif de les décrypter plus tard).

    Enfin je ne parle même pas des progrès que cela permettrait de réaliser dans tous les domaines de recherche...

  14. #34
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 014
    Points : 22 975
    Points
    22 975
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Et je ne suis pas spécialiste c'est vrai, mais j'essaie de proposer des idées et de progresser.
    Mais cela n'est pas d'une grande aide si tu n'as pas connaissance de l'état de l'art du domaine.
    La communauté scientifiques a déjà apporté des réponses à plusieurs questions et a déjà exploré beaucoup de pistes. Plutôt que de proposer ses propres idées, il faudrait déjà voir ce qui a été fait de ce coté là.

    L'attaquant peut bien essayer de modifier le code chiffré ou d'injecter dans l'URL (que tu peux protéger par exemple avec du Base64). Il ne fera que planter l'application localement et momentanément.
    Pourquoi tant vouloir à cacher des failles plutôt que de les corriger ?
    S'il est possible de faire des injections dans l'URL, c'est déjà que ton site a de gros problèmes de sécurité.

    Après oui, le hachage est un très bon moyen aussi. Mais ce qui m'intéresse c'est que le serveur ne puisse pas voir les données en clair.
    Autant utiliser une fonction non-inversible .

    Soit tu as une excellente solution, soit tu imbriques d'autres solutions.
    Cela peut être très dangereux au niveau de la sécurité, il ne faut pas tout imbriquer n'importe comment.


    Citation Envoyé par Mandotnet Voir le message
    Tous les systèmes de cryptage actuels tomberont très prochainement. La NSA, la Chine et sans doute d'autres grandes nations ont déjà (et travaillent encore) sur la conception de supercalculateurs quantiques.
    Et on a déjà une nouvelle génération d'algorithmes prêt à l'emploi.

    Au passage, j'ai entendu dire que les ordinateurs quantiques sont une menace aux algorithmes de chiffrement à clé publique, mais que le chiffrement symétrique n'est pas menacé.

  15. #35
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Mais cela n'est pas d'une grande aide si tu n'as pas connaissance de l'état de l'art du domaine.
    La communauté scientifiques a déjà apporté des réponses à plusieurs questions et a déjà exploré beaucoup de pistes. Plutôt que de proposer ses propres idées, il faudrait déjà voir ce qui a été fait de ce coté là.
    Je suis d'accord mais c'est aussi pour concevoir mes applications que je raisonne tout d'abord en faisant abstraction de ce qui existe, même si je le connais, pour ensuite regarder si ce qui se fait correspond à mon besoin. Mais oui, je n'ai pas une grande connaissance mais cherche à appliquer ceci à un projet personnel

    Citation Envoyé par Neckara Voir le message
    Pourquoi tant vouloir à cacher des failles plutôt que de les corriger ?
    Ca n'implique pas "coder comme un sagouin" ! Tu code sérieusement en prenant soin de gérer les failles d'injection JS, SQL ou XHR (c'est juste des exemples parmi d'autres). Après si je travaille côté client sur une partie importante (ce qu'on ne devrait pas faire, je le sais, mais voila ^^), il faut aussi cacher son code pour qu'on n'ait pas idée du mode d'action de l'application, aussi bien codée et protégée soit-elle. C'est le problème du côté client. Ce ne sera plus un problème avec Web Assembly, que j'utiliserai à mon avis beaucoup.

    Citation Envoyé par Neckara Voir le message
    S'il est possible de faire des injections dans l'URL, c'est déjà que ton site a de gros problèmes de sécurité.
    Justement, je parlais des solutions typiques habituellement utilisées pour contrer ça

    Citation Envoyé par Neckara Voir le message
    Autant utiliser une fonction non-inversible .
    C'est ce dont je parlais.

    Citation Envoyé par Neckara Voir le message
    Cela peut être très dangereux au niveau de la sécurité, il ne faut pas tout imbriquer n'importe comment.
    Et on a déjà une nouvelle génération d'algorithmes prêt à l'emploi.
    Evidemment, ça doit être fait avec le plus grand soin et une architecture en béton, par un spécialiste (pas moi donc, mais je dois essayer pour mon projet perso, SAUF si les solutions new-age sont super)

    Citation Envoyé par Neckara Voir le message
    Au passage, j'ai entendu dire que les ordinateurs quantiques sont une menace aux algorithmes de chiffrement à clé publique, mais que le chiffrement symétrique n'est pas menacé.
    C'est une bonne chose pour que les services secrets arrêtent de nous demander des backdoors. Je ne pense pas qu'un simple hacker puisse se payer ça. C'est un budget d'Etat.

  16. #36
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 014
    Points : 22 975
    Points
    22 975
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Je suis d'accord mais c'est aussi pour concevoir mes applications que je raisonne tout d'abord en faisant abstraction de ce qui existe, même si je le connais, pour ensuite regarder si ce qui se fait correspond à mon besoin. Mais oui, je n'ai pas une grande connaissance mais cherche à appliquer ceci à un projet personnel
    Le problème, c'est que tu risques de réinventer la roue, voir même d'inventer la roue carrée et toute cabossée.

    Il y a des années de recherches sur le sujet, avec des chercheurs aux connaissances très pointues qui ont déjà pu démontrer en quoi ce que tu essayes de faire est une mauvaise idée.

    Après si je travaille côté client sur une partie importante (ce qu'on ne devrait pas faire, je le sais, mais voila ^^), il faut aussi cacher son code pour qu'on n'ait pas idée du mode d'action de l'application, aussi bien codée et protégée soit-elle. C'est le problème du côté client.
    Non, ça c'est avant tout un problème de conception. La sécurité par l'obscurité n'est pas une bonne sécurité, cela fait consensus dans le milieu depuis un bon bout de temps.

    Qu'on le protège pour des raisons de licences, pourquoi pas. Mais penser offrir une sécurité en faisant en sorte que l'utilisateur "n'ait pas idée du mode d'action" est au contraire générateur de failles, faisant moins attention à la sécurité réelle de l'application vu que "le code est offusqué".
    Une application correctement pensée n'a pas besoin d'offuscation pour sa sécurité.

    C'est ce dont je parlais.
    Une fonction de chiffrement est inversible. Tu parlais bien dans tes posts précédent d'utiliser une fonction de chiffrement pour cela.

    SAUF si les solutions new-age sont super
    Tu as déjà plein de solutions à ce niveau là. Tu as même des tentatives sur le chiffrement homomorphique.
    Bref, tu as beaucoup de littérature très intéressante dans ce domaine.

  17. #37
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par Neckara Voir le message
    ...
    Je vois en effet que j'ai beaucoup à lire ^^ Merci pour toutes ces infos. Et en effet, compter sur de l'obscurcissement de code n'est pas une sécurité sur laquelle on peut se reposer. On est bien d'accord. Je voyais ça comme une couche finale sur un vrai travail de qualité.

    Oui c'est sûr que les chercheurs qui ont planché des années ont créé des trucs énorme par rapport à un mec lambda qui a cherché pendant quelques heures ^^'

    Tu as raison, c'était inversible. J'avais pas les yeux en face de trous. Dans ce cas, comment retranscrire des données chez un client avec du non inversible ? Pour faire du login/mot de passe, c'est bien mais ce n'est valable que pour de l'émission. Tu es obligé de déchiffrer ce que tu reçois.

    Après, pour les problèmes de conception, je ne peux pas trop dire. Comment empêcher un serveur de connaître la moindre chose sur toi, rendre caduques les possibles interceptions en cas de faille zéro day d'un protocle de transfert, tout en empêchant également le reverse engineering ?

  18. #38
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    décembre 2011
    Messages
    9 014
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 9 014
    Points : 22 975
    Points
    22 975
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    Après, pour les problèmes de conception, je ne peux pas trop dire. Comment empêcher un serveur de connaître la moindre chose sur toi, rendre caduques les possibles interceptions en cas de faille zéro day d'un protocle de transfert, tout en empêchant également le reverse engineering ?
    Avoir une architecture décentralisée (?).

  19. #39
    Expert confirmé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2009
    Messages
    1 030
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 1 030
    Points : 4 120
    Points
    4 120
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Avoir une architecture décentralisée (?).
    Idée très intéressante. Mais quid de l'apparition de données en clair côté serveur, passibles de réquisition par les FAI ou services secrets ?

  20. #40
    Membre régulier
    Profil pro
    Consultant
    Inscrit en
    janvier 2011
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : Espagne

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2011
    Messages : 77
    Points : 118
    Points
    118
    Par défaut
    C'est pas en interdisant le chiffrage des messages que l'on va en finir avec le terrorisme, mais en ayant des services de renseignement plus efficaces et mieux organisés que les terroristes. Mais enfin, le terrorisme a bon dos et c'est l'excuse parfaite pour faire ce que le politiciens adorent, interdire et empêcher la societé d'evoluer vers lá oú elle veut aller.

Discussions similaires

  1. Réponses: 9
    Dernier message: 07/09/2011, 16h05
  2. Réponses: 2
    Dernier message: 05/12/2003, 12h37
  3. lancer une page asp à partir du shell dos
    Par sqlnet dans le forum ASP
    Réponses: 3
    Dernier message: 19/11/2003, 16h20
  4. |VB6] [Réseau] Lancer une page ASP
    Par Delphi-ne dans le forum VB 6 et antérieur
    Réponses: 9
    Dernier message: 18/10/2002, 17h10
  5. [VBA-E] [Excel] Lancer une macro à une heure donnée
    Par Lysis dans le forum Macros et VBA Excel
    Réponses: 2
    Dernier message: 16/10/2002, 13h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo