Problème entre Filevault et mot de passe de session

[Membre supprimé 1060554]

Pereira

après différents tests, le seul caractère accentué qui bloque à l'ouverture c'est l'@, les autres passent

Ta trouvaille permet de circonscrire le problème en pratique : « Éviter l'arobase ! ». Quant à concevoir théoriquement parlant les raisons qui font que le seul arobase pose problème à l'écran de déverrouillage d'un Volume Logique Chiffré : comme disait Rudyard Kipling : « c'est une autre histoire »...

ce bug [...] n'est pas traité pour le moment par Apple alors qu'il en a connaissance depuis 2 ans, ce qui me déçois de la part d'une marque qui n'a à gérer que ses propres machines sur son propre système. Tout fout le camp.

Un OS est un univers logique. Le philosophe Leibniz disait de l'Univers qu'il ressemble à un « étang plein de poissons dont chaque poisson est lui-même un étang plein de poissons ». L'architecture logique du CoreStorage impliquée par le chiffrement «FileVault» est elle-même un pareil étang plein de poissons dans l'étang plein de poissons de macOS.

Le CoreStorage (avec le chiffrement «FileVault-2» comme dispositif particulier) a été créé logiquement avec l'OS «Lion 10.7». Ce dispositif implique notamment d'affecter la partition de récupération «Recovery HD» au rôle de démarreur logique (« booter ») du Volume Logique CoreStorage. L'écran de déverrouillage du Volume Logique Chiffré, en cas d'activation de «FileVault», est donc déployé par cette fonction « booter » de la «Recovery HD» (dont la ressource de Recovery OS - OS de secours démarrable - passe au second rang).

Mon § précédent était destiné à suggérer la complexité logique impliquée dans ce simple affichage de l'écran initial de déverrouillage d'un Volume Logique Chiffré. Lorsque cet écran s'affiche > aucun kernel (noyau) n'est encore démarré > aucun jeu de kexts (extensions su noyau) injecté dans le kernel > aucun OS initialisé (ce n'est pas comme le LoginWindow classique, qui intervient après l'initialisation du Système) => on a affaire à un fonctionnement a minimo (témoin : la lenteur de déplacement du pointeur à cet écran). Régler l'affaire du bogue de reconnaissance de l'arobase à cet écran dans un clavier non-US : pas sûr que le problème se laisse circonscrire à une ou deux lignes de code.

Il faudrait alors une décision politique d'entreprise d'affecter une équipe d'ingénieurs à l'examen de ce problème pendant un temps x > examen s'inscrivant nécessairement dans le cadre du fonctionnement logique d'ensemble du CoreStorage : un détail impliquant un « étang plein de poissons » - et un « étang » logique particulièrement redoutable a priori > celui de la création logique la plus sophistiquée de l'histoire d'Apple. Pas sûr que ce type de décision se prenne à la légère.

Même si je conçois ta déception > je ne te suivrai donc pas dans ta généralisation : « Tout fout le camp » > car le domaine du CoreStorage est théoriquement super-intriqué : un détail y implique l'ensemble et l'ensemble est super-complexe.

 

[bompi]

Euh... En fait, c'est un tout bêtement un bug et un bug proche de l'inacceptable, effectivement.

En dépit de l'admiration que je peux porter à G.W.Leibniz, il ne nous est ici d'aucun secours. On a affaire au cas typique d'une absence crasse de réflexion sur ce qu'on manipule (dans le cas présent, un caractère tout bête et, pour le mot de passe dans son entier, une chaîne de caractères). Il n'y a véritablement rien de compliqué à cela, et c'est une des premières choses que l'on apprend (ou devrait apprendre) en informatique.

Pour peu que l'on ait une idée à peu près correcte de la programmation, le contenu d'un mot de passe devrait être géré sans problème, d'autant qu'il s'agit ici d'un caractère ASCII, qui plus est un caractère imprimable et que c'est une des plus anciennes codifications informatiques ! Il ne s'agit même pas d'un caractère avec diacritique (é, ç, ñ etc.)

Je ne sais pas si tout fout le camp ; je dirais plutôt que rien n'a changé. J'espère simplement que la personne qui a codé ce bout de programme ne travaille pas sur les algorithmes du projet Titan...

 

[Novezan]

Voilà, maintenant tout le monde sait que j'utilise un @ dans mon mot de passe !!! LOL

 

[bompi]

Voilà, maintenant tout le monde sait que j'utilise un @ dans mon mot de passe !!! LOL

D'un autre côté tu me rends service : l'arobase fait partie des caractères que j'utilise à l'occasion dans mes mots de passe.

Note que si ton mot de passe fait au moins 95 caractères de long, c'est-à-dire le nombre de caractères imprimables de l'ASCII :

savoir qu'il contient l'arobase n'est pas déterminant... :zen:

Cependant, vu que l'@ pose des problèmes, je te déconseille d'utiliser l'espace, qui est souvent un séparateur (donc le risque est grand d'avoir un autre bug) ; ça ne te laisse plus que 93 caractères.

 

[Pereira]

@macomaniac
Je comprend les circonstances atténuantes que tu évoques, une société se doit elle de mettre tout en oeuvre afin de résoudre un bug mineur ("mineur" quand on connait la source du problème et sa résolution "artisanale", mais crois moi, pour avoir passé une semaine à tenter de comprendre de quoi il en retournait (car dans mon activité avoir un mac chiffré avec un mot de passe "sérieux" est essentiel) ce bug n'a rien de mineur) ?
Cette société à 3 solutions :
- Mettre tout en oeuvre afin que ses machines tournent comme des horloges, cela a un coût (mais il m'a semblé qu'Apple avait une trésorerie supérieure au budget de l'Irlande) mais également un bénéfice, la réputation de proposer des produits d'une fiabilité exemplaire.
- Dire bon, sur ce coup la, on n'a pas été bon, il y a un petit bug, voici comment le contourner facilement, et expliquer qu'il ne faut pas utiliser l'@ dans un MDP et que ça ira mieux la prochaine fois, lors du prochain système (ça va certes simplifie run peu la tâche des pirates, mais un bon MDP de + de 10 caractères avec chiffres majuscules caractères spéciaux on est protégé). La société fait preuve d'humilité, faute avouée à moitié pardonnée et elle sait communiquer avec ses clients.
- Faire le canard

La pomme a choisi de faire le canard, pas sur que ce soit le plus judicieux de sa part.

 

[Membre supprimé 1060554]

Je ne trouve pas évident de discerner la raison du problème : mot-de-passe d'utilisateur comportant des caractères spéciaux (l'@ spécifiquement) non reconnu en clavier AZERTY à l'écran de déverrouillage du Volume Logique en cas d'activation de «FileVault».

J'utilise comme Mac un MacBook Pro 17" i7 2.5 GHz Late 2011. De nombreux SSD sont attachés (en interne = SATA-3 / externe = Thunderbolt-1) à ce Mac > avec nombre de partitions > ce qui me permet de démarrer toutes sortes de Systèmes. J'ai répété une expérimentation que j'avais effectuée à la lecture du message inaugural de Nozeran :

--> dans l'OS «Sierra 10.2.3» du volume d'une de ces partitions > je crée un utilisateur bibi dont le mot-de-passe est : @&é"'(§è!çà)- > cela fait j'active «FileVault» en habilitant l'utilisateur bibi à déverrouiller le Volume Logique verrouillé au démarrage par le chiffrement.

Eh bien ! je ne rencontre aucune difficulté, sur mon clavier AZERTY, en clavier logique Français par défaut, à faire reconnaître ce mot-de-passe à l'écran initial de déverrouillage - malgré la présence de l'@ et d'une kyrielle d'autres caractères spéciaux.

Cette situation me semble exemplaire : elle illustre l'état des lieux classiques en ce qui concerne le chiffrement «FileVault». Jusqu'à ce que Nozeran ouvre un fil le 18 Mars 2016 sur le forum de MacGé > personne n'avait attesté à ma connaissance d'un problème de reconnaissance de mot-de-passe à l'écran de déverrouillage d'un Volume Logique dépendant d'un chiffrement «FileVault», quels que soient les caractères employés.

Bref : du 20 Juillet 2011 (date de publication de l'OS «Lion 10.7» introduisant le CoreStorage et la nouvelle version du chiffrement «FileVault-2» qui en dépendait) au 18 Mars 2016 => personne n'a attesté d'un bogue quelconque invalidant la saisie de caractères spéciaux dans un mot-de-passe à l'écran initial «FileVault» - ce pour la raison qu'il n'y avait pas de bogue.

C'est seulement avec de nouveau modèles physiques de MacBook Pro : Retina_2015, puis Retina_2016 (format 13" précisément) que le problème de non-reconnaissance de mots-de-passe comportant des caractères spéciaux s'est avéré pour un clavier logique non-US.

Que peut avoir à faire le modèle du Mac dans cette affaire ? - il est absolument clair que le problème ne dépend pas du Système d'exploitation («El Capitan10.11» ou «Sierra 10.12»), parce que, lorsque l'écran de déverrouillage du Volume Logique verrouillé par le chiffrement est affiché à l'écran du Mac > l'OS recelé dans le Volume Logique verrouillé n'est absolument pas activé. Et pas non plus le Recovery OS de la partition de récupération Recovery HD : aucun OS n'est encore activé.

Que se passe-t-il alors ? - le mécanisme logique suivant : le Programme Interne du Mac (EFI) > accède au seul volume monté disponible : celui de la Recovery HD > dans ce volume : 3 dossiers se trouvent présents -->

- le dossier de boot du Recovery OS intitulé com.apple.recovery.boot, lequel est entièrement hors du coup dans le cas que nous décrivons ;

- un dossier System > recelant le répertoire Library > recelant le dossier CoreServices > recelant un boot_loader : boot.efi flanqué de 2 fichiers plist de vérification de compatibilité : PlatformSupport.plist & SystemVersion.plist --> nous tenons ici le fichier du démarreur logique exécutable par l'EFI.

- un dossier absolument spécifique et n'existant qu'en cas de présence d'un CoreStorage Chiffré : com.apple.boot.P recelant 3 répertoires : Library > System > usr. Library contient un fichier de préférence com.apple.Boot.plist qui ne s'adresse qu'au boot_loader boot.efi une fois activé / usr contient un dossier standalone de secours (redondance) --> c'est le répertoire System qui concentre dans sa Library les outils logiques spéciaux :

- un sous-dossier PrelinkedKernels contenant un cache de démarrage prelinkedkernel activable par le boot_loader : boot.efi de manière classique ;

- un sous-dossier Caches > sous dossier com.apple.corestorage > sous-dossier EFILoginLocalizations > dans lequel sont contenus les fichiers .efires (efi_resources) traditionnels du démarrage en cas de Volume Logique Chiffré (dont : disk_passwordUI.efires > loginui.efires > Lucida13.efires).
​

Voici comment je me représente le mécanisme : l'EFI visite le dossier EFILoginLocalizations (comme elle le fait de la NVRAM) > charge les instructions des fichiers resources de l'efi .efires > fait s'afficher l'écran de déverrouillage : on est donc ici dans un pré-boot complet --> pas de boot_loader encore exécuté > pas de kernel activé > pas de kexts injectées > pas de Système démarré --> il n'y a que les ressources hardware basiques activées : RAM > processeur > clavier > écran.​

Pourquoi ce mécanisme sans bogue sur les Macs classiques (quel que soit l'OS) s'avère-t-il problématique sur de nouveaux MacBook Pro (à partir de 2015) ? - dans mes conversations antérieures avec Nozeran > la variable incriminable paraissait l'EFI, car le Programme Interne des Macs comporte des variations en fonction des modèles. Ce serait présumablement l'EFI des nouveaux MacBook Pro qui induirait le problème de non-reconnaissance d'un mot-de-passe incluant des caractères spéciaux (il est très possible que le problème ne se présente pas avec les nouveaux Macs non-MacBook Pro, genre iMac ou MacBook).

À titre d'hypothèse, on aurait donc un triangle problématique : version de l'EFI x hardware basique x fichiers .efires du CoreStorage Chiffré (la police de référence étant Lucida13).

=> cela fait beaucoup de facteurs hétérogènes en interaction (d'où mon image leibnizienne de l'« étang plein de poissons ») - un cas très différent de la bourde du «TimeMachine» d'«El Capitan» dont les sauvegardes n'étaient pas démarrables à cause d'une erreur d'adresse cf. Booter sur Sauvegarde TM --> ma détection du bogue d'adressage au message #11) > erreur jamais corrigée malgré sa ponctualité.

Certes il y a des enjeux sérieux de sécurité touchant le chiffrement «FileVault» > mais quand je contemple la complexité du mécanisme logique impliqué > le caractère récent (et pas inaugural) du problème de saisie des caractères spéciaux > sa localisation à un modèle de Mac seulement > le chantier (en cours) du nouveau système de fichiers APFS (qui me paraît devoir relever le CoreStorage en impliquant un nouveau procédé de chiffrement) => j'ai du mal (personnellement) à me "sentir" enclin à une incrimination abrupte (qui n'est jamais qu'une accélération généralisatrice à partir d'un cas particulier de l'ordre du sentiment).

C'est regrettable > mais je ne joindrai pas mon caillou à la lapidation d'Apple qui semble être encouragée de diverses parties dans l'espace général du site MacGé.

 

[bompi]

Je ne partage évidemment pas ton point de vue Nos ordinateurs font sans cesse, pour la moindre de nos actions, des traitements bien plus complexes que cela. Ne serait-ce que pour l'envoi du présent post ou de son affichage sur un écran, avec des passages d'informations entre matériels, systèmes, logiciels de sources et fournisseurs fort divers.

Alors qu'ici, tout est maîtrisé (?) par Apple et, je ne dis pas que c'est simple, mais cela ne présente rien de bien folichon non plus.

On peut se ramener à des constatations simples :

• l'utilisateur fournit une information en entrée
  
• cette information est enregistrée
• ce qui est enregistré est utilisé par quelque(s) routine(s)

La question revient, indépendamment de la complexité des opérations qui suivront, à la capacité à reconnaître des entrées, les stocker correctement (c'est-à-dire sans perte d'information) puis à les utiliser (toujours sans perte d'information, d'une part, et en respectant les champs de valeurs autorisés des routines appelées).

grosso modo, c'est la base de l'informatique : capter des entrées, les travailler, émettre des sorties, avec à chaque étape un minimum de perte d'information [on n'envoie pas l'information inutile au destinataire].

On peut certes constater que le caractère incriminé est l'@ et il n'est pas tout à fait comme les autres (il a un sens particulier en Objective-C, par exemple, et c'est un séparateur bien connu). Ce qui est assez épatant est qu'il s'agit d'un mot de passe, donc quelque chose qui n'est justement pas beaucoup utilisé tel quel : on examine plutôt sa transformation par des algorithmes et on ne le stocke pas tout cru, sauf chez les irresponsables [souvent, il est stocké très temporairement dans quelque partie chiffrée de la mémoire, juste le temps d'être transformé et utilisé : quand on a l'approbation, pffftt ! on l'efface]

Que peut avoir à faire le modèle du Mac dans cette affaire ? - il est absolument clair que le problème ne dépend pas du Système d'exploitation («El Capitan10.11» ou «Sierra 10.12»), parce que, lorsque l'écran de déverrouillage du Volume Logique verrouillé par le chiffrement est affiché à l'écran du Mac > l'OS recelé dans le Volume Logique verrouillé n'est absolument pas activé. Et pas non plus le Recovery OS de la partition de récupération Recovery HD : aucun OS n'est encore activé.

Juste un point : le changement d'OS amène parfois avec lui des modifications d'éléments connexes qui ne ressortissent pas à proprement parler du système ; donc le passage à Sierra peut amener des modifications des micro-systèmes, des logiciels d'encodage et tout ça.

[Petite incise : Apple n'a jamais pris le temps de gérer correctement le clavier de ses ordinateurs lorsqu'ils sont au plus bas du système (Darwin). À ce stade, que tout le monde peut voir avec le démarrage en mode mono-utilisateur ou l'ouverture d'une session en mode texte (login ">console"), tous les claviers sont considérés comme QWERTY-US. Que le problème survienne avec un clavier AZERTY ne m'étonne guère.]

 

[jacobinet]

Bonjour à tous,

J'ai hésité à créer un nouveau sujet, mais il y a quelques similitudes - je pense - avec celui-ci, donc je tente ma chance ici.

Ma config: MBP 9.1 15" mid 2012, 10.11.6

Je viens d'activer la protection par mot de passe interne via l'utilitaire disponible sur la Recovery HD. Mot de passe que j'ai choisi - inspiré que j'étais - avec pléthore de caractères spéciaux, en l’occurrence de ce type: @hypawié§&! (les "caractères spéciaux" sont identiques à ceux de mon mot de passe).

Après lecture de ce thread, j'ai déduis qu'au démarrage mon clavier est interprété comme étant un QWERTY-US alors que c'est un AZERTY-BE. Sur un QWERTY-US les touches @, é, §, & et ! ne sont pas présentes en façade, il faut donc que j'utilise les touches ⇧ et ⌥ pour tenter d'arriver à mes fins. J'ai donc logiquement fait:

@ = ⇧ + 2
h = h
y = y
p = p
a = q
w = z
i = i
é = (⌥ + e) + e
§ = ⌥ + 6
& = ⇧ + 7
! = ⇧ + 1

Constat: la touche ⌥ ne fonctionne pas...

Je crois que je suis dans une sacrée oo:

Help me please !

 

[bompi]

Je ne suis pas sûr de bien comprendre.
Tu as changé (ou simplement activé) le mot de passe interne (comme indiqué ici). Là, il ne s'agit pas de Filevault mais de bloquer un démarrage sur un autre disque (un disque externe par exemple).

Et quand tu redémarres, tu n'arrives pas à valider ton mot de passe ? Ou c'est simplement une crainte ?

 

[jacobinet]

Salut bompi,

J'ai activé le mot de passe interne (comme indiqué) et lorsque je veux redémarrer sur Recovery HD il me demande le mot de passe spécifique à la "protection interne". Impossible de taper celui-ci et donc impossible d'avoir accès au Recovery HD. Je n'ai pas encore essayé à partir de mon clone (externe), mais je suppose qu'il doit en être de même.

 

[bompi]

Aïe ! L'ennui est que ce mot de passe protège justement contre les démarrages sur un disque externe...
Il est dit dans le lien que je donne que, en cas d'oubli de ce mot de passe, tu peux aller dans un Apple Store [avec ta facture] pour qu'ils te donnent un coup de main.

 

[Membre supprimé 1060554]

Salut jacobinet

Effectivement : rien à voir avec «FileVault» et le dispositif CoreStorage. Le "mot-de-passe du Programme Interne" verrouille l'EFI de la Carte-Mère (le Firmware) et bloque un démarrage sur un autre Système que celui de la partition de l'OS du disque interne. Donc : pas de démarrage automatique sur clone, clé USB d'install, y compris le Recovery OS - sans montrer patte blanche = saisir le fameux mot-de-passe.

Je crois effectivement me souvenir, d'après des expérimentations qui datent un peu sur mon propre Mac, que le clavier logique de saisie du mot-de-passe de l'EFI est bien le QWERTY américain (en-US). Ce qui impliquerait, quand on utilise un AZERTY, d'éviter à l'avance les caractères à saisie critique > chose dont on ne se rend compte régulièrement qu'après-coup (comme toi) sans s'en être avisé au départ.

[Tu noteras que ce cas de figure (clavier logique obligatoirement QWERTY pour déverrouillage du mot-de-passe de l'EFI) diffère du cas de figure de l'écran de déverrouillage d'un Volume Logique CoreStorage lorsque «FileVault» est activé, car le clavier correspond alors normalement à la langue de l'utilisateur (et optionnellement on peut changer de clavier logique). Le problème abordé dans ce fil-ci concernait, ponctuellement, quelques caractères spéciaux non reconnus en clavier AZERTY > qui obligeaient à passer en clavier QWERTY américain.]

Je pense que tu peux automatiquement démarrer sur l'OS de la partition-Système de ton disque interne (= «El Capitan»), et que le problème ne se pose que si tu voulais démarrer sur un Système alternatif. Donc pour te consoler un peu : tu n'es pas bloqué pour l'usage courant de ton Mac.

Sinon --> à défaut de réussir de soi-même à désactiver ce mot-de-passe de l'EFI > même avis que bompi : il faut prendre rendez-vous en AppleStore, facture à l'appui (à cause du caractère "anti-vol" de l'activation du mot-de-passe de l'EFI > donc pouvoir prouver qu'on est le propriétaire légitime du Mac est requis) > et là un employé pourra faire sauter le verrouillage de l'EFI.

À moins que tu ne parviennes à taper les caractères accentués réfractaires : parce que c'est seulement après démarrage sur le Recovery OS > que tu peux "normalement" activer l'«Utilitaire de mot-de-passe du Programme Interne» et choisir alors la désactivation du verrouillage de l'EFI.

--------------------​

Il y a néanmoins un contournement que j'avais utilisé à l'époque de mes expérimentations hasardeuses => c'était d'avoir fait une copie à l'avance du «Firmware Password Utility.app» (Utilitaire de mot-de-passe du Programme Interne) dans les Applications de l'OS (après montage du volume de la Recovery HD et accès à l'original) > le logiciel était activable depuis l'environnement de l'OS démarré, sans nécessiter le recours à un démarrage sur le Recovery OS.

Comme j'ai gardé cette copie dans mon OS actuel «El Capitan 10.11.6» (le même que le tien) > je t'en ai chargé un exemplaire zippé dans le dossier public de ma «DropBox» dont voici de lien de téléchargement : ☞Firmware Password Utility.app.zip☜

=> télécharge-le > dézippe-le > déplace-le dans le sous-dossier /Applications/Utilities de ton OS démarré > lance le logiciel > s'il accepte de servir (j'ai vérifié : le logiciel se lance dans l'environnement de mon OS 10.11.6) > tu devrais pouvoir renseigner ton mot-de-passe de l'EFI à partir d'un clavier AZERTY afin de désactiver le verrouillage du Firmware.

[Si le greffon ne prenait pas > il y aurait encore le moyen, depuis ton OS «El Capitan» démarré > de monter le volume de la Recovery HD collatérale > et dans le dossier de démarrage : com.apple.recovery.boot > de monter le disque virtuel BaseSystm.dmg qui contient le Recovery OS dans un volume OS X Base System > de manière à accéder, sans avoir démarré en mode externe, au logiciel Firmware Password Utility.app» original > de manière à le lancer...]

Et comme c'est déjà la fin de l'après-midi (ce qui agit sur ma faculté d'ordonner les idées conformément à un enchaînement progressif en leur communiquant un caractère décousu) > voici que je m'avise qu'il faudrait rectifier les accédants au logiciel à user=root et group=wheel (ta manipulation graphique l'ayant approprié à user= toi et group = staff).

Donc lancer le «Terminal» (at: Applications > Utilitaires) > et à supposer que tu aies bien dépacé le logiciel au préalable dans le même sous-dossier cité > faire un copier-coller direct dans la fenêtre ouverte de la commande :

sudo chown -R 0:0 /Applications/Utilities/Firmware\ Password\ Utility.app

et ↩︎ (presse la toucne "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎

=> la commande appelle l'utilitaire chown (change_owners : changer les propriétaires) > avec l'option -R (Recursive : sur toute la profondeur du paquetage de l'application) > et les valeurs octales 0:0 (qui désignent l'user=root et le primary group=wheel) > sur l'objet constitué par le logiciel voulu en bout d'adresse /Applications/Utilities/Firmware\ Password\ Utility.app.

 

[bompi]

Donc : bien penser à récupérer cette application dès l'installation de l'ordinateur, histoire de ne pas avoir à faire toutes ces manipulations alors qu'on est stressé !

Pris d'une certaine curiosité et ayant pour une fois mon Mac sous la main j'ai recopié l'application sur mon système normal. Du coup elle appartient au couple utilisateur/groupe : mapomme/admin, soit 501/80 [sur Yosemite]. Cela suffit pour la lancer.

 

[jacobinet]

Ola macomaniac,

Un grand merci pour ton retour et tes solutions. Je teste ça d'ici fin de journée et viens vous dire ce qu'il en est.

 

[jacobinet]

Le greffon a pris ! J’ai désactivé le mot de passe interne.

Heureusement, car l’AppleStore le plus proche est à Bruxelles (le seul en Belgique à ce jour), c’est-à-dire à ± 230 kilomètres de mon domicile... ce qui ne le rend pas pour autant inaccessible, mais bon…

Concernant la saisie du mot-de-passe de l'EFI, j’ai des doutes sur le clavier QWERTY américain (en-US), la touche ⌥ (option) ne semble avoir aucun effet lors de son utilisation. Etrange.

Merci Macomaniac pour le partage de tes connaissances et pour ta copie “préventive” du «Firmware Password Utility.app». Merci également à bompi d’avoir pris du temps pour me lire et me répondre.

J’ai posté ici, car lorsque j’ai fait une recherche dans le forum à l'aide de "protection mot de passe interne", je suis arrivé sur ce thread et j'y ai (mal) vu quelques similitudes avec mon souci. Il est donc possible que cette petite mésaventure amène un quidam au problème similaire à trouver également sa solution ici.

 

[Membre supprimé 1060554]

jacobinet

Tu dois te sentir bigrement soulagé.

Si tu gardes le logiciel salvateur dans le sous-dossier des Utilitaires de ton OS > tu peux désormais sans crainte réactiver un mot-de-passe de l'EFI > tu arriveras toujours à te tirer d'affaire en dernière instance.

Mais comme le panneau de déverrouillage s'affiche au quotidien pour toute tentative de démarrage sur un Système alternatif de celui de l'OS > il vaut mieux choisir un mot-de-passe utilisant des caractères communs aux claviers AZERTY et QWERTY par souci de commodité personnelle. « toto » par exemple : court et passe-partout

 

[jacobinet]

Oui ! Ouf !

Tu rigoles mais pour tester à nouveau la protection de l'EFI, j'ai choisi "toto" comme mot-de-passe, ça marche super.

Encore merci macomaniac !

 

[PlannedObsolescence]

Bonjour !

Je viens de tomber sur le sujet et je tiens à remercier les intervenants, si je l'avais lu avant cela m'aurait évité de réinstaller 3 fois OS X...

J'ai aussi remarqué la chose suivante : au redémarrage suivant l'activation de FileVault, un indice supplémentaire est la transformation de l'icône de profil utilisateur en icône "visage" générique. A partir de ce moment là, le mot de passe n'est pas reconnu (mon mot de passe est en effet complexe).

J'ai désactivé FileVault ou plutôt pas activé lors de l'installation et bien sûr dans ce cas tout fonctionne.

Et je dispose d'un MacBook Pro Retina 15" de début 2015... Acheté sur le Refurb. Donc le problème est toujours d'actualité !

 

[Ikkon]

Bonjour à tous,

Je suis nouveau, et viens de m'inscrire exprès après avoir lu ce post, je sais, c'est tard après 6 ans Mac (ce jour où j'ai repensé ma façon de conserver un outil efficace, sans jamais rien perdre, et en toute sécurité)​

Merci pour l'ensemble des informations, ça m'évitera de perdre mon temps avec l'apple care, les Genius, niveau 1, 2, 3 et + si affinité sans obtenir de solution. J'ai exactement le même symptôme que Novezan et al.​

Rapidement, pour me présenter, il y a presque 6 ans, j'ai j'ai eu le malheur-bonheur d'acheter le fameux MBP15" mid 2011 et sa génialissime conception (le HDD à 1 an, la carte wifi à 2 ans, le GPU à 3 ans et 2 jours... l'apple store a fait un effort d'autant que c'est un défaut de série attesté a posteriori)

Après avoir très bien vécu depuis, avec un up SSD + 16Go de Ram, et des milliards de magouilles depuis que j'ai eu un apple advisor au téléphone et que j'ai lu les divers forums communautaires pour résoudre les problème par moi même j'ai beaucoup appris sur le fonctionnement de la bête. Notamment ce jour où j'ai dû faire la copie de volume sur mon nouveau disque sachant que j'avais activé le mot de passe EFI de la machine en plus du Filevault, avec un mot de passe de 15 à 17 caractères environ, contenant évidemment le fameux @.

Je sais par expérience, au moins chez windows que l'étoile ou le dollar, je ne sais plus, ne fonctionnait pas lors de l'association d'un compte hotmail sur le PC... Mais jusqu'à ce matin, tôt, je n'avais jamais été confronté à une telle hérésie chez Apple.

En fait, mon saint MBP15" 2011 "mort" hier 12h, ne supportant apparement plus la chaleur du midi. Heureusement, il avait alerté la veille, alors en pleine préparation d'un gros projet, avec des centaines de documents ouvert, powerpoint, image vectoriel, conso active des 9Go/16 bref il a craqué. Du coup j'ai du trouvé un Mac dans un dimanche. Bref, aillant prévu cet achat dans un futur proche, j'ai anticipé dans l'urgence pour un MBP 15" Retina + Touch Bar fin 2016.

Hier, soir, revenant avec ce nouveau bijou (espérons qu'il dure !), je mets tout en route, à jour, propre, nickel. Je redémarre la machine, pas de souci.
​

Bref cette nuit, les j'ai fait ma migration tranquille de ma sauvegarde Sierra à jour de la veille à partir de time machine. Et ce matin nickel, tout comme avant, la grande classe, la touch bar en plus et les haut parleur que je n'avais plus depuis 1 an. Bref je me remet au boulot, pour finir quelques trucs. Ensuite, je profite et j'explore l'ensemble des nouveautés, notamment dans les préf système, et je m'aperçoit que filevault est coupé, je redémarre il ne veut pas de mon super mot de passe crée il y a 6 ans et revisité régulièrement et tapé des dizaines de fois par jour. Alors je réessaie 6 fois, à cause de la marge d'erreur quand je suis extrêmement fatigué... mais rien, il n'en veut pas. Pris de panique, j'attends pas une seconde, je décroche le téléphone à l'heure d'ouverture en Irlande. J'obtiens immédiatement un "niveau 2" (c'est rare), le type très pro me rassure après vite pigé le machin, me fait d'abord reset le password qui par chance marche en recovery combinant le mot de passe admin + le mot de passe iCloud (ce qui me fait dire que ma sécurité est bonne, puisque l'advisor ne savait pas que ça allait marché, car j'avais désactivé le reset via le cloud mais que ça demande quand même les deux pour un reset normal, bref, j'ai bien ma vrai partition original, sans aucun doute sur le mot passe interne, je n'aurai. Ensuite pour me faire-faire des test l'advisor me conseil de créer une session et je test des mots de passe du plus simple au plus compliqué, et parce qu'il sait qu'il y a des souci Azerty/Qwerty sur les MBP récent au démarrage session, on a conclu que @ était le problème, et on a raccroché faute de temps.

Et ce soir, je teste plein de chose, et donc c'est bien FileVault le problème, et c'est bien vrai qu'en passant en clavier US international on a effectivement la possibilité de se casser là tête. Mais avouons-le c'est pas pratique. Et puis heureusement, j'ai trouvé ce fil. J'ai exactement le même problème que tous, pourtant mon mot de passe session fonctionne impec, sans filevault ou en US, mais pas en Azerty. Les lectures m'ont fait comprendre que ça vient ni d'Apple en soit, ni de l'Hardware. Je me dis que c'est un problème utilisateur dépendant.​

➡️C'est pourquoi ma question est simple, pensez-vous que si j'active le mot de passe EFI à l'ouverture de la machine, j'accentue le souci ou je le résous définitivement ?
➡️En attendant une mise à jour. Sinon je pense sincèrement qu'en le remettant à neuf le souci ne se représentera pas ?
➡️Sinon dois-je véritablement me plonger dans les explications de ce post ?

Salut jacobinet

Effectivement : rien à voir avec «FileVault» et le dispositif CoreStorage. Le "mot-de-passe du Programme Interne" verrouille l'EFI de la Carte-Mère (le Firmware) et bloque un démarrage sur un autre Système que celui de la partition de l'OS du disque interne. Donc : pas de démarrage automatique sur clone, clé USB d'install, y compris le Recovery OS - sans montrer patte blanche = saisir le fameux mot-de-passe.

Je crois effectivement me souvenir, d'après des expérimentations qui datent un peu sur mon propre Mac, que le clavier logique de saisie du mot-de-passe de l'EFI est bien le QWERTY américain (en-US). Ce qui impliquerait, quand on utilise un AZERTY, d'éviter à l'avance les caractères à saisie critique > chose dont on ne se rend compte régulièrement qu'après-coup (comme toi) sans s'en être avisé au départ.

[Tu noteras que ce cas de figure (clavier logique obligatoirement QWERTY pour déverrouillage du mot-de-passe de l'EFI) diffère du cas de figure de l'écran de déverrouillage d'un Volume Logique CoreStorage lorsque «FileVault» est activé, car le clavier correspond alors normalement à la langue de l'utilisateur (et optionnellement on peut changer de clavier logique). Le problème abordé dans ce fil-ci concernait, ponctuellement, quelques caractères spéciaux non reconnus en clavier AZERTY > qui obligeaient à passer en clavier QWERTY américain.]

Je pense que tu peux automatiquement démarrer sur l'OS de la partition-Système de ton disque interne (= «El Capitan»), et que le problème ne se pose que si tu voulais démarrer sur un Système alternatif. Donc pour te consoler un peu : tu n'es pas bloqué pour l'usage courant de ton Mac.

Sinon --> à défaut de réussir de soi-même à désactiver ce mot-de-passe de l'EFI > même avis que bompi : il faut prendre rendez-vous en AppleStore, facture à l'appui (à cause du caractère "anti-vol" de l'activation du mot-de-passe de l'EFI > donc pouvoir prouver qu'on est le propriétaire légitime du Mac est requis) > et là un employé pourra faire sauter le verrouillage de l'EFI.

À moins que tu ne parviennes à taper les caractères accentués réfractaires : parce que c'est seulement après démarrage sur le Recovery OS > que tu peux "normalement" activer l'«Utilitaire de mot-de-passe du Programme Interne» et choisir alors la désactivation du verrouillage de l'EFI.

--------------------​

Il y a néanmoins un contournement que j'avais utilisé à l'époque de mes expérimentations hasardeuses => c'était d'avoir fait une copie à l'avance du «Firmware Password Utility.app» (Utilitaire de mot-de-passe du Programme Interne) dans les Applications de l'OS (après montage du volume de la Recovery HD et accès à l'original) > le logiciel était activable depuis l'environnement de l'OS démarré, sans nécessiter le recours à un démarrage sur le Recovery OS.

Comme j'ai gardé cette copie dans mon OS actuel «El Capitan 10.11.6» (le même que le tien) > je t'en ai chargé un exemplaire zippé dans le dossier public de ma «DropBox» dont voici de lien de téléchargement : ☞Firmware Password Utility.app.zip☜

=> télécharge-le > dézippe-le > déplace-le dans le sous-dossier /Applications/Utilities de ton OS démarré > lance le logiciel > s'il accepte de servir (j'ai vérifié : le logiciel se lance dans l'environnement de mon OS 10.11.6) > tu devrais pouvoir renseigner ton mot-de-passe de l'EFI à partir d'un clavier AZERTY afin de désactiver le verrouillage du Firmware.

[Si le greffon ne prenait pas > il y aurait encore le moyen, depuis ton OS «El Capitan» démarré > de monter le volume de la Recovery HD collatérale > et dans le dossier de démarrage : com.apple.recovery.boot > de monter le disque virtuel BaseSystm.dmg qui contient le Recovery OS dans un volume OS X Base System > de manière à accéder, sans avoir démarré en mode externe, au logiciel Firmware Password Utility.app» original > de manière à le lancer...]

Et comme c'est déjà la fin de l'après-midi (ce qui agit sur ma faculté d'ordonner les idées conformément à un enchaînement progressif en leur communiquant un caractère décousu) > voici que je m'avise qu'il faudrait rectifier les accédants au logiciel à user=root et group=wheel (ta manipulation graphique l'ayant approprié à user= toi et group = staff).

Donc lancer le «Terminal» (at: Applications > Utilitaires) > et à supposer que tu aies bien dépacé le logiciel au préalable dans le même sous-dossier cité > faire un copier-coller direct dans la fenêtre ouverte de la commande :

sudo chown -R 0:0 /Applications/Utilities/Firmware\ Password\ Utility.app

et ↩︎ (presse la toucne "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎

=> la commande appelle l'utilitaire chown (change_owners : changer les propriétaires) > avec l'option -R (Recursive : sur toute la profondeur du paquetage de l'application) > et les valeurs octales 0:0 (qui désignent l'user=root et le primary group=wheel) > sur l'objet constitué par le logiciel voulu en bout d'adresse /Applications/Utilities/Firmware\ Password\ Utility.app.

 

[Membre supprimé 1060554]

Salut Ikkon

Le créateur de ce fil, Novezan, a mis à jour une impasse très spécifique qui n'a reçu a ce jour aucune solution pratique. Sur certains types de Mac récents > en cas d'activation de «FileVault» et de choix d'un mot-de-passe d'ouverture de session d'utilisateur incluant des caractères spéciaux > la saisie d'un tel mot-de-passe en clavier AZERTY n'est pas validée à l'écran inaugural de déverrouillage du Volume Logique CoreStorage Chiffré. Il faut basculer obligatoirement en clavier Américain QWERTY.

----------

pensez-vous que si j'active le mot de passe EFI à l'ouverture de la machine, j'accentue le souci ou je le résous définitivement ?

Un mot-de-passe de verrouillage de l'EFI ne concerne que des démarrages sur un autre volume que le volume-Système du disque (un clone par exemple) ou selon un autre mode que le mode automatique (en Single User par exemple).

Il n'a donc aucun impact sur le démarrage en mode automatique en cas d'activation de «FileVault», où il s'agit de saisir en tout début de démarrage un mot-de-passe d'ouverture de session qui aura valeur de déverrouillage du Volume Logique CoreStorage verrouillé par le chiffrement.

Sur un Mac où la saisie d'un mot-de-passe à caractères spéciaux n'est pas validée en clavier AZERTY pour déverrouiller un Volume Logique verrouillé par «FileVault» > la situation ne sera donc strictement pas changée : il faudra toujours basculer en clavier Américain QWERTY. Mais comme la saisie d'un mot-de-passe de l'EFI n'est elle-même validée par défaut qu'en clavier Américain QWERTY --> un verrouillage de l'EFI aura valeur d'universalisation à tous les démarrages possibles de l'obligation de saisie en clavier Américain QWERTY > là où sinon cette obligation n'intervient qu'en cas de démarrage en mode automatique sur le Volume verrouillé de l'OS.

En résumé : tu vas te compliquer universellement la vie > là où tu ne te l'étais compliquée avec ton choix d'activer «FileVault» que de manière spécifique.

----------

En attendant une mise à jour. Sinon je pense sincèrement qu'en le remettant à neuf le souci ne se représentera pas ?

Aucune ré-initialisation du disque suivie d'une ré-installation ne résoudra le problème > lequel ressurgira inévitablement en cas de ré-activation de «FileVault».

Mes spéculations abondantes dans ce fil ont (semble-t-il) avéré que, sur certains modèles de Mac récents exclusivement, la non-reconnaissance d'un mot-de-passe à caractères spéciaux en clavier AZERTY en cas d'activation de «FileVault» découle de l'« essence logique » spécifique de l'EFI (le Programme Interne) de ces Mac. L'EFI étant le logiciel supportant exclusivement la procédure de démarrage d'un Volume Logique Chiffré de type CoreStorage - alors qu'en cas de non-chiffrement, la saisie d'un mot-de-passe d'ouverture de session comportant des caractères spéciaux s'opère au LoginWindow, càd. un écran supporté par le logiciel-Système de l'OS entièrement chargé à ce moment-là.

Il s'agit d'une simple nécessité déterministe : les mêmes causes produisent invariablement les mêmes effets. À invariance de l'« essence logique »de l'EFI à travers n ré-installations > invariance de l'effet de non-reconnaissance de caractères spéciaux en clavier AZERTY à l'écran de déverrouillage d'un Volume Logique Chiffré.

Si tu désactives «FileVault» --> tu résous de ce fait le problème > puisque la saisie d'un mot-de-passe à caractères spéciaux n'intervient plus à un écran inaugural gouverné par l'EFI. Si tu changes ton mot-de-passe en en excluant les caractères spéciaux --> tu résous également ton problème en cas de maintien de l'activation de «FileVault».

Mais en ce qui concerne ton évocation d'une « mise-à-jour » => je dis : tous les espoirs sont permis. Car cette « mise-à-jour » est la prochaine mise-à-niveau logicielle à l'OS «High Sierra». En effet -->

• cette mise-à-niveau logicielle implique une mise-à-jour logicielle de l'EFI de tous les Macs. On pourrait imaginer que cette seule MÀJ-de-l'EFI règle la question à OS inchangé pour ton Mac. Pour cela > il faudrait que tu installes expérimentalement la High Sierra Developer Beta 10.13 dans un volume autre que celui de ton OS actuel > avec choix de l'option "Upgrade to APFS" --> ce qui impliquera nécessairement la mise-à-jour de l'EFI de ton Mac. Après effacement du volume APFS supportant High Sierra > peut-être la MÀJ-de-l'EFI intervenue pour ton Mac permettra-t-elle la reconnaissance d'un mot-de-passe à caractères spéciaux en clavier AZERTY en cas d'activation de «FileVault».

• cette mise-à-niveau logicielle (si tu attends la version publique de High Sierra pour éviter des dysfonctionnements trop drastiques - attention ! l'activation de «FileVault» est supportée à partir de la beta 2 avec des ratatouillages indescriptibles), en faisant passer au système de stockage APFS, implique l'abandon du système de stockage CoreStorage. Le chiffrement «FileVault-2» qui reposait entièrement sur la logistique CoreStorage > devient le chiffrement «FileVault-3» qui repose sur la logistique APFS. On peut alors présumer que l'EFI mise-à-jour permettra la validation de mots-de-passe à caractères spéciaux à l'écran initial de déverrouillage d'un Volume APFS Chiffré différemment d'un Volume Logique CoreStorage Chiffré.

=> bref : il suffit d'attendre en espérant.

----------

➡️Sinon dois-je véritablement me plonger dans les explications de ce post ?

Non. Il s'agissait de spéculations sur le mécanisme logique du démarrage impliqué par la technologie CoreStorage (la création logique la plus absconse de l'ingéniérie Apple). Aussi verbalement abstruses que leur objet. Concluant à l'incompatibilité ponctuelle de certains types d'EFI avec les contraintes de démarrage d'un CoreStorage Chiffré. Cette « théorisation négative » ne t'apporterait aucune solution pratique.