boarf a écrit 36 commentaires

Je suppose qu'on peut considérer comme une protection le fait de changer l'identifiant de la session à chaque appel au serveur. Et de manière générale, comme le but de l'attaque pésentée dans ce journal est de voler l'identifiant de session, toute protection contre ce type d'attaque (que SSL soit utilisé ou non) est bonne à prendre.

Par exemple, quand j'ai besoin de sessions pour un script php, j'utilise cette fonction à chaque appel :

session_regenerate_id(true);

Oui, c'était l'objet de mon edit.

Je ne suis pas persuadé, soit le script vient du site attaqué (ou est inclus depuis ses pages) auquel cas il a accès au cookie (il me semble) et l'attaque ne sert à rien, soit il vient d'un domaine tiers auquel cas non seulement il ne peut pas lire le cookie mais ne peut pas générer de requête non plus vers le domaine à attaquer (les navigateurs ont des protections contre ça, il me semble).

Bon, après, c'est une réaction à chaud, je n'ai pas creusé le sujet.

edit : au temps pour moi, il peut toujours générer & manipuler des iframes ou autres balises important du contenu.

Ça me fait penser aux réalisations d'Always Innovating : https://www.alwaysinnovating.com/products/smartbook.htm

Même chose, concept du téléphone central, qu'on plug dans un écran pour faire une tablette, qu'on plug sur un bloc clavier pour faire un notebook.

(commentaire bookmark)

"la cretion"

La création j'imagine, bien que l'accrétion du monde Linux soit aussi une réalité.

Sinon, tu as aussi le standard TOTP (les token RSA ne sont pas standards, si j'ai bien suivi), dont l'implémentation made in google : google authenticator. Ton smartphone fait office de token et génère des OTP basés sur le temps. Un secret est partagé entre le serveur d'authentification et l'application, l'application peut contenir plusieurs secrets (comme une collection de jetons). L'implémentation est libre, un module PAM est aussi disponible. Il est assez facile de le réimplémenter, il y a par exemple un module wordpress pour utiliser ce système.
Exemple de mise en œuvre : http://blog.essembeh.org/post/2011/Google-auth-OpenSSH

Accessoirement, peut-être faut-il rappeler que le coût des fraudes à la carte bancaire est intégralement supporté par les banques et leurs assurances (il reste tout de même la perte de temps et l'inquiétude pour le détenteur de la carte), notamment qu'une transaction peut être contestée sauf dans le cas où le code PIN a été utilisé.

Si je me souviens bien, c'est un choix de la norme que de laisser les informations déjà présentes sur le papier en clair.
Seules les nouvelles données (empreintes, iris, etc selon les pays) peuvent être chiffrées et soumises à accès authentifiées, etc. Cette partie-là est laissée à la discrétion des pays émetteurs. Généralement, pour des raisons de mauvaise organisation, c'est mal fait. Par exemple, pour authentifier les passeports, il faut faire la vérification en récupérant le certificat du gouvernement. Comme les aéroports ont tendance à être internationaux, ça signifie que les machines de contrôle accèdent au dépôt commun des gouvernements, auquel peu d'entre eux participent, donc dans la pratique, le contrôle ne se fait pas (ou peu). C'est comme ça qu'on avait vu un passeport valide d'Elvis Presley à Amsterdam, je crois.

Ben dans le cas d'une simple carte, effectivement, un étui blindé (par exemple avec de la feuille d'aluminium) suffit. La technique est d'ailleurs utilisée sur les passeports biométriques américains, si je ne m'abuse : il y a un blindage dans la couverture pour ne pouvoir lire la puce que si le passeport est ouvert.

Dans le cas où le smartphone intègre les capacités NFC de lui-même, on peut supposer qu'il laisse la possibilité à l'utilisateur de désactiver cette interface (comme il laisse cette possibilité pour le wifi, la 3G, etc). C'est le cas sous Android.

Si c'est la carte SIM qui intègre le NFC, effectivement, c'est foutu.

Comme d'habitude, le problème vient plutôt du mauvais usage qui en est fait que de la puce en elle-même. Généralement, celles-ci disposent de toutes les protections hardware nécessaires (chiffrement, vrai générateur de nombres aléatoires, etc). La faute incombe surtout aux développeurs des applications, je pense. Après tout, c'est Visa/Mastercard/machin qui n'exige pas de canal de communication chiffré, d'authentification mutuelle de la carte et du terminal (les deux parties supportant parfaitement les standards en la matière : certificats, PKI, RSA, AES, etc).