À noter que, dans LUKS, par exemple, la clé symétrique de chiffrement est stockée dans une entête de la partition, ou de ce qu'il y a à chiffrer - elle est ensuite protégée par de la passphrase : je dis "de la", et non pas "une", car on peut tout à fait en mettre plusieurs, pour donner un peu de granularité aux accès.
Ainsi, sur ce qui doit être récupérable, les admins mettent leur "passphrase", et les utilisateurs en utilisent une autre - au final, c'est toujours la même clé symétrique qui protège les données (même si l'utilisateur n'y est jamais directement confronté), mais même si ses utilisateurs habituels ont perdue ou emmenée avec eux la "passphrase", pas grave : il reste celle(s) des admins, qui en profiteront pour désactiver celle qui s'est envolée dans la nature.
Après, le problème, c'est la taille de ce passe... mettons que le "standard" (de fait) de chiffrement symétrique est l'AES 256bits. Pour ne pas réduire le pool de possibilités que le bruteforçage devra affronter, ça nous fait donc une "passphrase" d'au moins 32 caractères ASCII (32*8bits). Dur de s'en souvenir... heureusement, on peut par exemple mettre ça sur un token crypto, en l'y stockant en tant qu'objet privé, uniquement accessible via un code PIN.
Il faut alors non seulement connaître le code PIN (la carte est censée se bloquer, et attendre une réinitialisation, après un certain nombre d'essais râtés), et posséder la carte (sans le PIN, le passe ne peut être extrait par des méthodes logicielles... reste la cryptoanalyse de la puce)... et là, ça devient humainement plus utilisable, tout en restant "sûr", et en permettant une granularité des accès aux données chiffrées.
Bon, sinon, on peut aussi stocker la clé symétrique directement dans le token crypto - ça évite de la laisser, même chiffrée, sur l'objet à protéger... par contre, ça complique les choses pour les accès multiples - ça dépend de ce qu'on veut faire, mais ça revient de toute façon peu ou prou au même, si le passe utilisé est long.
En outre, avec des tokens cryptos, on peut proprement faire de la PKI (Infrastructure à Clés Publiques), où les certificats couplés aux clés privées stockées dans les tokens vont rendre le tout très sûr : plus besoin de mot de passe (hors le PIN, qui est un peu plus qu'un passe, avec la répudiation après quelques essais manqués), hormis dans quelques cas, comme passer en superutilisateur (une fois authentifié avec le certificat, via SSH, par exemple), auquel cas, à la limite, on peut sortir un petit Kerberos juste pour ça (mais de toute façon, c'est loin d'être nécessaire pour tous les utilisateurs)... ah oui - et il y a Jabber, qui est chiant, aussi, avec ça (il semble qu'ejabberd2 va avoir le support de l'authentification TLS mutuelle... reste que je cherche encore un client libre qui permet ça).
M'enfin, si on a "des besoins en matière de confidentialité", et qu'on veut se donner "les moyens de les satisfaire", m'est avis que le plus simple, en matière de politique de mot de passe, c'est encore de les dégager le plus possible, pour les remplacer par de la PKI via des tokens crypto (en matière de confidentialité, c'est quand même bien sympa, ces petits artefacts, même quand on ne fait pas de PKI avec - pour le chiffrement, par exemple)... 5-6 chiffres à mémoriser, ça va : c'est quand même à la portée d'à peu près n'importe qui... Avec le PIN dans un agent, il n'y a même pas à le taper souvent.
Après, le soucis, c'est le support libre des tokens... ça marche avec OpenSSL, SSH, iceweasel... mais par exemple, sous KDE, c'est la loose - genre, avec Konqueror, nada... c'est moche, parce qu'Apache+TLS mutuel+Perl+LDAP, c'est pourtant de la tuerie (confidentialité et authentifications via TLS/X509, autorisations via X509 /ACL de l'annuaire - pas un mot de passe ou que ce soit - fonctionne en surcouche de tout ce qu'on peut/veut mettre sur le serveur web, ce qui permet de pousser les choses plus loin notamment dans l'appli web, avec par exemple du SASL proxy ou que sais-je encore) - et utiliser ça avec des clés en fichiers, c'est gâcher :(
[^] # Re: C'est déjà un peu le cas
Posté par Aefron . En réponse au journal Les plans de la prison de Nancy étaient sur les 4 ordinateurs volés.. Évalué à 6.
Ainsi, sur ce qui doit être récupérable, les admins mettent leur "passphrase", et les utilisateurs en utilisent une autre - au final, c'est toujours la même clé symétrique qui protège les données (même si l'utilisateur n'y est jamais directement confronté), mais même si ses utilisateurs habituels ont perdue ou emmenée avec eux la "passphrase", pas grave : il reste celle(s) des admins, qui en profiteront pour désactiver celle qui s'est envolée dans la nature.
Après, le problème, c'est la taille de ce passe... mettons que le "standard" (de fait) de chiffrement symétrique est l'AES 256bits. Pour ne pas réduire le pool de possibilités que le bruteforçage devra affronter, ça nous fait donc une "passphrase" d'au moins 32 caractères ASCII (32*8bits). Dur de s'en souvenir... heureusement, on peut par exemple mettre ça sur un token crypto, en l'y stockant en tant qu'objet privé, uniquement accessible via un code PIN.
Il faut alors non seulement connaître le code PIN (la carte est censée se bloquer, et attendre une réinitialisation, après un certain nombre d'essais râtés), et posséder la carte (sans le PIN, le passe ne peut être extrait par des méthodes logicielles... reste la cryptoanalyse de la puce)... et là, ça devient humainement plus utilisable, tout en restant "sûr", et en permettant une granularité des accès aux données chiffrées.
Bon, sinon, on peut aussi stocker la clé symétrique directement dans le token crypto - ça évite de la laisser, même chiffrée, sur l'objet à protéger... par contre, ça complique les choses pour les accès multiples - ça dépend de ce qu'on veut faire, mais ça revient de toute façon peu ou prou au même, si le passe utilisé est long.
En outre, avec des tokens cryptos, on peut proprement faire de la PKI (Infrastructure à Clés Publiques), où les certificats couplés aux clés privées stockées dans les tokens vont rendre le tout très sûr : plus besoin de mot de passe (hors le PIN, qui est un peu plus qu'un passe, avec la répudiation après quelques essais manqués), hormis dans quelques cas, comme passer en superutilisateur (une fois authentifié avec le certificat, via SSH, par exemple), auquel cas, à la limite, on peut sortir un petit Kerberos juste pour ça (mais de toute façon, c'est loin d'être nécessaire pour tous les utilisateurs)... ah oui - et il y a Jabber, qui est chiant, aussi, avec ça (il semble qu'ejabberd2 va avoir le support de l'authentification TLS mutuelle... reste que je cherche encore un client libre qui permet ça).
M'enfin, si on a "des besoins en matière de confidentialité", et qu'on veut se donner "les moyens de les satisfaire", m'est avis que le plus simple, en matière de politique de mot de passe, c'est encore de les dégager le plus possible, pour les remplacer par de la PKI via des tokens crypto (en matière de confidentialité, c'est quand même bien sympa, ces petits artefacts, même quand on ne fait pas de PKI avec - pour le chiffrement, par exemple)... 5-6 chiffres à mémoriser, ça va : c'est quand même à la portée d'à peu près n'importe qui... Avec le PIN dans un agent, il n'y a même pas à le taper souvent.
Après, le soucis, c'est le support libre des tokens... ça marche avec OpenSSL, SSH, iceweasel... mais par exemple, sous KDE, c'est la loose - genre, avec Konqueror, nada... c'est moche, parce qu'Apache+TLS mutuel+Perl+LDAP, c'est pourtant de la tuerie (confidentialité et authentifications via TLS/X509, autorisations via X509 /ACL de l'annuaire - pas un mot de passe ou que ce soit - fonctionne en surcouche de tout ce qu'on peut/veut mettre sur le serveur web, ce qui permet de pousser les choses plus loin notamment dans l'appli web, avec par exemple du SASL proxy ou que sais-je encore) - et utiliser ça avec des clés en fichiers, c'est gâcher :(