plus d'infos sur http://studenti.unina.it/~ncuomo/syskey/syskey.txt
Cdlt
-- Fabrice Meillon Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
a écrit dans le message de news: 0f4901c4fefa$38fd9b00$ Bonjour, Est-ce que Syskey.exe intègre dans sa conception et action: certificat valide, Efs, en dire plus s'il y a ? Merci
plus d'infos sur http://studenti.unina.it/~ncuomo/syskey/syskey.txt
Cdlt
--
Fabrice Meillon
Architecte Infrastructure
Division Développeurs et Plate-Forme d'Entreprise
Microsoft France
<anonymous@discussions.microsoft.com> a écrit dans le message de news:
0f4901c4fefa$38fd9b00$a601280a@phx.gbl...
Bonjour,
Est-ce que Syskey.exe intègre dans sa conception et
action: certificat valide, Efs, en dire plus s'il y a ?
Merci
plus d'infos sur http://studenti.unina.it/~ncuomo/syskey/syskey.txt
Cdlt
-- Fabrice Meillon Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
a écrit dans le message de news: 0f4901c4fefa$38fd9b00$ Bonjour, Est-ce que Syskey.exe intègre dans sa conception et action: certificat valide, Efs, en dire plus s'il y a ? Merci
Jean-Claude BELLAMY
Dans le message news:0f4901c4fefa$38fd9b00$ ,
s'est ainsi exprimé:
Bonjour, Est-ce que Syskey.exe intègre dans sa conception et action: certificat valide, Efs, en dire plus s'il y a ?
Non, SYSKEY est un procédé de renforcement de l'authentification assez rudimentaire. Il date de NT4 (peut-être NT3, mais je ne m'en souviens pas)
Le principe est le suivant : Un administrateur définit un "super mot de passe" pour ouvrir une session, en plus du mot de passe propre à chaque compte. Ce mot de passe est saisi en lançant SYSKEY.
Cet outil offre alors 3 choix possibles :
1) Lors de la séquence de démarrage initiale du système, mais avant que le système ne soit disponible pour l'ouverture de session par des utilisateurs, ce mot de passe est demandé pour récupérer la clé système. Ce mot de passe n'est pas stocké en clair sur le système, mais seulement sous la forme de hachage MD5. (au niveau algorithme de hachage, on fait mieux de nos jours avec SHA-1 et suivants!)
2) L'administrateur décide de stocker cette clef sur une disquette. Elle doit être insérée à l'invite après l'initialisation de la séquence de démarrage par Windows, mais avant que les utilisateurs ne puissent ouvrir une session sur le système. Elle n'est stockée nulle part sur le système local.
3) La clef est stockée dans une section sécurisée du registre, elle-même protégée par le contrôle d'accès et une fonction de dissimulation. Cette option permet l'ouverture de sessions de façon autonome (aucune action n'est requise de la part de l'utilisateur). C'est l'option par défaut.
EFS est apparu seulement avec W2K , et ne concerne que le chiffrement des données, et non pas l'ouverture de session. La seule ressemblance est dans le mécanisme de EFS qui fait appel au hachage (SHA-1) du mot de passe de l'utilisateur pour générer une clef maitre qui va créer une clef de session laquelle va enfin chiffrer la clef privée qui servira au déchiffrement des données. (ouf!)
Mais il est relativement facile de se créer son propre mécanisme de renforcement du mécanisme d'authentification, par réécriture de la DLL "GINA" (Graphical Identification aNd Authentication). Par défaut c'est "%systemroot%system32msgina.dll", définie dans la clef HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonGinaDLL
La réécriture de "GINA.DLL" va essentiellement consister à modifier la fonction "WlxLoggedOutSAS" (cette nouvelle GINA se contentera d'appeler MSGINA.DLL pour toutes les fonctions autres que "WlxLoggedOutSAS") C'est là où on demandera la lecture d'une clef supplémentaire, sur CD, clef USB, ..., et avec lm'algorithme de chiffrement + hachage que l'on veut.
J'ai écrit une telle DLL (en Delphi), mais avec un usage un peu différent. Ma préoccupation était de demander un password supplémentaire UNIQUEMENT aux administrateurs.
Si au login le compte saisi est celui d'un admin (utilisation de "NetUserGetInfo" de l'APi NetAPI32.dll), il y a une boite de dialogue qui demande d'insérer une disquette clef et/ou de saisir une clef au clavier.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
Dans le message news:0f4901c4fefa$38fd9b00$a601280a@phx.gbl ,
anonymous@discussions.microsoft.com <anonymous@discussions.microsoft.com>
s'est ainsi exprimé:
Bonjour,
Est-ce que Syskey.exe intègre dans sa conception et
action: certificat valide, Efs, en dire plus s'il y a ?
Non, SYSKEY est un procédé de renforcement de l'authentification assez
rudimentaire.
Il date de NT4 (peut-être NT3, mais je ne m'en souviens pas)
Le principe est le suivant :
Un administrateur définit un "super mot de passe" pour ouvrir une session,
en plus du mot de passe propre à chaque compte. Ce mot de passe est saisi en
lançant SYSKEY.
Cet outil offre alors 3 choix possibles :
1) Lors de la séquence de démarrage initiale du système,
mais avant que le système ne soit disponible pour
l'ouverture de session par des utilisateurs, ce mot de
passe est demandé pour récupérer la clé système.
Ce mot de passe n'est pas stocké en clair sur le système,
mais seulement sous la forme de hachage MD5.
(au niveau algorithme de hachage, on fait mieux de nos
jours avec SHA-1 et suivants!)
2) L'administrateur décide de stocker cette clef sur une disquette.
Elle doit être insérée à l'invite après l'initialisation de la
séquence de démarrage par Windows, mais avant que
les utilisateurs ne puissent ouvrir une session sur le système.
Elle n'est stockée nulle part sur le système local.
3) La clef est stockée dans une section sécurisée du registre,
elle-même protégée par le contrôle d'accès et une fonction
de dissimulation. Cette option permet l'ouverture de sessions
de façon autonome (aucune action n'est requise de la part
de l'utilisateur).
C'est l'option par défaut.
EFS est apparu seulement avec W2K , et ne concerne que le chiffrement des
données, et non pas l'ouverture de session.
La seule ressemblance est dans le mécanisme de EFS qui fait appel au hachage
(SHA-1) du mot de passe de l'utilisateur pour générer une clef maitre qui va
créer une clef de session laquelle va enfin chiffrer la clef privée qui
servira au déchiffrement des données. (ouf!)
Mais il est relativement facile de se créer son propre mécanisme de
renforcement du mécanisme d'authentification, par réécriture de la DLL
"GINA" (Graphical Identification aNd Authentication).
Par défaut c'est "%systemroot%system32msgina.dll", définie dans la clef
HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonGinaDLL
La réécriture de "GINA.DLL" va essentiellement consister à modifier la
fonction "WlxLoggedOutSAS"
(cette nouvelle GINA se contentera d'appeler MSGINA.DLL pour toutes les
fonctions autres que "WlxLoggedOutSAS")
C'est là où on demandera la lecture d'une clef supplémentaire, sur CD,
clef USB, ..., et avec lm'algorithme de chiffrement + hachage que l'on veut.
J'ai écrit une telle DLL (en Delphi), mais avec un usage un peu différent.
Ma préoccupation était de demander un password supplémentaire UNIQUEMENT aux
administrateurs.
Si au login le compte saisi est celui d'un admin (utilisation de
"NetUserGetInfo" de l'APi NetAPI32.dll), il y a une boite de dialogue qui
demande d'insérer une disquette clef et/ou de saisir une clef au clavier.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr
Bonjour, Est-ce que Syskey.exe intègre dans sa conception et action: certificat valide, Efs, en dire plus s'il y a ?
Non, SYSKEY est un procédé de renforcement de l'authentification assez rudimentaire. Il date de NT4 (peut-être NT3, mais je ne m'en souviens pas)
Le principe est le suivant : Un administrateur définit un "super mot de passe" pour ouvrir une session, en plus du mot de passe propre à chaque compte. Ce mot de passe est saisi en lançant SYSKEY.
Cet outil offre alors 3 choix possibles :
1) Lors de la séquence de démarrage initiale du système, mais avant que le système ne soit disponible pour l'ouverture de session par des utilisateurs, ce mot de passe est demandé pour récupérer la clé système. Ce mot de passe n'est pas stocké en clair sur le système, mais seulement sous la forme de hachage MD5. (au niveau algorithme de hachage, on fait mieux de nos jours avec SHA-1 et suivants!)
2) L'administrateur décide de stocker cette clef sur une disquette. Elle doit être insérée à l'invite après l'initialisation de la séquence de démarrage par Windows, mais avant que les utilisateurs ne puissent ouvrir une session sur le système. Elle n'est stockée nulle part sur le système local.
3) La clef est stockée dans une section sécurisée du registre, elle-même protégée par le contrôle d'accès et une fonction de dissimulation. Cette option permet l'ouverture de sessions de façon autonome (aucune action n'est requise de la part de l'utilisateur). C'est l'option par défaut.
EFS est apparu seulement avec W2K , et ne concerne que le chiffrement des données, et non pas l'ouverture de session. La seule ressemblance est dans le mécanisme de EFS qui fait appel au hachage (SHA-1) du mot de passe de l'utilisateur pour générer une clef maitre qui va créer une clef de session laquelle va enfin chiffrer la clef privée qui servira au déchiffrement des données. (ouf!)
Mais il est relativement facile de se créer son propre mécanisme de renforcement du mécanisme d'authentification, par réécriture de la DLL "GINA" (Graphical Identification aNd Authentication). Par défaut c'est "%systemroot%system32msgina.dll", définie dans la clef HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonGinaDLL
La réécriture de "GINA.DLL" va essentiellement consister à modifier la fonction "WlxLoggedOutSAS" (cette nouvelle GINA se contentera d'appeler MSGINA.DLL pour toutes les fonctions autres que "WlxLoggedOutSAS") C'est là où on demandera la lecture d'une clef supplémentaire, sur CD, clef USB, ..., et avec lm'algorithme de chiffrement + hachage que l'on veut.
J'ai écrit une telle DLL (en Delphi), mais avec un usage un peu différent. Ma préoccupation était de demander un password supplémentaire UNIQUEMENT aux administrateurs.
Si au login le compte saisi est celui d'un admin (utilisation de "NetUserGetInfo" de l'APi NetAPI32.dll), il y a une boite de dialogue qui demande d'insérer une disquette clef et/ou de saisir une clef au clavier.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
