Posté par Nap .
En réponse à la dépêche KDE 3.4 RC1.
Évalué à 2.
bon je dois vraiment être bête car je ne comprends pas le coup du wallet sans mot de passe, ou alors tu as voulu dire "avec mot de passe"
je résume une partie de la discussion :
pour moi c'est le seul moyen de chiffrer des données de l'utilisateurs
Ben non, ce n'est pas le seul moyen.
Et c'est quoi les autres ?
un wallet sans mot de passe
comment le wallet sans mot de passe chiffre-t-il les comptes de l'utilisateur ?
bon, sinon, c'est quoi la mémoire PAM ? ça m'intéresse. beaucoup ce truc
c'est un espace mémoire réservé à l'utilisateur ?
En tout cas, ce qui me gène dans tout ça, c'est de se baser uniquement sur les protections offertes par l'OS (à part le coup du chiffrement sans mot de passe du wallet où j'ai rien compris)
Pour stocker des informations sensibles comme des mots de passe, il me semble impératif de chiffrer le tout avec un mot de passe maitre. Si on ne peut pas utiliser le mot de passe de la session, on est obligé d'en avoir deux ou de taper le même deux fois, ce que l'utilisateur aura du mal à comprendre, et moi aussi finalement car la seule explication qu'il peut y avoir est une explication technique (limitations des interactions entre le gestionnaire de session et la session elle même) et non pas théorique.
En effet on pourrait parfaitement imaginer que le gesionnaire de session ouvre lui même la session du wallet avec le mot de passe de l'utilisateur. Or il ne peut techniquement qu'ouvrir la session.
Il faudrait un mécanisme indiquant à la session de lancer le wallet avec le mot de passe.
Enfin pour préciser les choses je n'ai bien sûr jamais voulu que toute application puisse accéder au mot de passe de la session :)
je voyais les choses dans l'autre sens : la session, possédant le mot de passe au moment de l'ouverture, ouvre le wallet avec celui-ci.
Autre idée : le gestionnaire de session peut-il lancer un programme dans la session une fois celle-ci ouverte ?
[^] # Re: KDE 3.4
Posté par Nap . En réponse à la dépêche KDE 3.4 RC1. Évalué à 2.
je résume une partie de la discussion :
comment le wallet sans mot de passe chiffre-t-il les comptes de l'utilisateur ?
bon, sinon, c'est quoi la mémoire PAM ? ça m'intéresse. beaucoup ce truc
c'est un espace mémoire réservé à l'utilisateur ?
En tout cas, ce qui me gène dans tout ça, c'est de se baser uniquement sur les protections offertes par l'OS (à part le coup du chiffrement sans mot de passe du wallet où j'ai rien compris)
Pour stocker des informations sensibles comme des mots de passe, il me semble impératif de chiffrer le tout avec un mot de passe maitre. Si on ne peut pas utiliser le mot de passe de la session, on est obligé d'en avoir deux ou de taper le même deux fois, ce que l'utilisateur aura du mal à comprendre, et moi aussi finalement car la seule explication qu'il peut y avoir est une explication technique (limitations des interactions entre le gestionnaire de session et la session elle même) et non pas théorique.
En effet on pourrait parfaitement imaginer que le gesionnaire de session ouvre lui même la session du wallet avec le mot de passe de l'utilisateur. Or il ne peut techniquement qu'ouvrir la session.
Il faudrait un mécanisme indiquant à la session de lancer le wallet avec le mot de passe.
Enfin pour préciser les choses je n'ai bien sûr jamais voulu que toute application puisse accéder au mot de passe de la session :)
je voyais les choses dans l'autre sens : la session, possédant le mot de passe au moment de l'ouverture, ouvre le wallet avec celui-ci.
Autre idée : le gestionnaire de session peut-il lancer un programme dans la session une fois celle-ci ouverte ?