Bonjour à tous, après une recherche sur le forum, j'ai vu qu'il n'existe aucun topic sur John the ripper, pourtant bien pratique ce petit logiciel. Il serait intéressant d'avoir la durée de crackage des mdp de vos configs et le type de composition de vos mots de passe. Je propose qu'on fasse sous cette forme :
 
 
Pseudo - Distribution
Processeur - Ram - disque dur (ide, sata, scsi)
Temps de crackage de vos mots de passe
Composition de vos mots de passe (aaa = lettres, @ = caractère spécial, 000 = chiffres)
 
 
Michalatore - Debian
Bi-P3 1Ghz - 1,5Go SDR ECC - 2*18Go raid1 scsi160 / 3*74Go raid5 scsi320
Arrêté au bout de 38h.
aaa@0aaa
 
 
 
DEBIAN

 
Vous pouvez reprendre une session de crackage par la commande :
john -restore
 
Vous pouvez demander à voir les mots de passe qu'il a réussi à cracker :
john -show passwd
 
Pour voir où ça en est, appuyez sur la touche "enter" dans la console active.
 
 

 
 
Si le topic vous intéresse, je créerai un tableau général à partir de ces informations.
Si vous avez les méthodes d'installation et de lancement pour d'autres distributions, soumettez-les moi, je les mettrai en premier post.

John the ripper fonctionne à partir d'un dictionnaire (je crois, depuis le temps cela a peut être changé ),
sinon ça sers a rien d'ouvrir un topic durée de crackage a son sujet.

 
Bah, d'toute manière ... c'est moi qu'ai la plus grosse  
     

tu as un mode incrémental qui permet qui a partir d'un dictionnaire teste toutes les combinaisons.

ben c'est ce que je dis, celui qui a le plus gros dictionnaire va gagner : forcément
ou alors je divague.
 
ps : la derniere fois que je me suis servis de ce truc c'est qd on m'a refilé un serveur de prod
dont les passwd étaient périmés dans la tête des clients/users. je te dis pas le foin (30-40 clients mails)
pour tous les appelé un par un et leur dire qu'il faut changer leur passwd genre "année de naissance,
4chiffres uniquement..." bref tout et n'importe quoi qui était anti-secure  
et surtout pour leur expliquer que c'est pas bon les passwd facileatrouver/cracker

Apparemment il attaque en brute force aussi.
Il me semblait que c'était intéressant de voir la durée d'attaque sur certaines configs de ce logiciel qui est bien pratique.
Par exemple, si ton mot de passe est le même que ton login, il le trouve de suite, c'est le premier truc qui teste

donne nous la commande exacte dans ce cas.
je ferais un essai sur un bi-proc pour voir  

C'est le mode incremental dont je parlais

J'ai déjà donné la commande pour débian, je connais pas les autres distrib. Le dernier John est le v1.7. Par contre apparemment il n'est pas SMP, j'ai pas trouvé de commande pour qu'il utilise les deux processeurs.
 

bah je croyais qu'il se basait sur un petit dictionnaire surlequel il incrémenterai.
ie: tu lui donne un input (une série de password) sur lequel il effectue les opération incrémentale.

cette commande par defaut utilise le dictionnaire installé par defaut.
il y en a bien une de commande qui va faire la brute force.
il faut que tlm utilise la même procédure sinon pas moyen d'avoir une comparaison
fiable.

T'es sur qu'il teste pas d'abord le dictionnaire par défaut ensuite en brute force ? A mon avis c'est ce qu'il fait, je n'ai jamais trouvé d'autres commandes sur john. Je vais chercher

je viens de le lancer en ssh sur 10 passwd /etc/shadow sur un bi-p3s 1000Mhz,
et ça bouge pas pour le moment (:ça fait >2min)

Quelle est la conception de ton mot de passe ?
Si c'est un mot simple du dictionnaire, il devrait le trouver rapidement.
Si c'est un mot composé avec lettres, chiffres, caractères spéciaux, il va galéré (le mien tourne depuis maintenant 17h sur un bi-P3 1Ghz).

Juste pour l'info (tant qu'à faire, autant parler un peu sécurité des mdp) :  

Dans la documentation de John ( man john ) :
 

 
Il est aussi possible de reprendre une session de crackage interrompue en tapant (sous debian) : john -restore. Toujours intéressant...

sur mon serveur aucun passwd est dans un dictionnaire,
genre je melange les chiffres, les lettres, les caracteres peciaux, les majuscules
bref, c'est

lol c'est ce qu'il faut
Ca aurait été bien de tester avec un mot de passe simple du dictionnaire, voir en combien de temps il trouve. Et avec un mdp simple mis en majuscule par exemple.

dans le même genre pour savoir qui pisse le plus loin.
il suffit de lancer un prog pour calculer la serie des nombres 1er

Le but c'était pas de savoir qui déchiffrera son password le premier ou en dernier, ça dépend trop des machines et du mot de passe en lui-même. C'était juste voir la difficulté de déchiffrer certains mots de passes, mieux formés que d'autres.
 
Pour le calcul pur, autant demander aux gars de la rubrique SETI de nous faire une démo, parce que c'est pas avec un bi-P3 qu'on va faire les beaux face à un quadri opteron 850 ou autres machines du genre... lol

nicodu95 - Mdv 2006
Celeron 1Ghz - 512 Mo - 50 Go
même pas une seconde  
aaaaaaa
 
avec la commande john /etc/shadow
là il cherche pour les autre mdp (root , ...)
 
 
edit : John marche aussi avec les Mdp de Windows non ??
si oui si qqun connait leur emplacemnt  

On peut voir l'avancement quelque part ?

lorsqu'il est en premier plan dans ta console tape entrer

sinon dans une autre console ou si il est en arriere plan dans le répertoire ou tu a lancer ton john tapes
john -show /etc/shadow

au passage y a un man

J'ai vu Merci pour l'astuce, pour voir où ça en est : enter.
 
Perso, après 20h de taf, il en est à anDZCUS (soit 7 caractères, mon mot de passe comporte 8 caractères déjà...)

je l'ai arrêté because, il n'a pas trouvé l'ombre d'un seul mot de passe sur les 10 proposés
au bout de presque 20h qd même.  
j'ai pu verifié que le smp ne fonctionnait pas avec john : alternativement l'un et l'autre géré
par le kernel en fonction de la temperature de fonctionnement des proc, j'ai l'impression.

 
  wow ... t'as un bi-proc ou un double-coeur ?

un bi-proc donc pas dual core  
je me demande d'ailleurs comment le kernel se debrouille pour migrer un process
d'un proc à l'autre, j'avais deja observé ce phenomène qd j'envoie de l'encodage
stream sur le réseau avec vlc.

Ben normalement le kernel ne migre rien mais partage le process entre les deux procs ... c'est l'avantage du smp, sinon autant avoir deux bécanes

ben c'est bizarre cette histoire alors.  
je vois clairement le proc 0 travailler (+charge) pendant disons 1min puis le proc 1 et en alternatif,
chacun leur tour.
 
sinon pour des processus différent (pid différents), la charge est bien répartie. mon serveur tourne a environ 10% de moyenne
pour chaque proc (avec l'interface graphique, la tv...).
mais avec john, chaque proc monte a 80% mais alternativement.

 
Tes supers disques en SCSI vont changer la donne pour attaquer un pass en force brute, c'est sûr !
 
Vous n'avez rien de mieux à faire que de consommer de l'energie pour des causes aussi affligeantes ? Inscrivez-vous à un projet de recherche si vous avez du temps machine inutile !!
 
Tu fais quoi d'autre sur ta debian ?
Postes nous le résultat d'un 'ls -lR / | grep jpg | wc -l', ca occupera tes durs.

mon serveur heberge un site/forum pour une association carritative également  
désolé, mais j'ai pas mauvaise conscience sur ce coup la.

 
c'est tout à ton honneur..
mais visiblement certaines personnes n'ont pas gd chose d'autre a faire que d'étaler leur matos, genre "yeah I'm the king of the world avec mes 6 disques SCSI"
 
j'ai envie de dire que debian c'est une distrib pour faire des choses utiles (héberger de l'asso., très bien !) mais passer 18h à craquer un mdp avec john the ripper, et se la ramener avec son SCSI et sa ram ECC, c'est risible ! c'est 300Wh dépensé en pure perte !
 
(désolé)

ben, tu dégrades le services que tu offres a l'assoc carritative

Et puis, oui, john the ripper, c'est à la base un crackeur basé sur dictionnaire.. donc cherchez pas, "sd%*87hsD!" il va pas le trouver par miracle !

ne t'inquiete donc pas pour ça.    
son serveur est passé gratuitement de p200mmx à l'origine à un bi-proc 1Ghz, je crois que  
et je pense que le service que j'offre evoluera gratuitement avec l'evolution de mon parc machine.

 
Yep, assez strange ... A moins que ça ne provienne de john lui même qui ne supporte pas le smp ou qui demande une compilation spécifique pour le smp