Sécurité et mot de passe

par AB » 09 sept. 2011, 21:14

Et les systèmes que font les banques en ligne actuellement... ?
On a déjà ssl (fort heureusement), et pour contrer d'éventuels keyloggers, on a des claviers virtuels changeants à chaque fois à actionner avec la souris.
Chez la banque qui distribue aussi du courrier accessoirement, le clavier virtuel fonctionne même au survol prolongé de chaque touche ...
Avec ça normalement ça va ?

Bah c'est le mieux qu'on puisse faire actuellement... Sans ce système, comme le disait plus faut Cyrano, il faut s'assurer que l'on a une machine saine et éviter les accès depuis les lieux publics.

Quant au ssl c'est aussi le mieux qu'on sait faire tant que...

par **Dr@ke** » 09 sept. 2011, 21:09

Et aussi, mais ensuite je m'arrête là.

Comme je l'avais déjà dis dans le passé ici, pour moi 99% des mots de passes qui sont trouvés, crackés et utilisés sont par la faute de son possesseur, ou par un autre moyen qu'un véritable crackage.

- Mot de passe simple, (prénom de sa fille ou nom de son chien)
- Même mot de passe utilisé partout, (genre le mec s'inscrit sur un forum de cracks, et hop les mecs le récupèrent et l'essayent à un autre endroit....)
- Simple Keylogger, (récupérée par exemple en téléchargeant un crack).
- Autres Virus récupérés bêtement
- Mot de passe en clair dans un fichier texte sur le disque dur
- Mot de passe noté sur un Postit sur l'écran.
...

Il y a quelques mois, une personnalité americaine s'est fait hacker son site par un gas.
Bien le gas avait simplement parcouru son blog, sa bio et l'avait trouvé par ce moyen.
Le pire c'est que le mec a trouvé un job en sécurité informatique ensuite lol, ok super en fait il savait simplement lire

par AB » 09 sept. 2011, 21:02

@ Nagol
Oui mais d'un autre côté en surenchérissant dans l'autre sens, on pourrait dire qu'il ne sert donc à rien de protéger les accès administrateurs... La protection est donc une histoire de juste équilibre pour éviter que l'accès soit trop facilement piratable. Et quand on peut améliorer la sécurité par des techniques simples il ne faut pas s'en priver.

Choisir un mot de passe assez long avec quelques caractères spéciaux n'est pas très difficile. De même la technique du grain de sable que je mentionnait plus haut ne l'est pas non plus et avec la généralisation des accès wifi je me dis que cela n'est pas un luxe...

Par ailleurs se serait bien bien d'arrêter de parler de md5... on se croirait encore à l'époque des débuts de php4. Le sha256 est supporté par les lib javascript, php 5.1.2 (et MySQL 5.5.5) et est quand même "un poil mieux" que le md5, alors pourquoi s'en priver ?

par **jojolapine** » 09 sept. 2011, 20:37

Et les systèmes que font les banques en ligne actuellement... ?
On a déjà ssl (fort heureusement), et pour contrer d'éventuels keyloggers, on a des claviers virtuels changeants à chaque fois à actionner avec la souris.
Chez la banque qui distribue aussi du courrier accessoirement, le clavier virtuel fonctionne même au survol prolongé de chaque touche ...
Avec ça normalement ça va ?

par **Dr@ke** » 09 sept. 2011, 20:32

C'est vrai, je dirai à ma manière que c'est surtout d'éviter que le premier branleur venue vienne bousiller des heures de travail.
Pour les reste, ils ont autre-chose à faire ou à s'occuper.
Ou si on a bien fait notre job, respectent un peu le travail fournit... -> enfin là, peut-être que je crois un peu au père-noël

par **Nagol** » 09 sept. 2011, 19:24

savoir que l'on utilise md5 ne permet pas de retrouver le mot de passe d'origine.
A la rigueur, il facilite le travail d'attaque par dictionnaire, mais toute tentative de ce type sera sur les techniques les plus utilisées en 1er (soit hash et md5)
le crack de md5 ca se fait très bien maintenant, et un md5 ça se redonnait à l'oeil, rien que le fait que ça fait 32 caractères fixe... de toutes les manières faut bien se rendre compte que la sécurité informatique c'est une illusion, que le fait que quelqu'un ne se fasse pas attaquer (par des gens compétents) signifie juste qu'il a soi 1) de la chance, ou soi 2) ne représente aucun intérêt à être attaqué.
Mon idée était plutôt de dire que ce n'est pas le fait d'afficher ou cacher que c'est du md5 qui fera que c'est plus sécurisé.
La sécurisation en cachant des données, c'est jamais fiable

ouais c'est certain mais je surenchérissais en disant que la sécurité informatique ça tient plus de la croyance et de la prière que du paramétrage

par **zeus** » 09 sept. 2011, 14:35

savoir que l'on utilise md5 ne permet pas de retrouver le mot de passe d'origine.
A la rigueur, il facilite le travail d'attaque par dictionnaire, mais toute tentative de ce type sera sur les techniques les plus utilisées en 1er (soit hash et md5)
le crack de md5 ca se fait très bien maintenant, et un md5 ça se redonnait à l'oeil, rien que le fait que ça fait 32 caractères fixe... de toutes les manières faut bien se rendre compte que la sécurité informatique c'est une illusion, que le fait que quelqu'un ne se fasse pas attaquer (par des gens compétents) signifie juste qu'il a soi 1) de la chance, ou soi 2) ne représente aucun intérêt à être attaqué.

Mon idée était plutôt de dire que ce n'est pas le fait d'afficher ou cacher que c'est du md5 qui fera que c'est plus sécurisé.
La sécurisation en cachant des données, c'est jamais fiable

par **Nagol** » 09 sept. 2011, 12:29

savoir que l'on utilise md5 ne permet pas de retrouver le mot de passe d'origine.
A la rigueur, il facilite le travail d'attaque par dictionnaire, mais toute tentative de ce type sera sur les techniques les plus utilisées en 1er (soit hash et md5)

le crack de md5 ca se fait très bien maintenant, et un md5 ça se redonnait à l'oeil, rien que le fait que ça fait 32 caractères fixe... de toutes les manières faut bien se rendre compte que la sécurité informatique c'est une illusion, que le fait que quelqu'un ne se fasse pas attaquer (par des gens compétents) signifie juste qu'il a soi 1) de la chance, ou soi 2) ne représente aucun intérêt à être attaqué.

par **zeus** » 09 sept. 2011, 09:51

savoir que l'on utilise md5 ne permet pas de retrouver le mot de passe d'origine.
A la rigueur, il facilite le travail d'attaque par dictionnaire, mais toute tentative de ce type sera sur les techniques les plus utilisées en 1er (soit hash et md5)

par AB » 08 sept. 2011, 22:22

J'avais lu un article sur un encodage coté client, faudrait que je remette la main dessus.
Mais ca pose toujours un problème, vu que c'est la chaine hachée qui est envoyée pour comparaison,le simple fait de récupérer cette chaine permet de se connecter via le formulaire...

... sauf si le mot de passe est concaténé à un grain de sel à chaque fois différent. Dans ce cas la chaine récupérée n'est valide qu'une seule fois.

Pour ceux que cela intéressent voici un lien qui permet de faire du sha256 en javascript.

par **momox** » 08 sept. 2011, 21:37

J'avais lu un article sur un encodage coté client, faudrait que je remette la main dessus.
Mais ca pose toujours un problème, vu que c'est la chaine hachée qui est envoyée pour comparaison,le simple fait de récupérer cette chaine permet de se connecter via le formulaire...
La seule solution valable pour la protection des formulaire d'authentification c'est le SSL...

par **Nagol** » 08 sept. 2011, 21:24

De toutes façons il y a un bug commun à tous les formulaires, c'est l'interface chaise-clavier.
Faut que je poste le bug ou ? Sur le bugtracker de mozilla, php ou de la w3c ?
Comme aurait dit Nagol pendant un temps : « stoi le bug »

squi qui pepcak?

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?
On appelle ça le PHP Et ça ne règlerait rien puisque le problème de départ est la qualité du mot de passe mesurée selon sa complexité. Ajoutons à ça le problème de la transmission en clair sur le réseau de ce même mot de passe entre client et serveur faute d'une connexion SSL et la porte est ouverte au piratage... ou à l'usurpation d'identité selon l'usage que le pirate fera de ce qu'il aura récupéré.

Bon alors sinon on enleve les passwords, ca règle pleins de choses ça aussi!

par AB » 08 sept. 2011, 21:23

c'est pour ça que le https existe , ce qui serait sympa c'est que sur les client web le champ password supporte les hash :
<input type="password" hash="md5" name="pwd" />
L'idée au départ est séduisante, mais à la réflexion, ça n'a pas grand intérêt.

Si c'était indiqué dans le HTML, ce serait donc clairement lisible dans la source et donc le pirate saurait comment s'adapter pour produire ses attaques en hachant ses envois de la même manière. Même un hachage md5 en JavaScript est possible mais présente le même défaut...

Si si cela a un grand intérêt, car s'il récupère une chaine de caractères haschée, le sniffeur de réseau doit encore faire du travail pour retrouver le mot de passe original. Pour peu que le mot de passe soit concaténé à un grain de sable différent pour chaque envoi de formulaire, le pirate ne récupèrera qu'une chaine qu'il ne saura pas exploiter.

Par contre avec un mot de passe qui transite en clair dans les tuyaux, le sniffer de réseau pourra trouver le mot de passe en clair - directement utilisable - et dans ce cas peu importe sa complexité et ou sa longueur.

Ce que je voulais donc dire c'est que ce débat sur la sécurisation des mots de passe pour les rendre difficiles à attaquer, n'a d'intérêt qu'à partir du moment où le mot de passe ne transite pas en clair, sinon une simple écoute du réseau (technique assez simple pour un pirate expérimenté) rend tout ça caduque

par **Cyrano** » 08 sept. 2011, 21:05

De toutes façons il y a un bug commun à tous les formulaires, c'est l'interface chaise-clavier.
Faut que je poste le bug ou ? Sur le bugtracker de mozilla, php ou de la w3c ?

Comme aurait dit Nagol pendant un temps : « stoi le bug »

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?

On appelle ça le PHP

Et ça ne règlerait rien puisque le problème de départ est la qualité du mot de passe mesurée selon sa complexité. Ajoutons à ça le problème de la transmission en clair sur le réseau de ce même mot de passe entre client et serveur faute d'une connexion SSL et la porte est ouverte au piratage... ou à l'usurpation d'identité selon l'usage que le pirate fera de ce qu'il aura récupéré.

par **Nagol** » 08 sept. 2011, 20:53

en fait il faudrait une sorte de langage de script qui serait capable de faire du md5 et qui soit côté serveur, ça réglerait tout ça non?

Sécurité et mot de passe

Répondre

Étendre la vue Revue du sujet : Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe

Re: Sécurité et mot de passe