1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
Oui, c'est sûr que ça n'a rien de magique, une faille dans une lib privilégiée peut mettre à terre tout le système. Ça n'empêche pas que ça offre quand même des possibilités intéressantes qui seraient très difficiles à faire autrement, et impossibles à faire de façon portable. Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
Je sais pas exactement comment c'est géré en interne, mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Pour moi, c'est quand même sacrément jouer avec le feu.
Comme je l'ai dit avant, le but n'est pas de remplacer les sécurités de l'OS, mais de fournir un moyen pratique et surtout portable d'avoir certaines garanties au niveau sécurité. Si vraiment on a besoin d'une sécurité absolue, il faudra envisager autre chose, mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS : créer des contextes d'exécution séparés, régler les permissions, prévoir un système de communication inter-processus qui pourra passer les barrières mises en place, etc. Et au final, on pourra aussi très facilement oublier un détail qui va complètement détruire tout l'édifice ;)
Admettons que ton code essaie d'ouvrir un fichier. La méthode d'ouverture de fichier va appeler un SecurityManager (c'est l'objet responsable de l'application de la politique de sécurité) qui va examiner la pile d'appels de méthodes, ce qui va lui indiquer la provenance du code qui essaie d'accéder au fichier (en général, la politique se définit au niveau des fichiers JAR, donc le SecurityManager saura de quel JAR vient le code qui essaie d'ouvrir le fichier)
À partir de ça, il va simplement regarder ses règles de sécurité, qui vont dire par exemple "x.jar peut accéder sans limites au système de fichier, y.jar peut seulement lire les fichiers dans /tmp, et z.jar n'a pas la permission d'accéder au fs", et va soit autoriser l'opération, soit envoyer une exception.
Là où la VM apporte un plus, c'est justement qu'elle donne la possibilité de fixer les permissions jar par jar, et pas juste une permission au niveau du processus complet.
Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted", et on voudra que le code "trusted" puisse faire ce qu'il a besoin de faire, sans que le code "non-trusted" puisse faire n'importe quoi. C'est impossible à faire si la sécurité est gérée uniquement par l'OS, parce que les permissions sont au niveau process. Là, on veut quelque chose de plus fin. En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
- les connexions réseau
- le chargement de classes supplémentaires
- l'appel à System.exit() (termine la VM)
- la génération de byte code
- l'accès aux membres privés ou protégés des classes
- et surement plein de choses que j'oublie
Bien évidemment, chacune des permissions est complètement paramétrable, on peut par exemple autoriser les connexions sur un port précis d'un serveur précis et refuser tout le reste.
Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité
Le but n'est pas de remplacer l'OS. Le but, c'est de fournir un environnement limité qui servira à exécuter du code dans lequel on n'a pas forcément confiance. Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
En Java, la VM est capable d'analyser la pile d'appel et de déterminer l'origine du code qui tente d'effectuer une opération privilégiée (comme l'accès à un fichier) À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions. Si du code "non-trusted" (du code télécharger sur Internet, par exemple) tente d'effectuer une opération sans y être explicitement autorisé, il y aura une exception. Mais à côté de ça, le code "trusted" (fourni par l'application) pourra avoir des permissions plus souples.
Par défaut, ce mécanisme est désactivé (n'importe quel code peut faire n'importe quoi), mais ça s'active et s'utilise très facilement.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local. C'est possible parce qu'on peut donner des permissions différentes aux classes de base et à celles téléchargées.
Non, je parle de vrai sandboxing, où on pourra donner des privilièges différents suivant l'origine du code au sein du même processus.
L'exemple type, c'est une applet Java : même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
L'évolution de Java passe par le Java_Community_Process, dont Sun est membre, mais ils ne sont pas seuls. Il y a aussi des représentation du logiciel libre là-dedans (fondation Apache en particulier)
Le but, c'est d'arriver à prouver l'existence du contrat et son contenu. Avec un document publié sur Internet, ça me semble relativement facile à faire, grâce aux caches des moteurs de recherche.
Même avec du code bien écrit, tu auras beaucoup de mal à implémenter du sandboxing sans VM, alors que c'est très simple à faire en Java (et sans doute aussi en .Net)
Je pense que ça doit avoir une valeur légale même en dehors des US. Vu la forme du texte, ça doit très certainement être assimilable à un contrat, et donc valide devant un tribunal.
Une des rares utilités du goto, c'est pour les langages qui ne supportent pas les exceptions (C, par exemple), ça permet de simplifier le code de gestion d'erreur. C'est utilisé couramment dans le noyau Linux, par exemple.
Dans un langage avec des exceptions, par contre, j'ai vraiment du mal à voir à quoi ça sert.
Si tu conçois toi-même le système défi-réponse, en effet, c'est possible d'utiliser un hash du mot de passe (avec le problème que tu soulignes, la connaissance du hash seul suffit pour avoir accès au service)
Mais suivant les cas, il n'y a pas forcément le choix. Pour du HTTP Digest par exemple, il faut des mots de passe stockés en clair sur le serveur.
XHTML est du vrai XML, à 100% (c'est d'ailleurs ça qui fait son intérêt) En pratique, ça veut surtout dire 2 choses :
- ça supporte les namespaces (ce qui permet d'inclure d'autres données XML, comme du MathML, du SVG ou du XUL)
- le parser est très strict, la moindre erreur de syntaxe empêchera le rendu de la page
En pratique, c'est très peu utilisé de façon stricte (c'est-à-dire servi avec un mime type XML), justement parce que IE ne le supporte pas du tout (je sais plus trop ce qu'il fait, soit il propose d'enregistrer le fichier sur disque, soit il affiche l'arbre XML)
Il y a quand même une légère différence entre une « censure » exercée par une société privée sur son propre site web et une vraie censure officielle, organisée par un État pour museler ceux qui n'approuvent pas son action.
Ça peut aussi être des développeurs qui utilisent un langage moderne qui se passe de ce genre d'artifices pour avoir une gestion efficace et sûre de la mémoire.
Faudra un jour m'expliquer comment on peut transposer tel quel des principes qui viennent du monde du logiciel vers un travail artistique quelconque...
Le principe du logiciel libre, c'est avant tout de permettre aux utilisateurs d'avoir les meilleurs logiciels possibles, en leur permettant de participer activement à leur développement et en leur offrant la possibilité de les adapter à leur utilisation.
Est-ce que cette philosophie est applicable à un travail artistique ? Non, je ne pense pas.
Après, il y a autre chose, c'est la réutilisation. Là, on peut effectivement trouver un parallèle entre logiciel libre et œuvre artistique (surtout au niveau des photos, musiques, dessins, logos, etc. qui peuvent facilement être inclus dans d'autres travaux) Mais là aussi, on est dans le domaine artistique, qui n'a pas grand chose à voir avec le logiciel (aussi élégant soit-il, le code source d'une application n'a pas d'autre but que de fournir un outil pour accomplir une tâche)
This version of the Open XML Format SDK is pre-release software, so the APIs are currently under development.
C'est une version de développement, donc à destination des développeurs uniquement. MS ne veut pas que cette version non-finale soit utilisée pour autre chose, ils interdisent donc sa redistribution. Ça ne veut pas dire que ça sera pareil pour la version finale (ça serait vraiment stupide qu'elle ne soit pas redistribuable)
Le lien que j'ai suivi vient du blog, il est donné vers la fin du message. Je pense que tu es passé par le lien http://www.codeplex.com/aspnet qui n'a visiblement pas encore été mis à jour avec la nouvelle license.
Bah perso, j'ai pu télécharger un zip (sans qu'on me demande d'accepter quoi que ce soit comme license), et j'ai du code source avec un fichier license.htm, qui contient bien le texte de la license MS-PL. Bref, ça m'a l'air parfaitement correct.
Une clé USB n'est pas un bon exemple de SSD. Même si les puces de mémoire flash sont sans doute plus ou moins les mêmes, le contrôleur n'a rien à voir, et c'est à ce niveau qu'on trouve les plus grosses différences entre un bon et un mauvais SSD. Une clé USB a certainement un contrôleur extrêmement primitif, et je ne pense pas que ça soit une bonne idée de l'utiliser pour autre chose que du transport de fichiers d'une machine à l'autre.
Pour les perfs, il y a d'énormes différences d'un modèle à l'autre. Il existe d'excellents SSD (Intel, Samsung, certains OCZ), mais à côté de ça, il y a énormément de bouses pratiquement inutilisables en raison de latence en écriture particulièrement haute (c'est justement ce qu'on essaie de mesurer ici)
Les débits annoncés par les constructeurs et repris par la plupart des tests qu'on trouve sur le web n'ont à peu prêt aucun intérêt. Ce qui fait la puissance d'un SSD, plus que les débits, c'est avant tout une latence de l'ordre du dixième de miliseconde. Les mauvais SSD peuvent avoir des latences qui grimpent à plus d'une seconde quand il y a beaucoup d'écritures sur des petits fichiers, ce qui provoque des "freezes" du système.
Par contre, si le key-loging est possible, je souhaite bonne chance à ceux qui tente de trouver le code *cliqué* de manière aléatoire plutôt que tapé.
Suffit de faire une capture de la zone sous le pointeur de la souris, ça a rien de compliqué. Ça rend le keylogger un peu plus lourd et plus compliqué, mais ça n'a rien d'impossible.
De façon plus générale, tant qu'un utilisateur est identifié uniquement par un mot de passe qu'il doit entrer à chaque login, il sera vulnérable à une attaque par keylogger, peu importe la façon dont il va l'entrer. Si on veut augmenter la sécurité, il faut demander une deuxième information, qui change à chaque login (ça peut être aussi simple qu'une liste à biffer)
Beaucoup de sites qui envoient un mot de passe par email ne renvoie pas le mot de passe courant, mais un nouveau généré aléatoirement (comme ça, pas de problème pour ne pas pas garder le mot de passe en clair)
En effet, ça ne change pas grand chose. Tant que le système se contente d'essayer de rendre plus compliqué le travail d'un keylogger, ça ne va pas fondamentalement améliorer la sécurité.
Ce qu'il faut, c'est un système qui exige d'entrer un code différent à chaque connexion (peu importe la forme que ça prend, même une bête liste de numéros sur papier améliore déjà considérablement la sécurité)
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
1°) vu que c'est le même espace mémoire tu ouvre quand même une grosse boite de pandore (suffit d'une faille dans un jar "autorisé", ou un code volontairement malicieux (si c'est possible), et tout le système s'écroule, sachant que tu as accés à la mémoire du jar autorisé vu que tu es dans le même processus (vm?)).
Oui, c'est sûr que ça n'a rien de magique, une faille dans une lib privilégiée peut mettre à terre tout le système. Ça n'empêche pas que ça offre quand même des possibilités intéressantes qui seraient très difficiles à faire autrement, et impossibles à faire de façon portable. Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
2°) et il gère comment les sécurité lors de la compilation et de l'execution du code binaire ? Les optimisation ne risquent elles pas de gener la VM ? Et les tranpolines , comment il retrouve ses petits ?
Je sais pas exactement comment c'est géré en interne, mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
est il possible de révoquer les permissions sans redemarrer les process ? (le système de base de linux ne le permet pas, mais selinux si).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Pour moi, c'est quand même sacrément jouer avec le feu.
Comme je l'ai dit avant, le but n'est pas de remplacer les sécurités de l'OS, mais de fournir un moyen pratique et surtout portable d'avoir certaines garanties au niveau sécurité. Si vraiment on a besoin d'une sécurité absolue, il faudra envisager autre chose, mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS : créer des contextes d'exécution séparés, régler les permissions, prévoir un système de communication inter-processus qui pourra passer les barrières mises en place, etc. Et au final, on pourra aussi très facilement oublier un détail qui va complètement détruire tout l'édifice ;)
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Admettons que ton code essaie d'ouvrir un fichier. La méthode d'ouverture de fichier va appeler un SecurityManager (c'est l'objet responsable de l'application de la politique de sécurité) qui va examiner la pile d'appels de méthodes, ce qui va lui indiquer la provenance du code qui essaie d'accéder au fichier (en général, la politique se définit au niveau des fichiers JAR, donc le SecurityManager saura de quel JAR vient le code qui essaie d'ouvrir le fichier)
À partir de ça, il va simplement regarder ses règles de sécurité, qui vont dire par exemple "x.jar peut accéder sans limites au système de fichier, y.jar peut seulement lire les fichiers dans /tmp, et z.jar n'a pas la permission d'accéder au fs", et va soit autoriser l'opération, soit envoyer une exception.
Là où la VM apporte un plus, c'est justement qu'elle donne la possibilité de fixer les permissions jar par jar, et pas juste une permission au niveau du processus complet.
Je te met un contexte non_trusted* en level non_trusted* et catégorie non_trusted* sur le code par défaut, ben ton appli elle va s'amuser a faire quoi que ce soit.
Ben justement, on peut avoir dans la même VM du code "trusted" et du code "non-trusted", et on voudra que le code "trusted" puisse faire ce qu'il a besoin de faire, sans que le code "non-trusted" puisse faire n'importe quoi. C'est impossible à faire si la sécurité est gérée uniquement par l'OS, parce que les permissions sont au niveau process. Là, on veut quelque chose de plus fin. En plus de ça, les permissions qu'on peut régler ne concernent pas que l'accès au système de fichiers, on peut aussi autoriser/interdire :
- les connexions réseau
- le chargement de classes supplémentaires
- l'appel à System.exit() (termine la VM)
- la génération de byte code
- l'accès aux membres privés ou protégés des classes
- et surement plein de choses que j'oublie
Bien évidemment, chacune des permissions est complètement paramétrable, on peut par exemple autoriser les connexions sur un port précis d'un serveur précis et refuser tout le reste.
Ensuite c'est la difficulté a implémenté cette solution, mais intrinsèquement la vm n'apporte pas un "plus de sécurité", elle apporte bien un "plus de sécurité" car elle gère plus facilement la sécurité
Le but n'est pas de remplacer l'OS. Le but, c'est de fournir un environnement limité qui servira à exécuter du code dans lequel on n'a pas forcément confiance. Ça permet par exemple d'avoir une application qui pourra être étendue par des plugins tiers qui ne pourront pas faire n'importe quoi.
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
En Java, la VM est capable d'analyser la pile d'appel et de déterminer l'origine du code qui tente d'effectuer une opération privilégiée (comme l'accès à un fichier) À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions. Si du code "non-trusted" (du code télécharger sur Internet, par exemple) tente d'effectuer une opération sans y être explicitement autorisé, il y aura une exception. Mais à côté de ça, le code "trusted" (fourni par l'application) pourra avoir des permissions plus souples.
Par défaut, ce mécanisme est désactivé (n'importe quel code peut faire n'importe quoi), mais ça s'active et s'utilise très facilement.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local. C'est possible parce qu'on peut donner des permissions différentes aux classes de base et à celles téléchargées.
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
L'exemple type, c'est une applet Java : même si la VM qui la fait tourner a tous les privilèges de l'utilisateur courant, l'applet ne pourra pas accéder aux fichiers du disque, ni établir de connexions réseaux avec d'autres serveurs que celui d'où vient le code.
[^] # Re: Drôle
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Promesses ? C'est nouveau dans l'industrie ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Le but, c'est d'arriver à prouver l'existence du contrat et son contenu. Avec un document publié sur Internet, ça me semble relativement facile à faire, grâce aux caches des moteurs de recherche.
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Les trolls ne meurent jamais
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: GOTO : Nostalgie...
Posté par Buf (Mastodon) . En réponse au journal Sortie de PHP 5.3. Évalué à 10.
Dans un langage avec des exceptions, par contre, j'ai vraiment du mal à voir à quoi ça sert.
[^] # Re: À ta place...
Posté par Buf (Mastodon) . En réponse au journal De la sécurité des informations personnelles sur Internet. Évalué à 1.
Mais suivant les cas, il n'y a pas forcément le choix. Pour du HTTP Digest par exemple, il faut des mots de passe stockés en clair sur le serveur.
[^] # Re: À ta place...
Posté par Buf (Mastodon) . En réponse au journal De la sécurité des informations personnelles sur Internet. Évalué à 2.
[^] # Re: Web standards
Posté par Buf (Mastodon) . En réponse au journal Get The Facts : le retour. Évalué à 4.
- ça supporte les namespaces (ce qui permet d'inclure d'autres données XML, comme du MathML, du SVG ou du XUL)
- le parser est très strict, la moindre erreur de syntaxe empêchera le rendu de la page
En pratique, c'est très peu utilisé de façon stricte (c'est-à-dire servi avec un mime type XML), justement parce que IE ne le supporte pas du tout (je sais plus trop ce qu'il fait, soit il propose d'enregistrer le fichier sur disque, soit il affiche l'arbre XML)
[^] # Re: Pertinence de Java
Posté par Buf (Mastodon) . En réponse à la dépêche Yahoo libère son Hadoop. Évalué à 5.
Java Enterprise Edition ? Ça fait (entre autres) serveur web, c'est très puissant, très utilisé, et pas vraiment à la rue niveau performances.
[^] # Re: En parlant du Monde
Posté par Buf (Mastodon) . En réponse au journal Voyage en Censurie, suite. Évalué à 0.
[^] # Re: la nouvelle version du jounal lien est sortie
Posté par Buf (Mastodon) . En réponse au journal Valgrind fonctionnel sous OS X. Évalué à -1.
[^] # Re: NC en photo
Posté par Buf (Mastodon) . En réponse au journal De la paranoïa du NC et de l'égoïsme du ND. Évalué à 9.
Le principe du logiciel libre, c'est avant tout de permettre aux utilisateurs d'avoir les meilleurs logiciels possibles, en leur permettant de participer activement à leur développement et en leur offrant la possibilité de les adapter à leur utilisation.
Est-ce que cette philosophie est applicable à un travail artistique ? Non, je ne pense pas.
Après, il y a autre chose, c'est la réutilisation. Là, on peut effectivement trouver un parallèle entre logiciel libre et œuvre artistique (surtout au niveau des photos, musiques, dessins, logos, etc. qui peuvent facilement être inclus dans d'autres travaux) Mais là aussi, on est dans le domaine artistique, qui n'a pas grand chose à voir avec le logiciel (aussi élégant soit-il, le code source d'une application n'a pas d'autre but que de fournir un outil pour accomplir une tâche)
[^] # Re: Effectivement on est pas vendredi
Posté par Buf (Mastodon) . En réponse au journal Oui je sais, on est pas Vendredi. Évalué à 1.
C'est une version de développement, donc à destination des développeurs uniquement. MS ne veut pas que cette version non-finale soit utilisée pour autre chose, ils interdisent donc sa redistribution. Ça ne veut pas dire que ça sera pareil pour la version finale (ça serait vraiment stupide qu'elle ne soit pas redistribuable)
[^] # Re: ASP.NET MVC
Posté par Buf (Mastodon) . En réponse au journal ASP.NET MVC sous licence libre. Évalué à 1.
[^] # Re: ASP.NET MVC
Posté par Buf (Mastodon) . En réponse au journal ASP.NET MVC sous licence libre. Évalué à 2.
Je suis passé par ce lien : http://go.microsoft.com/fwlink/?LinkId=144444
[^] # Re: Intéressant
Posté par Buf (Mastodon) . En réponse au journal [SSD] Mesure de la latence d'écriture aléatoire sur disque. Évalué à 3.
[^] # Re: Intéressant
Posté par Buf (Mastodon) . En réponse au journal [SSD] Mesure de la latence d'écriture aléatoire sur disque. Évalué à 2.
Les débits annoncés par les constructeurs et repris par la plupart des tests qu'on trouve sur le web n'ont à peu prêt aucun intérêt. Ce qui fait la puissance d'un SSD, plus que les débits, c'est avant tout une latence de l'ordre du dixième de miliseconde. Les mauvais SSD peuvent avoir des latences qui grimpent à plus d'une seconde quand il y a beaucoup d'écritures sur des petits fichiers, ce qui provoque des "freezes" du système.
[^] # Re: sécurité vs facilité
Posté par Buf (Mastodon) . En réponse au journal Les créateurs de formulaires sont complètement abrutis.... Évalué à 4.
Suffit de faire une capture de la zone sous le pointeur de la souris, ça a rien de compliqué. Ça rend le keylogger un peu plus lourd et plus compliqué, mais ça n'a rien d'impossible.
De façon plus générale, tant qu'un utilisateur est identifié uniquement par un mot de passe qu'il doit entrer à chaque login, il sera vulnérable à une attaque par keylogger, peu importe la façon dont il va l'entrer. Si on veut augmenter la sécurité, il faut demander une deuxième information, qui change à chaque login (ça peut être aussi simple qu'une liste à biffer)
[^] # Re: sécurité vs facilité
Posté par Buf (Mastodon) . En réponse au journal Les créateurs de formulaires sont complètement abrutis.... Évalué à 6.
[^] # Re: Mouhahahaha
Posté par Buf (Mastodon) . En réponse au journal Il faut sauver le soldat %. Évalué à 5.
[^] # Re: 3D Secure
Posté par Buf (Mastodon) . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 5.
Ce qu'il faut, c'est un système qui exige d'entrer un code différent à chaque connexion (peu importe la forme que ça prend, même une bête liste de numéros sur papier améliore déjà considérablement la sécurité)