C’est meme impossible sans contournement.
Mais je trouve le compte en ligne interessant pour un utilisateur lambda, car en cas de perte de son appareil, il peut tout récupérer grace à son compte en ligne. C’est vraiment top pour cela.
Je ne me lancerai pas sur le débat de la vie privée stockée du coup en ligne chez MS. Car c’est un débat sans fin qui ne débouche en général sur rien.
Et un navigateur, avec son gestionnaire de mots de passe le plus souvent pas lui même protégé par un mot de passe. Donc accès à tous les comptes en lignes non dotés de double authentification, et même en partie à certains de ceux qui en sont dotés (grâce aux cookies du navigateur), dont la boîte mail… De quoi faire vraiment beaucoup de choses, comme tenter d’arnaquer des proches, ou encore faire chanter le propriétaire en le menaçant de diffuser certaines choses…
Très peu de personnes vont avoir le réflexe de changer leurs mots de passe suite à la perte ou au vol de leur ordinateur…
1 « J'aime »
Et bien on fera sans Bitlocker. Pas fan pour mon matériel perso. plus de contraintes que d’avantages.
Soit je trouve comment le désactiver à l’installation ou après l’installation, soit je continuerais à mettre la 23H2 puis upgrade vers 24h2
J’ai eu une dizaine de clients a qui c’est arrivé et c’était bien la clé bitlocker qu’il fallait.
Le disque était juste illisible, ça ne demandait pas de mot de passe.
Alors c’était probablement un bug car comme je l’ai dit, c’était spécifique à un modèle de chez Asus mais ça n’empêche que sans bitlocker ça ne serait pas arrivé.
Si c’est un PC portable, ça se comprend. Mais si c’est une tour, c’est un poil plus compliqué.
Maintenant, chiffre ton disque et attends que tu tombes ne panne et que tu sois obligé de récupérer tes données…
Tu vas voir, c’est très rigolo.
C’est exactement ce que je dis depuis le début en fait…
Si tu avais lu mes messages, tu aurais vu que j’ai déja fait cela.
Désolé, j’ai zappé ! Je rentre du « boulot » : je suis bénévole. 
Et j’y retourne demain !
1 « J'aime »
Pas de soucis
Moi, j’ai codé un crypteur/décrypteur à ma sauce et je crypte mes fichiers avec. Et je dépose ces fichiers sur le net à plusieurs endroits.
Alors c’est bien, mais assure toi que ton truc à ta sauce il soit fiable. Parce que des mecs qui ont fait des trucs à leur sauce qui se sont fait ruiner ensuite il y en a plus d’un.
Seul un audit de ton code pourra t’assurer que ton truc à ta sauce est solide.
il est inviolable (sauf par brute force attack mais il faudrait plusieurs centaines, voir quelques milliers d’années pour y arriver).
Je le garantie à 99,999%
Le 0.001% qui reste est dû à ma folie que je ne détecte pas encore… 
À moins que tu n’utilises exclusivement des algorithmes de chiffrement connus, il faudrait que tu sois un expert en cryptographie pour pouvoir être confiant à ce point… Ce que tu n’es clairement pas, car sinon tu ne dirais pas « crypter/décrypter », et surtout, un expert en crypto ne dira jamais que son algorithme est sûr à 99.999, même s’il en est convaincu 
Après, c’est sûr que si c’est pour un usage strictement personnel, pas pour des échanges avec d’autres gens, tu crains pas trop avec un truc maison, ne serait ce que parce que celui qui tombe sur tes fichiers n’aura sans doute absolument aucune idée de ce avec quoi ils ont été chiffrés.
1 « J'aime »
Ho, mais, je suis prêt à donner le crypteur avec. Il est inviolable…
Le quoi??
1 « J'aime »
C’est ce qui doit fabriquer des cryptes.
Ca a été testé / certifié par qui / quel organisme pour en arriver à ce postulat ?
1 « J'aime »
Et pourtant, tu dis toi même avoir aussi codé un décrypteur. Or un décrypteur, c’est bien quelque chose qui viole un chiffrement (on dit déchiffrer quand on a la clé, décrypter quand on ne l’a pas…)
1 « J'aime »
Je parle d’une cryptographie symétrique (un MDP pour crypter le fichier, et ce même MDP pour décrypter ce fichier crypté).
Par moi même et par personne d’autre pour le moment 
Et ? Ça ne le rend pas inviolable pour autant…
Le seul chiffrement dont on peut avoir la certitude qu’il est inviolable, c’est un chiffrement symétrique ET dont la clé est au moins aussi longue que les données à chiffrer.
Si la clé est plus courte que le message, et en particulier si elle est vraiment beaucoup plus courte (ce qui est pratiquement toujours le cas, puisqu’on n’utilise rarement des clés de plus de quelques dizaines d’octets) :
- si c’est un chiffrement basique (type XOR ou autre truc du genre), on est vulnérable à des attaques statistiques/heuristiques. En particulier, si on ne prend pas la peine d’obfusquer le type des fichiers qu’on a chiffré (et également le nom d’ailleurs, car un nom de fichier peut donner des informations sur son type… « facture » a plus de chances d’être un PDF qu’un MP3…), le début de la clé peut être cassé très très vite… Par exemple sur un JPEG, on va casser instantanément les 48 premiers bits de la clé + jusqu’à 16 autres bits de la clé selon la taille du fichier (si n est la taille de la clé en octets, on casse les premiers 48 bits si la taille du fichier est comprise entre xn et xn + 6, les premiers 56 bits si la taille du fichier est xn+7, les premiers 64 bits si elle est xn+8 et les 48 premiers + 16 autres (et dont on connait la position) dans les autres cas).
- si c’est un chiffrement avec des fonctions mathématiques complexes conçues pour se protéger contre les attaques statistiques de base, on est exposé à un risque de faiblesse dans ces fonctions mathématiques, et il est assez prétentieux d’imaginer avoir écrit une telle fonction infaillible…
Dans ce second cas, il est beaucoup plus raisonnable et prudent d’utiliser des fonctions déjà réputées pour leur robustesse, par exemple AES, dont les plus performantes attaques connues à ce jour ne font gagner qu’un facteur ~10 par rapport à un brute force, plutôt que d’écrire soi même une fonction en s’imaginant être capable de faire mieux que des experts du domaine…