Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

htaccess et erreur 401

16 views
Skip to first unread message

Gerald

unread,
Oct 24, 2011, 4:52:21 AM10/24/11
to
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
htaccess. Désormais le fichier de mot de passe est bien reconnu, le
dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
parce que je me prends une erreur 401 (password mismatch) quelque soit
l'utilisateur et que le mdp soit bon ou pas.

- quand le fichier htaccess n'est pas présent, l'accès au site se fait
sans problème
- quand il est présent il me demande identifiant et mot de passe, normal
- si je déplace le fichier des mots de passe il me renvoie une erreur
404 de fichier non présent
- quand il est en place il le voit, mais le navigateur ne reçoit pas le
ok de "correspondance" pour accéder au site et il me renvoit une 401.

Une piste : quand je veux mettre des accents dans mon message
d'invitation, ça me ressort du "garbage" sur les caractères accentués.
Il y a donc un problème de non francisation ou quelque chose du genre ?
(je précise que j'ai choisi "Identification" comme invitation, des
prénoms sans accents comme logins, et des mots de passe constitués
uniquement de chiffres.)

J'ajoute que le résultat est le même avec Safari et avec Firefox.

Si quelqu'un a une idée, d'avance merci.

--
Gérald

Yop

unread,
Oct 24, 2011, 6:04:46 AM10/24/11
to
> Si quelqu'un a une idée, d'avance merci.

De mémoire, le chemin indiquant htpasswd
doit etre complet dans htaccess
AuthUserFile /home/web/ton/chemin/.htpasswd

Y


Gerald

unread,
Oct 24, 2011, 6:47:20 AM10/24/11
to
Yop <kloug...@yahoo.fr> wrote:

> De mémoire, le chemin indiquant htpasswd
> doit etre complet dans htaccess
> AuthUserFile /home/web/ton/chemin/.htpasswd

Le chemin n'est pas en cause : quand il l'était (et il l'a été avant que
je ne trouve la bonne syntaxe !), ça donnait une erreur 404. Là c'est
une erreur d'authentification : le fichier est bien vu mais sa lecture
est corrompue. Et je dirais même : dès la comparaison de l'identifiant
puisque le problème existe même quand on ne met pas de mot de passe.

Mais merci quand même pour l'intention,

--
Gérald

Vincent

unread,
Oct 24, 2011, 7:04:37 AM10/24/11
to
Le 24/10/2011 10:52, Gerald a écrit :

> Une piste : quand je veux mettre des accents dans mon message
> d'invitation, ça me ressort du "garbage" sur les caractères accentués.

J'avais eu quelque chose comme cela...
Il m'avait fallu réencoder le fichier htaccess avec le même encodage que
celui de la page appelante (c'était le index.php)

Si ça peut aider...

Pour le fun, le htaccess avait été encodé en UTF16 little endian par je
ne sais quel cochonnerie d'éditeur windows.

SAM

unread,
Oct 24, 2011, 9:02:14 AM10/24/11
to
Le 24/10/11 10:52, Gerald a écrit :
> J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
> htaccess.

Ça se passe chez qui ?
(quel hébergeur ?)

> Désormais le fichier de mot de passe est bien reconnu, le
> dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
> parce que je me prends une erreur 401 (password mismatch) quelque soit
> l'utilisateur et que le mdp soit bon ou pas.
>
> - quand le fichier htaccess n'est pas présent, l'accès au site se fait
> sans problème

Ouf ! donc le "site" existerait (au moins en cache ;-) )

> - quand il est présent il me demande identifiant et mot de passe, normal
> - si je déplace le fichier des mots de passe il me renvoie une erreur
> 404 de fichier non présent
> - quand il est en place il le voit, mais le navigateur ne reçoit pas le
> ok de "correspondance" pour accéder au site et il me renvoit une 401.

erreur de login, non ?
(ou erreur de rédaction du fichier de MdP)

> Une piste : quand je veux mettre des accents dans mon message
> d'invitation, ça me ressort du "garbage" sur les caractères accentués.

Bon ...
bien entendu, tous les fichiers sont écrits avec le même charset ?
En utf-8, par exemple.
(ou, à minima, en ISO-8859-1)

> Il y a donc un problème de non francisation ou quelque chose du genre ?
> (je précise que j'ai choisi "Identification" comme invitation, des
> prénoms sans accents comme logins, et des mots de passe constitués
> uniquement de chiffres.)
>
> J'ajoute que le résultat est le même avec Safari et avec Firefox.

les pov's chéris n'y peuvent goute pour des problèmes de serveurs ;-)
non ?

> Si quelqu'un a une idée, d'avance merci.


Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
pour aller là.


tout refaire "propre" ?
(y compris le ftp)


--
Stéphane Moriaux avec/with iMac-intel

Gerald

unread,
Oct 24, 2011, 11:13:00 AM10/24/11
to
SAM <stephanemor...@wanadoo.fr.invalid> wrote:

> Ça se passe chez qui ?
> (quel hébergeur ?)

Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les
fonctionnalité du serveur Apache intégré à Mac OS X :
- Préférences Système : partage web
- Site créé avec RapidWeaver et copié en local dans le dossier "Sites"
d'un utilisateur lambda du MacMINI
- Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère
les redirections
- et qui est branchée en Ethernet sur une BBox complètement passive, sur
laquelle j'ai simplement ouvert le HTTP, et activé la redirection
dynamique du nom de domaine (vers DynDNS.org)

> Ouf ! donc le "site" existerait (au moins en cache ;-) )

En fait LES sites existent depuis plusieurs années et fonctionnent très
bien (dans la limite du débit montant de Bouygues quand même, mais c'est
pour une utilisation à très faible audience, certaines mauvaises langues
diraient à très faible intérêt :-)

> Bon ...
> bien entendu, tous les fichiers sont écrits avec le même charset ?
> En utf-8, par exemple.
> (ou, à minima, en ISO-8859-1)

Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques
du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron
? Autre ?

> Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
> pour aller là.

Déjà essayé, tout comme de créer un nouvel utilisateur pour voir si le
résultat serait différent : hélas non. J'ai aussi exclu la nature du
site (très élémentaire) créé par RapidWeaver en le remplaçant par une
copie des pages par défaut d'Apple pour le dossier Sites de
l'utilisateur. Pas de changement : sans htaccess ça s'affiche impec,
avec htaccess ça demande le mot de passe, ça accède au fichier mdp
(puisque "pas" de 404) mais ça ne reconnaît pas ce qui est saisi (ou ce
qui est renvoyé) comme identique.
>
> tout refaire "propre" ?
> (y compris le ftp)

Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité
de la manip.

J'ai effectivement l'impression qu'il y a quelque chose qui modifie la
nature du texte identifiant-mot de passe, quand on le tape, ou quand on
l'envoie, ou quand on le reçoit, ou quand on lit le fichier mdp, ou
quand on compare les deux (c'est Apache du MINI qui fait ça, je crois).
C'est sûrement très évident et je suis sûrement le roidek, mais le
résultat est le même : je suis bloqué (enfin pour cette fonctionnalité).
J'ai vu qu'il existe un "external" pour rapidweaver qui offre une
interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser
10 euros pour rien.

En tout cas merci de ton aide : tu suis parfaitement le problème, et
c'est agréable d'être compris, à défaut de bondir de joie :-)

--
Gérald

Gerald

unread,
Oct 24, 2011, 11:13:01 AM10/24/11
to
Vincent <vincen...@sfr.fr> wrote:

> Il m'avait fallu réencoder le fichier htaccess avec le même encodage que
> celui de la page appelante (c'était le index.php)

DE LA PAGE *APPELANTE* ? mmm ! ça pourrait bien être ça, mais ça le fait
pareil si je remplace la page créée par RapidWeaver par celle créée par
Apple (par défaut dans le dossier Sites).

Une suggestion pour ce réencodage (logiciel et manière de faire ?)

En tout cas merci déjà !

--
Gérald

Denis Beauregard

unread,
Oct 24, 2011, 11:22:11 AM10/24/11
to
Le Mon, 24 Oct 2011 10:52:21 +0200, Ger...@alussinan.org (Gerald)
écrivait dans fr.comp.infosystemes.www.auteurs:

>J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
>htaccess. Désormais le fichier de mot de passe est bien reconnu, le
>dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
>parce que je me prends une erreur 401 (password mismatch) quelque soit
>l'utilisateur et que le mdp soit bon ou pas.


Je ne sais pas si cela aidera, mais voici une petite anecdote à
ce sujet.


Une fois, j'ai essayé de créer un .htaccess à la mitaine, en
écrivant le code et en envoyant le tout au serveur et cela ne
marchait pas. Par contre, il y avait sur le serveur un logiciel
de gestion du site (du genre cpanel). En l'utilisant, j'ai pu
avoir un .htaccess fonctionnel. Je n'ai jamais su quel était le
problème. J'éditais sur Windows et le serveur être en Linux, avec
une éventuelle conversion durant le FTP.

Si on édite sur Mac et que le serveur est un Linux, le .htaccess
n'a pas d'extension et peut-être que le logiciel FTP ne fait pas
la conversion des fins de ligne. J'essaierais soit d'éditer les
fichiers directement sur le serveur, soit de changer l'extension
(exemple : .txt) lors du téléversement au serveur.


Denis

Olivier Miakinen

unread,
Oct 24, 2011, 12:13:54 PM10/24/11
to
Le 24/10/2011 17:13, Gerald a écrit :
>
>> Bon ...
>> bien entendu, tous les fichiers sont écrits avec le même charset ?
>> En utf-8, par exemple.
>> (ou, à minima, en ISO-8859-1)
>
> Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
> re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
> sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques
> du fichier ?

Pour le contenu effectif, si tu as un moyen d'afficher le contenu des
fichiers octet par octet tu peux comparer un caractère donné (mettons
un « é » par exemple) avec son encodage prévu (en l'occurrence, deux
octets de valeurs hexa C3 et A9, dans cet ordre). Ceci est à faire
aussi bien sur le .htaccess que sur la page à protéger.

Cf. <http://www.miakinen.net/vrac/charsets/?pr=233>, codage UTF-8.


Regarder aussi s'il n'y aurait pas un BOM au début de l'un des fichiers.
Pour cela, voir si les trois premiers octets sont EF BB BF.


Enfin, il serait bon de préciser ce que tu appelais « garbage » dans ton
premier article, en donnant un exemple des caractères que tu souhaites
et du résultat obtenu (à faire par copier-coller car je me doute que tu
ne sauras pas forcément saisir un Å ou un √). Euh... hum, je vois que tu
utilises MacSOUP alors il ne te sera peut-être pas possible de faire ce
copier-coller ici... dans ce cas cjoint.com est ton ami.


Cordialement,
--
Olivier Miakinen

SAM

unread,
Oct 24, 2011, 8:16:19 PM10/24/11
to
Le 24/10/11 17:13, Gerald a écrit :
> SAM<stephanemor...@wanadoo.fr.invalid> wrote:
>
>> Ça se passe chez qui ?
>> (quel hébergeur ?)
>
> Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les
> fonctionnalité du serveur Apache intégré à Mac OS X :
> - Préférences Système : partage web
> - Site créé avec RapidWeaver et copié en local dans le dossier "Sites"
> d'un utilisateur lambda du MacMINI

ça, ça me gène ... le coup du "copié"
qu'en pense le serveur ensuite ?
les droits des fichiers sont-ils les bons ?

il faudrait faire un chmod à bon escient(*) sur les fichiers .htaccess
et .passwords

(*) je ne sais si un chmod 7777 conviendrait pour ces fichiers


> - Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère
> les redirections
> - et qui est branchée en Ethernet sur une BBox complètement passive, sur
> laquelle j'ai simplement ouvert le HTTP, et activé la redirection
> dynamique du nom de domaine (vers DynDNS.org)

Ha Oui ! Quand même !

Et est-ce que l'accès protégé a eu fonctionné un jour ?
Ou bien est-ce tes premiers essais.

>> bien entendu, tous les fichiers sont écrits avec le même charset ?
>> En utf-8, par exemple.
>> (ou, à minima, en ISO-8859-1)
>
> Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
> re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
> sauvegardé en UTF-8...

Oui ... bon ... même s'il est censé y arriver, ça se mérite trop pour
être certain de ne pas avoir fait une erreur qque part.

> Comment en savoir plus sur les caractéristiques du fichier ?
> Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron

À défaut de BBEdit, j'opterais volontiers pour TextWrangler
(TextEdit est trop difficile à dompter, je trouve)
Smultron, oui sans doute (bien que pour un fichier texte de MdP ...)

>> Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
>> pour aller là.
>
> ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé).

J'espère que ton fichier de MdP en contient plusieurs et que tu as
essayé sur chacun ?
Histoire d'écarter la fôte de frappe réitérée à l'infini. (on peut de
bonne fois s'évertuer à entrer un login sans s'appercevoir que ce n'est
pas exactement le bon)

>> tout refaire "propre" ?
>> (y compris le ftp)
>
> Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité
> de la manip.

non quand même pas ;-) !
Je voulais juste dire de réécrire les fichiers en les enregistrant aux
bons endroit (sans s'amuser à les glisser ensuite d'un dossier à l'autre)

> je suis bloqué (enfin pour cette fonctionnalité).
> J'ai vu qu'il existe un "external" pour rapidweaver qui offre une

Je me méfie comme de la peste de ces usines à créer des fichiers web
rien le vaut le labeur à la mimine

> interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser
> 10 euros pour rien.

10 euros pour écrire un fichier de 4 à 6 lignes et un autre d'autant de
lignes que de logins ???
économise ! économise !

SAM

unread,
Oct 24, 2011, 8:26:37 PM10/24/11
to
Le 24/10/11 17:22, Denis Beauregard a écrit :
>
> Si on édite sur Mac et que le serveur est un Linux, le .htaccess
> n'a pas d'extension et peut-être que le logiciel FTP ne fait pas
> la conversion des fins de ligne. J'essaierais soit d'éditer les
> fichiers directement sur le serveur, soit de changer l'extension
> (exemple : .txt) lors du téléversement au serveur.

Bon, là en l'occurrence il n'y a ps de ftp
tout est fait directement sur l'ordi qui fait serveur web

éditer un fichier caché sur le serveur ... ça ne m'est pas évident.
(jamais essayé)(compliqué ... login étoussa)

Sinon, pour ma part, un .htaccess est écrit (copié/collé) grâce à un
éditeur-texte respectueux de l'encodage que je lui précise.
Le fichier est sauvegardé sur l'ordi avec n'importe quel nom et, si
suffixe, ce serait : txt
Le fichier est uploadé sur le site en ftp
puis renommé sur le site (en .htacces)
À partir de ce moment mon logiciel de ftp ne le voit plus sur le site.
(à chaque modif j'en uploade et renomme un autre)

Gerald

unread,
Oct 25, 2011, 12:14:30 AM10/25/11
to
Olivier Miakinen <om+...@miakinen.net> wrote:

> Enfin, il serait bon de préciser ce que tu appelais « garbage » dans ton
> premier article, en donnant un exemple des caractères que tu souhaites
> et du résultat obtenu

Ok. Je vais essayer de recréer les fichiers avec TextWrangler comme le
suggère SAM, je teste, je copie et je reviens éventuellement avec les
copies d'écran. Merci pour ton aide.


--
Gérald

Gerald

unread,
Oct 25, 2011, 12:14:30 AM10/25/11
to
SAM <stephanemor...@wanadoo.fr.invalid> wrote:

> les droits des fichiers sont-ils les bons ?

j'aurais tendance à penser que oui pour deux raisons : parce que j'ai
déjà été voir avec les infos du finder d'une part, et parce que l'erreur
retournée laisse supposer que le fichier mot de passe a pu être *lu* (ce
qui est tout ce qu'on lui demande), mais mal (ce qui est le problème).
Mais je vais quand même aller voir avec Batchmod...

> Et est-ce que l'accès protégé a eu fonctionné un jour ?
> Ou bien est-ce tes premiers essais.

Ce sont mes premiers essais de protection. C'est vraiment un problème
spécifique de htaccess. Note un point positif : alors que d'habitude ce
genre de problème met en cause l'hébergeur, là on a tout sous la main !

> J'espère que ton fichier de MdP en contient plusieurs et que tu as
> essayé sur chacun ?

Oui. J'ai aussi testé avec un mdp vide, de mettre ou pas un return après
le dernier etc.

> non quand même pas ;-) !
> Je voulais juste dire de réécrire les fichiers en les enregistrant aux
> bons endroit (sans s'amuser à les glisser ensuite d'un dossier à l'autre)

ok, je vais essayer avec TextWrangler et je reviens.
>
Encore merci de ton intérêt. Tu ne peux pas savoir à quel point c'est
important de ne pas se sentir tout seul au monde dans ce genre de
circonstances.

--
Gérald

Jean Francois Ortolo

unread,
Oct 25, 2011, 3:45:38 AM10/25/11
to
Le 25/10/2011 06:14, Gerald a écrit :
> SAM<stephanemor...@wanadoo.fr.invalid> wrote:
>
>> Et est-ce que l'accès protégé a eu fonctionné un jour ?
>> Ou bien est-ce tes premiers essais.
>
> Ce sont mes premiers essais de protection. C'est vraiment un problème
> spécifique de htaccess. Note un point positif : alors que d'habitude ce
> genre de problème met en cause l'hébergeur, là on a tout sous la main !
>
>


Bonjour Monsieur

Histoire de rire... ( Excusez-moi si je fais une erreur. )

Est-ce que le contenu du fichier .htpasswd ( qui peut être faux ), a
bien été crypté, de manière à ce que l'application de la fonction
crypt() du Langage C, ou bien PHP, au mot de passe entré au moment de
l'essai d'authentification, soit bien égale à au contenu du fichier
.htpasswd ?

Vous savez bien, que les mots de passe, dans le fichier .htpasswd ,
sont cryptés ?

Bien amicalement.

Jean François Ortolo


Paul Gaborit

unread,
Oct 25, 2011, 4:31:43 AM10/25/11
to

À (at) Tue, 25 Oct 2011 02:16:19 +0200,
SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):

> les droits des fichiers sont-ils les bons ?
>
> il faudrait faire un chmod à bon escient(*) sur les fichiers .htaccess
> et .passwords
>
> (*) je ne sais si un chmod 7777 conviendrait pour ces fichiers

Les fichiers .htaccess et .htpasswd n'ont besoin que d'un seul droit :
la lecture par le serveur Apache. Donc les droits 644 suffisent
largement.

>>
>> Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
>> re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
>> sauvegardé en UTF-8...
>
> Oui ... bon ... même s'il est censé y arriver, ça se mérite trop pour
> être certain de ne pas avoir fait une erreur qque part.

Puisque le contrôle d'accès se déclenche, c'est que le fichier .htaccess
est reconnu. Quant au fichier .htpasswd, vu qu'il est généré par la
command 'htpasswd', son format est évidemment correct.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Gerald

unread,
Oct 25, 2011, 9:53:10 AM10/25/11
to
Paul Gaborit <Paul.G...@invalid.invalid> wrote:

> Puisque le contrôle d'accès se déclenche, c'est que le fichier .htaccess
> est reconnu. Quant au fichier .htpasswd, vu qu'il est généré par la
> command 'htpasswd', son format est évidemment correct.

Tu as parfaitement suivi. Je n'ai pas encore eu le temps de recréer les
fichiers avec un autre outil, des fois que TextEdit soit en cause. Je
reviens dans un moment vous tenir au courant...

--
Gérald

Gerald

unread,
Oct 25, 2011, 9:53:10 AM10/25/11
to
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> wrote:

> Vous savez bien, que les mots de passe, dans le fichier .htpasswd ,
> sont cryptés ?

Non, il me semblait que le cryptage des mots de passe était une
*option*. Tu as une source fiable de ça ?

--
Gérald

Jean Francois Ortolo

unread,
Oct 25, 2011, 10:11:03 AM10/25/11
to
Bonjour Monsieur

Ben voilà l'errreur . ;)

Demandez aux autres intervenants ce qu'ils en pensent.

Vous semblez être votre propre hébergeur.

Vous êtes sous Mac.

Le système Mac, est similaire à celui d'Unix, ou de Linux. ( C'est la
même chose ).

Il devrait y avoir un outil sous Mac, qui permette de crypter une
chaîne de caractère, comme si c'était en vue de l'utiliser dans un
fichier .htpasswd

Monsieur Gaborit a mentionné l'outil : htpasswd.

Vous avez dit que c'était cet outil que vous avez utilisé.

Voici le résultat sur mon système Linux Fedora 15 64 bits, de la
commande : 'htpasswd --help' :

Usage:
htpasswd [-cmdpsD] passwordfile username
htpasswd -b[cmdpsD] passwordfile username password

htpasswd -n[mdps] username
htpasswd -nb[mdps] username password
-c Create a new file.
-n Don't update file; display results on stdout.
-m Force MD5 encryption of the password (default).
-d Force CRYPT encryption of the password.
-p Do not encrypt the password (plaintext).
-s Force SHA encryption of the password.
-b Use the password from the command line rather than prompting for it.
-D Delete the specified user.
On other systems than Windows, NetWare and TPF the '-p' flag will
probably not work.
The SHA algorithm does not use a salt and is less secure than the MD5
algorithm.
~



Comme vous voyez, il y a plusieurs options pour le cryptage.

Un serveur http Apache, utilise le mode crypt() de cryptage, je crois.

C'est à vous à faire la même commande : 'htpasswd --help' , puis à
voir quelles sont les options dont vous disposez.

Comme le mot de passe ( crypté très certainement ) semble faux dans
votre cas, je penche pour une option de cryptage erronée, que votre
serveur web interprète mal.

Bien à vous.

Amicalement.

Jean François Ortolo



Paul Gaborit

unread,
Oct 25, 2011, 10:48:58 AM10/25/11
to

À (at) Tue, 25 Oct 2011 15:53:10 +0200,
Ger...@alussinan.org (Gerald) écrivait (wrote):
Le fichier des mots de passe *doit* être créer avec l'outil 'htpasswd'
(ou alors on le génère soi-même mais cela signifie qu'on sait comment
hacher les mots de passe).

PS: les mots de passe ne sont pas chiffrés (sinon cela supposerait qu'on
puisse les déchiffrer ou, pire, les décrypter). Ils sont haché et on ne
stocke que leur empreinte.

Jean Francois Ortolo

unread,
Oct 25, 2011, 12:25:12 PM10/25/11
to
Le 25/10/2011 16:48, Paul Gaborit a écrit :
>
> Le fichier des mots de passe *doit* être créer avec l'outil 'htpasswd'
> (ou alors on le génère soi-même mais cela signifie qu'on sait comment
> hacher les mots de passe).
>
> PS: les mots de passe ne sont pas chiffrés (sinon cela supposerait qu'on
> puisse les déchiffrer ou, pire, les décrypter). Ils sont haché et on ne
> stocke que leur empreinte.
>



Bonjour Monsieur

Vous avez peut-être vu mon message à côté du votre.

Les modes de cryptage du mot de passe, sont indiqués :

MD5,
crypt(),
SHA

ou bien, effectivement, avec l'option -p , en clair.

Je reconnais que l'on ne stocke que les empreintes des mots de passe.

Quant au fait de si les modes de cryptage sont des hashages ou des
cryptages réels, il me semble que ces trois modes ci-dessus, sont bien
du cryptage, évidemment sans clé publique et/ou privée, ce à quoi vous
restreignez peut-être, l'emploi du mot cryptage.

Paul Gaborit

unread,
Oct 25, 2011, 6:39:54 PM10/25/11
to

À (at) Tue, 25 Oct 2011 18:25:12 +0200,
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> écrivait (wrote):

> Les modes de cryptage du mot de passe, sont indiqués :
>
> MD5,
> crypt(),
> SHA
[...]
> Quant au fait de si les modes de cryptage sont des hashages ou des
> cryptages réels, il me semble que ces trois modes ci-dessus, sont bien
> du cryptage, évidemment sans clé publique et/ou privée, ce à quoi vous
> restreignez peut-être, l'emploi du mot cryptage.
>

Le cryptage n'existe pas. On parle de chiffrement et de déchiffrement.
Et l'un comme l'autre nécessitent effectivement l'usage d'une clé. Une
information chiffrée peut être déchiffrée si on connait la clé à
utiliser. Si on arrive à déchiffrer cette information sans connaître la
clé alors on fait de décryptage.

Les trois fonctions évoquées ci-dessus (MD5, SHA et crypt() qui est en
fait une utilisation détournée de DES) sont des fonctions de hachages
(et non pas des fonctions de chiffrement). Elles permettent de calculer
l'empreinte d'une information. Cette empreinte identifie l'information
dont elle est issue (aucune autre information n'a la même empreinte)
mais le seule connaissance de cette empreinte ne permet pas de retrouver
le moindre bit de l'information d'origine.

C'est pour cela qu'on utilise ces empreintes pour vérifier les mots de
passe. Lorsqu'on veut vérifier un mot de passe, on calcule son empreinte
et on la compare à celle qu'on a stockée. Si elles sont identiques,
c'est que les deux informations initiales sont identiques (c'est donc le
bon de passe). En revanche, l'administrateur ou, pire, le pirate qui a
accès au fichier des empreintes ne peut absolument pas retrouver le
moindre mot de passe...

Parfois on ajoute du sel (quelques caractères choisis au hasard) devant
le mot de passe avant de calculer son empreinte. Cela permet de
s'assurer que deux mots de passe identiques n'auront pas la même
empreinte (puisque le sel sera différent). Il faut évidemment stocké le
sel choisi en plus de l'empreinte pour pouvoir la recalculer lors de la
vérification d'un mot de passe.

Si mes souvenirs sont bons, la commande htpasswd fournie avec Apache
n'utilise pas de sel.

Olivier Masson

unread,
Oct 26, 2011, 6:04:39 AM10/26/11
to
Le 26/10/2011 00:39, Paul Gaborit a écrit :

> Parfois on ajoute du sel (quelques caractères choisis au hasard) devant
> le mot de passe avant de calculer son empreinte. Cela permet de
> s'assurer que deux mots de passe identiques n'auront pas la même
> empreinte (puisque le sel sera différent). Il faut évidemment stocké le
> sel choisi en plus de l'empreinte pour pouvoir la recalculer lors de la
> vérification d'un mot de passe.
>
> Si mes souvenirs sont bons, la commande htpasswd fournie avec Apache
> n'utilise pas de sel.
>

On sale aussi pour éviter le reverse-engineering via l'utilisation de
rainbow-tables (gigantesques tables de hash précalculés).
À ce moment, le sel est très souvent unique, relativement long, complexe
et, bien entendu, secret. Les hash de mots de passe circulant bien
souvent en clair sur internet, s'il n'y a pas de sel, la plupart des
mots de passe sont faciles à retrouver (voir par exemple
http://www.onlinehashcrack.com/).
Pour htpasswd, avec crypt, il utilise le sel standard pour DES, soit 2
caractères, ce qui n'est pas bien sûr.

SAM

unread,
Oct 26, 2011, 6:36:50 AM10/26/11
to
Le 26/10/11 00:39, Paul Gaborit a écrit :
>
> Les trois fonctions évoquées ci-dessus (MD5, SHA et crypt() qui est en
> fait une utilisation détournée de DES) sont des fonctions de hachages
> (et non pas des fonctions de chiffrement). Elles permettent de calculer
> l'empreinte d'une information. Cette empreinte identifie l'information
> dont elle est issue (aucune autre information n'a la même empreinte)
> mais le seule connaissance de cette empreinte ne permet pas de retrouver
> le moindre bit de l'information d'origine.

Tout ça me parait du pipeau.
Ça n'empêche pas de mouliner en clair x mots de passe jusqu'à tomber sur
le bon.

Est-ce qu'un méchant-vilain pourra plus facilement aller lire le fichier
des MdP, fichier caché, fichier dans un dossier protégé, fichier dont le
nom n'est pas obligatoirement htpasswd.
(au cazou il voudrait tenter de lire les MdP directement)

> C'est pour cela qu'on utilise ces empreintes pour vérifier les mots de
> passe. Lorsqu'on veut vérifier un mot de passe, on calcule son empreinte
> et on la compare à celle qu'on a stockée. Si elles sont identiques,
> c'est que les deux informations initiales sont identiques (c'est donc le
> bon de passe). En revanche, l'administrateur ou, pire, le pirate qui a
> accès au fichier des empreintes ne peut absolument pas retrouver le
> moindre mot de passe...

Ha! Ben ! Ça c'est malin !
Si l'administrateur ne peut même pas relire les MdP qu'il avait entrés !

> Parfois on ajoute du sel (quelques caractères choisis au hasard) devant
> le mot de passe avant de calculer son empreinte. Cela permet de
> s'assurer que deux mots de passe identiques n'auront pas la même
> empreinte (puisque le sel sera différent). Il faut évidemment stocké le
> sel choisi en plus de l'empreinte pour pouvoir la recalculer lors de la
> vérification d'un mot de passe.

> Si mes souvenirs sont bons, la commande htpasswd fournie avec Apache
> n'utilise pas de sel.

Et est-ce que ça fait la même chose que la fonction PHP crypt() ?

Au final, on ne sait toujours pas s'il faut hachurer/crypt/htpasswd les
MdP pour un serveur Apache maquillé par Apple sur ses PC.

On lit ici ou là que sous Windows, il ne faudrait pas.
Que chez Free.fr, non plus.

Le coup de dire qu'un Mac c'est un Unix (a l'instar d'un Linux) me
parait un peu lèdge pour assurer que l'Apache y sera le même des 2 côtés.
(chez Free c'est aussi un Apache (sous Linux) ).


Chez moi, sur mon "serveur" Apache/Apple at home, c'est pire, j'ai dû
véroler mon fichier de conf ... le .htaccess semble ne même pas être
vu/détecté !

Jean Francois Ortolo

unread,
Oct 26, 2011, 6:57:47 AM10/26/11
to
Le 26/10/2011 12:36, SAM a écrit :
>
> Le coup de dire qu'un Mac c'est un Unix (a l'instar d'un Linux) me
> parait un peu lèdge pour assurer que l'Apache y sera le même des 2 côtés.
> (chez Free c'est aussi un Apache (sous Linux) ).
>
>


Bonjour Monsieur

Si votre serveur est Apache, comme le système Mac est équivalent à
Unix ou Linux, vous pouvez être tranquille : Le bon mode de cryptage est
l'équivalent de crypt(), soit DES.

Vous pouvez tester htpasswd avec l'option -d ( crypt(), ou DES ), ou
l'option -m ( MD5, l'option par défaut théoriquement ).

Je n'ai jamais essayé cette commande htpasswd , je ne sais pas si
elle demande le sel explicitement, dans ce cas, il faut le fournir
évidemment.

En ce qui me concerne, je choisirais l'option -d , avec un sel de
deux caractères ( ascii, pour faire bonne mesure ), et je choisirais un
mot de passe avec des lettres majuscules et minuscules, ou des chiffres
( ascii donc ).

Comme celà, il ne devrait pas y avoir de problème de mode de
caractères, peut-être différents entre Mac et Linux, ce serait de
l'ascii, même chose donc.

Je sais que l'option par défaut, est l'option -m

Celà peut invalider ce que je vous dis, car en ce qui concerne le
mode de hashage des mots de passe pour les fichier .htpasswd, mes
connaissances datent.

SAM

unread,
Oct 26, 2011, 7:09:19 AM10/26/11
to
Le 26/10/11 12:04, Olivier Masson a écrit :
>
> la plupart des
> mots de passe sont faciles à retrouver (voir par exemple
> http://www.onlinehashcrack.com/).
> Pour htpasswd, avec crypt, il utilise le sel standard pour DES, soit 2
> caractères, ce qui n'est pas bien sûr.

J'ai demandé à php de me crypter : ght2356
Ça m'a donné différentes "empreintes" :
$1$4Rbc35xM$On1atkc0XjJMrdKMt2UKe/
$1$ijs8y7T0$cYqzIbFae0XgzaVb5GWAB.
$1$4qISgorh$6EvCg.JpFOY9dJn.EUTQo/
et elles n'ont pas plu à onlinehashcrack (avec ou sans le $1$ du début)


Alors j'ai tenté la méthode "Apache"
au terminal j'ai fait :
htpasswd -b /Users/STEF/Sites/mesEssais/.htpasswd admin admin
et ça m'a bien modifié le fichier de MdP
admin:6m7TMuhLE2HUM
... savoir si c'est salé ou sucré ... ? ?

le crypté/heu/chiffré : 6m7TMuhLE2HUM
n'est toujours pas accepté par le site de crackage ... !

Pour sûr ! s'il faut le limiter à :
« A hash contains only A to F and 0 to 9 characters »

Jean Francois Ortolo

unread,
Oct 26, 2011, 7:27:04 AM10/26/11
to
Le 26/10/2011 13:09, SAM a écrit :
>
> Alors j'ai tenté la méthode "Apache"
> au terminal j'ai fait :
> htpasswd -b /Users/STEF/Sites/mesEssais/.htpasswd admin admin
> et ça m'a bien modifié le fichier de MdP
> admin:6m7TMuhLE2HUM
> ... savoir si c'est salé ou sucré ... ? ?
>
> le crypté/heu/chiffré : 6m7TMuhLE2HUM
> n'est toujours pas accepté par le site de crackage ... !
>
> Pour sûr ! s'il faut le limiter à :
> « A hash contains only A to F and 0 to 9 characters »
>


Bonjour Monsieur

En utilisant le mode de hashage par défaut ( équivalent à -m , soit
MD5 ), vous n'avez parobablement pas choisi le bon mode hashage.

Par ailleurs, dans votre ligne de commande :

htpasswd -b /Users/STEF/Sites/mesEssais/.htpasswd admin admin

Vous choisissez comme login : admin, et comme mot de passe : admin

Si vous faites cette ligne de commande :

htpasswd -bd /Users/STEF/Sites/mesEssais/.htpasswd admin mot_de_passe

Avec votre mot de passe à la place de mot_de_passe ,

normalement, le sel devrait être les deux premières lettres du mot de
passe choisi, et vous devraiez pouvoir vous connecter, avec le login :
admin , et le mot de passe : mot_de_passe ( de préférence en ascii ).

Remarquez le petit d que j'ai ajouté après le -b

Celà configure le mode de hashage, à CRYPT, ou DES ( d'après Monsieur
Gaborit ).

En mode CRYPT, je me souviens bien, que le sel, est les deux
premières lettres du mot de passe.

Donc, en répétant cette même commande avec le même mot de passe, vous
devriez obtenir le même mot de passe crypté après : admin:

SAM

unread,
Oct 26, 2011, 8:09:46 AM10/26/11
to
Le 26/10/11 13:27, Jean Francois Ortolo a écrit :
> Le 26/10/2011 13:09, SAM a écrit :
>>
>> Alors j'ai tenté la méthode "Apache"
>> au terminal j'ai fait :
>> htpasswd -b /Users/STEF/Sites/mesEssais/.htpasswd admin admin

> En utilisant le mode de hashage par défaut ( équivalent à -m , soit MD5
> ), vous n'avez parobablement pas choisi le bon mode hashage.

Oui, j'ai choisi le hashage "par défaut".
Ha? probablement pas le bon ?

Recommencé, ça me donne cette fois :
admin:DxSMVy32ItVt.

> Par ailleurs, dans votre ligne de commande :
>
> htpasswd -b /Users/STEF/Sites/mesEssais/.htpasswd admin admin
>
> Vous choisissez comme login : admin, et comme mot de passe : admin

oui, oui, j'ai choisi comme MdP 'admin'
ce ne doit pas être interdit, non ?

> Si vous faites cette ligne de commande :
>
> htpasswd -bd /Users/STEF/Sites/mesEssais/.htpasswd admin mot_de_passe
>
> Avec votre mot de passe à la place de mot_de_passe ,

oui : admin
;-)
C'est pour un exemple.
S'pa ?

> normalement, le sel devrait être les deux premières lettres du mot de
> passe choisi, et vous devraiez pouvoir vous connecter, avec le login :
> admin , et le mot de passe : mot_de_passe ( de préférence en ascii ).
>
> Remarquez le petit d que j'ai ajouté après le -b
>
> Celà configure le mode de hashage, à CRYPT, ou DES ( d'après Monsieur
> Gaborit ).

J'obtiens cette fois :
admin:ykJ/Yo5sGnfbc
qui contient, toujours et encore, autre chose que les chiffres hexa (A-F
0-9) voulus pas le site de crackage.

> Donc, en répétant cette même commande avec le même mot de passe, vous
> devriez obtenir le même mot de passe crypté après : admin:

Ça le change à chaque répétition :
admin:Gz3EZe8rnRA8M
admin:3egx8qY.94lh.
admin:UmXJL9v2p5tpI
avec :
htpasswd -bd /Users/STEF/Sites/mesEssais/.htpasswd admin admin



htpasswd -bd /Users/STEF/Sites/mesEssais/.htpasswd truc bidule

Hop !
admin:UmXJL9v2p5tpI
truc:qiuCA0EunY7bA


--
Stéphane Moriaux avec/with iMac-intel

* Français - détecté
* Anglais
* Français
* Espagnol

* Anglais
* Français
* Espagnol

<javascript:void(0);>

Denis Beauregard

unread,
Oct 26, 2011, 8:47:19 AM10/26/11
to
Le Wed, 26 Oct 2011 14:09:46 +0200, SAM
<stephanemor...@wanadoo.fr.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:

>> Donc, en répétant cette même commande avec le même mot de passe, vous
>> devriez obtenir le même mot de passe crypté après : admin:
>
>Ça le change à chaque répétition :
> admin:Gz3EZe8rnRA8M
> admin:3egx8qY.94lh.
> admin:UmXJL9v2p5tpI

C'est génial, je trouve ! Ainsi, avec une table de mots de passe
possibles comme un dictionnaire, il devient impossible de déterminer
le vrai mot de passe.

J'avoue que j'ai utilisé ce concept sur un site : à chaque jour, le
mot de passe intermédiaire est différent et donc si un usager donne
son mot de passe, il ne répondra pas le lendemain. Dans mon cas, c'est
le nom des pages affichées qui contient le mot de passe (donc, on ne
peut pas voir l'information sans mot de passe).


Denis

SAM

unread,
Oct 26, 2011, 8:47:34 AM10/26/11
to
Le 26/10/11 12:57, Jean Francois Ortolo a écrit :
> Le 26/10/2011 12:36, SAM a écrit :
>>
>> Le coup de dire qu'un Mac c'est un Unix (a l'instar d'un Linux) me
>> parait un peu lèdge pour assurer que l'Apache y sera le même des 2 côtés.
>> (chez Free c'est aussi un Apache (sous Linux) ).
>
> Bonjour Monsieur

Bonjour très cher,

> Je n'ai jamais essayé cette commande htpasswd , je ne sais pas si elle
> demande le sel explicitement, dans ce cas, il faut le fournir évidemment.

Le man est ici :
<http://httpd.apache.org/docs/2.0/programs/htpasswd.html>
Je n'y vois pas d'allusion à du salt.

> En ce qui me concerne, je choisirais l'option -d , avec un sel de deux
> caractères ( ascii, pour faire bonne mesure ), et je choisirais un mot
> de passe avec des lettres majuscules et minuscules, ou des chiffres (
> ascii donc ).

en général, pour les choses pouvant être codées, interprétées, j'essaie
de me limiter à l'ASCII

> Comme celà, il ne devrait pas y avoir de problème de mode de caractères,
> peut-être différents entre Mac et Linux, ce serait de l'ascii, même
> chose donc.
>
> Je sais que l'option par défaut, est l'option -m

J'ai l'impression que le man me dit : function crypt() du système

> Bien amicalement.
>
> Jean François Ortolo

Bon .. la doc Apache ... y a qu'eux qui doivent la comprendre ? !
Elle n'est pas francisée et ils disent
- flat-file
- realm
- digest authentication
(pour sûr !
tt l'monde sait ce qu'est une authentification digérée)

et même passé à google-traducteur (qui n'en fait qu'à sa tête et mal) ...
ça ne prend pas vraiment de sens ...
« Méthode qui utilise Apache pour sérialiser plusieurs enfants à
accepter les demandes sur les sockets réseau »
- quels "enfants" ? (c'est quoi ?)
- sérialiser ... Ha ? et ?
- sockets réseau ? .... des chaussettes pour réseau ? et quel réseau ?


Pas réussi à trouver chez Apache.org ce qu'ils entendaient par :
Basic / Digest
...


Cordialement,

Gerald

unread,
Oct 26, 2011, 9:10:11 AM10/26/11
to
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> wrote:

> > Non, il me semblait que le cryptage des mots de passe était une
> > *option*. Tu as une source fiable de ça ?
> >>
> Ben voilà l'errreur . ;)

Re-bonjour et mille mille merci à tous pour votre aide !
Merci à Jean-François, Vincent, Paul, SAM, Olivier, Denis... et les
autres. Votre patience est récompensée.

Évidemment il faut que j'explique pourquoi ça marche et quelles pistes
étaient les bonnes :

- TextWrangler pour la création du htaccess était probablement une très
bonne idée principalement parce que dans son dialogue d'enregistrement
il propose tout un tas d'options *dont* le choix entre le mode Unix (LF,
line-feed) et le mode Mac (CR, carriage return) (et PC aussi) pour les
fins de ligne ET clairement le mode Mac n'est PAS reconnu (erreur 404),
il faut bien du fichier à la mode Unix, ...*et également* parce qu'il
propose différents formats de texte et que l'UTF-8 n'autorise pas les
accents (ou les transmet comme du garbage) tandis que l'ISO-latin 1
marche au poil avec tous les accents qu'on veut (faudra quand même
vérifier comment ça apparaît sur d'autres plateformes).

- Du fait d'un bon esprit généralisé ici, personne ne m'a renvoyé RTFM,
et pourtant ce n'a pas été inutile d'y aller voir ; le manuel est en
français et particulièrement bien documenté ici :
<http://httpd.apache.org/docs/2.2/>
L'explication de mes misères se trouvant plus particulièrement ici :
<http://httpd.apache.org/docs/2.2/mod/mod_authn_file.html#authuserfile>
c'est-à-dire dans la quasi obligation, fort bien identifiée tout
récemment par Jean-François et Paul, d'utiliser dans le Terminal l'outil
htpasswd, le cryptage du mot de passe, décrit comme optionnel dans
d'autres littératures (dans "comment ça marche" par exemple) ne l'étant
pas du tout mais étant bien obligatoire.

Rien à dire de plus, ça marche et c'est une solution locale qui a
évidemment ses limites mais qui permet de mettre en ligne des documents
qu'on ne souhaite pas retrouver aux quatre coins d'internet : photos de
famille, voire carnavalesques et compromettantes :-)

Grand merci à tous, donc, vous avez été TRÈS bien !

--
Gérald

Olivier Masson

unread,
Oct 26, 2011, 9:38:37 AM10/26/11
to
Le 26/10/2011 14:47, Denis Beauregard a écrit :
> Le Wed, 26 Oct 2011 14:09:46 +0200, SAM
> <stephanemor...@wanadoo.fr.invalid> écrivait dans
> fr.comp.infosystemes.www.auteurs:
>
>>> Donc, en répétant cette même commande avec le même mot de passe, vous
>>> devriez obtenir le même mot de passe crypté après : admin:
>>
>> Ça le change à chaque répétition :
>> admin:Gz3EZe8rnRA8M
>> admin:3egx8qY.94lh.
>> admin:UmXJL9v2p5tpI
>
> C'est génial, je trouve ! Ainsi, avec une table de mots de passe
> possibles comme un dictionnaire, il devient impossible de déterminer
> le vrai mot de passe.
>

À lire cette réponse et celles de SAM, j'ai la nette impression que tout
n'est pas clair pour certains.
Le sujet n'étant pas forcément des plus simples, je vous suggère d'aller
chercher de la doc :)

SAM

unread,
Oct 26, 2011, 10:53:14 AM10/26/11
to
Le 26/10/11 15:38, Olivier Masson a écrit :
> Le 26/10/2011 14:47, Denis Beauregard a écrit :
>> Le Wed, 26 Oct 2011 14:09:46 +0200, SAM
>> <stephanemor...@wanadoo.fr.invalid> écrivait dans
>> fr.comp.infosystemes.www.auteurs:
>>
>>>> Donc, en répétant cette même commande avec le même mot de passe, vous
>>>> devriez obtenir le même mot de passe crypté après : admin:
>>>
>>> Ça le change à chaque répétition :
>>> admin:Gz3EZe8rnRA8M
>>> admin:3egx8qY.94lh.
>>> admin:UmXJL9v2p5tpI
>>
>> C'est génial, je trouve ! Ainsi, avec une table de mots de passe
>> possibles comme un dictionnaire, il devient impossible de déterminer
>> le vrai mot de passe.
>>
>
> À lire cette réponse et celles de SAM,

quoi ?
que le résultat crypté n'est jamais le même pour un même MdP ?
D'expérience, c'est ce qu'il semblerait.

> j'ai la nette impression que tout n'est pas clair pour certains.
> Le sujet n'étant pas forcément des plus simples, je vous suggère d'aller
> chercher de la doc :)


Ho! Moi ... les MdP ... ce n'est pas exactement ma passion ;-)
Je sais comment faire pour en mettre sur mes sitos chez Free, çam'suffit
bien.
(de ttes façons quand je vois la foule s'écarter de ces sitos (qui n'ont
rien de vraiment secret) ... avant que qque chose ou qu'un n'y vienne
tenter un décryptage ... on a l'temps)

Vincent

unread,
Oct 26, 2011, 6:59:14 PM10/26/11
to
Le 26/10/2011 15:10, Gerald a écrit :
> Grand merci à ...

Vincent, François, Paul et les autres... :-)

0 new messages