Andrea Luzzardi a écrit 12 commentaires

  • [^] # Re: c'est bien beau mais ...

    Posté par  . En réponse à la dépêche pam_usb 0.3.1 dans les bacs. Évalué à 1.

    Je crois que tu n'as pas saisi le but de pam_usb.

    Le but de ce projet n'est pas de sécuriser une machine:
    dès qu'on y a accès physique, on peut y accèder comme on veut.

    Puisque quoi qu'il arrive l'accès physique sera pas sécurisé, pourquoi perdre du temps à taper le password ?

    C'est la qu'intervient pam_usb. Il n'est en aucun cas plus sécurisé que le password, vu l'accès physique, mais te permet de te logguer plus facilement et plus rapidement sur ta propre machine.
    Cependant, la sécurité a été le but principale pendant le dévéloppement: l'authentification se fait par des clé DSA, qui peuvent être cryptées, une ACL de serial numbers est disponible et plusieurs moyens d'identifications sont disponibles.

    En dehors de l'utilisation doméstique, son utilisation est intéressante aussi au sein d'une entreprise, d'un laboratoire, d'un internet café, etc. car les gens ne s'amusent pas à demonter la machine dans des endroits pareils pour remettre à zero le password du bios :)

    De plus, il inclut des utilitaires sympas tel que usbhotplug, qui permet de bloquer l'écran quand tu enlèves la clé usb, et de le débloquer dès que tu remet la bonne clé usb.
  • [^] # Re: Sécurité ?

    Posté par  . En réponse à la dépêche pam_usb 0.3.1 dans les bacs. Évalué à 3.

    Effectivement, l'auteur (moi) a déjà été confronté à ce problème :)

    Comme l'a dit Imbolcus, il y a plusieurs solutions pour protéger la
    copie et le vol de la clé USB:

    - mode additional: non seulement il faut la clé, mais aussi le
    password du compte demandé (implementé dès la première release, 0.1-beta1)

    - cryptage de la clé privée: la clé sera cryptée en 3des/twofish/autre grâce à l'utilitaire usbadm fourni avec, pour pouvoir se logguer il faudra entrer ce password. (implementé dans la 0.2-rc1)

    - access list de serial numbers: seules les clés dont le serial number est dans la liste pourront se logguer (implementé dans la 0.1-beta1).

    Ces trois solutions peuvent être couplées entre elles et d'autres sécuritées seront implementées dans le futur.

    Pour ce qui concerne les empreintes digitales, il y a des clés USB biometric. Je n'ai pas encore eu la possibilité d'en acheter une pour essayer (vu les prix), mais tôt ou tard je me pencherai sur cette solution (j'éspère que les donations au projet pourront m'aider à m'en procurer une)

    J'ai aussi vu des commentaires qui parlaient de PINs.
    Certaines clés USB supportent le montage avec password. Ces clés coûtent à peu près le même prix que les clés normales.
    J'en acheterai une dans les semaines à venir pour poivoir rajouter le support PIN.
  • [^] # Re: pam_usb 0.2.1

    Posté par  . En réponse au journal pam_usb 0.2.1. Évalué à 3.

    En effet c'est mon but final pouvoir se logguer sans login en insérant la clé USB, et"bloquer" la machine (screensaver + vlock, etc) en l'enlévant.

    Est ce que ca impliquerait de faire des modifications en dehors de pam_usb (genre gdm, xdm, gnome-session, xscreensaver et co) ?


    La pluspart des modifications seront en dehors de pam_usb (HAL, D-BUS, hotplug plus toutes les applications concérnées telles que gdm/xdm/etc).

    Sinon c'est un chouette projet, bravo :-)

    Merci:)
  • [^] # Re: apres le login ...

    Posté par  . En réponse à la dépêche Authentification par clé USB : pam_usb. Évalué à 1.

    En fait je suis en train de travailler sur quelque chose de similaire:

    - tu retires la clé USB, un screensaver (genre xscreensaver) se met en place, de même pour xlock, et la machine reste vérouillée
    - tu re-pluggues la clé USB, et le screensaver/xlock se dévérouillent
  • [^] # Re: pam_usb v0.2_rc2

    Posté par  . En réponse au journal pam_usb v0.2_rc2. Évalué à 1.

    C'est normal, c'est pour ça qu'en tant que root il vaudrait mieux crypter la clé privée en utilisant usbadm (usbadm help cipher).

    En tout cas, je suis déjà en train de m'occuper de ça en cherchant une méthode pour m'assurer que l'utilisateur soit bien local. J'ai déjà essayé en utilisant pam_get_item() sur PAM_RHOST, mais sans succès. Il y a de fortes chances que cette feature soit sur la nouvelle version de pam_usb.
  • # Re: pam_usb v0.2_rc2

    Posté par  . En réponse au journal pam_usb v0.2_rc2. Évalué à 1.

  • [^] # Re: Et dans vos clefs USB, vous mettez quoi ?

    Posté par  . En réponse au journal Et dans vos clefs USB, vous mettez quoi ?. Évalué à 1.

    Un souhait ? Ca ne marche pas ?
    Si si ça marche :)

    Par contre, faut pas se logger n'importe ou ? Quelqu'un pourrait mettre sur sa machine un programme qui en plus d'authentifier recopierait la cle privee sur le disque ...

    Pour répondre à ta question, la clé privée peut-être cryptée en blowfish/3des, ce qui demande un passphrase au login. Tu peux utiliser ce genre de machanismes temporairement, pendant que tu est à l'extérieur, et rebasculer sur une méthode sans passphrase à la maison.

    De plus, tu peux changer le couple de clé autant de fois que tu le souhaite (tu peux le rajouter à crontab si tu veux).

    Une meilleure solution serait une cle USB qui nous renvoi crypte ou decrypte le message qu'on lui a donne, en faisant les calculs elle meme. Ca existe deja ?

    Ouais, ça existe, c'est pour Windows, c'est cher, et ça ne stoque aucune donnée...
  • # Re: Authentification par clé usb / Reconnaissance vocale

    Posté par  . En réponse au journal Authentification par clé usb / Reconnaissance vocale. Évalué à 2.

    Pour la question 1/, j'avais posté un journal intitulé Authentification par clé usb (http://linuxfr.org/~scox/4427.html(...)) il y a un mois à l'occasion de la sortie de pam_usb 0.1.

    Entretemps j'ai publié la version 0.2-rc1 il y a quelques semaines mais je n'ai pas posté de journal (si ça vous dis, allez-y). Pour plus d'info tu peux aller voir http://freshmeat.net/projects/pam_usb/(...)
  • # Re: Plusieurs suggestions pour l'amelioration de DLFP

    Posté par  . En réponse au journal Plusieurs suggestions pour l'amelioration de DLFP. Évalué à 2.

    Poster un journal est une chance, et non une liberté.

    Je ne vois pas ça de cette façon.
    Un journal est quelque chose de personnel, qui sert à garder une trace de tout et n'importe quoi, un peu comme les journaux d'advogato.

    Ainsi, cela pourrait limiter le nombre de journaux postés.

    Je ne crois pas qu'il y ait un excès de journaux.
    En admettant que ce soit le cas, il serait mieux de publier les journaux sur la page personelle de l'utilisateur (linuxfr.org/~user) dès la création, et d'étaler sur plusieurs jours la publication sur la page principale à travers une "post queue" pour ceux qui sont rendu publics.

    Par contre il serait bien que les modérateurs puissent juger de l'exactitude et de la valeur ludique d'un journal.

    Comme je l'ai déjà dit avant, un journal est un recueil de réfléxions personnelles qui ne peut être jugé.

    Enfin, il serait temps aussi d'enlever 1 XP par message sur la tribune.

    C'est une tribune libre.

    Par contre je trouve intéressante la première proposition pour le système de "pré-vote".
  • [^] # Re: Authentification par clé USB

    Posté par  . En réponse au journal Authentification par clé USB. Évalué à 1.

    Tu peux toujours rebooter et passer des options à lilo.

    Si tu peux mettre un ordinateur dans un coffre blindé, alors vaut mieux y acceder depuis une deuxième machine par ssh.
  • [^] # Re: Authentification par clé USB

    Posté par  . En réponse au journal Authentification par clé USB. Évalué à 2.

    C'est faisable, mais comme j'ai spécifié dans le commentaire précédent, du moment que l'on a accès physique, c'est un peu inutile
  • [^] # Re: Authentification par clé USB

    Posté par  . En réponse au journal Authentification par clé USB. Évalué à 4.

    Théoriquement il ne faudrait pas laisser traîner sa clé usb, tout comme les clés de chez soit pour éviter qu'elles soient copiés :)

    pam_usb supporte une liste de sérial numbers authorisés, ces S/N sont directement ceux inscrits dans l'hardware, parsés dans /proc.

    Cela dit, je vois mal quelqun te piquer ta clé, copier le contenu, faire un fake de ton S/N, alors qu'il a accès physique à la machine (et que donc il pourrait tout simplement rebooter et passer init=/bin/bash au kernel).

    Une nouvelle version est en cours de développment qui quant à elle supporte l'authorisation par couple de clé DSA/RSA/DH. La clé privée pourra être cryptée en blowfish ou 3des.