Tiens, F-Secure distribue une appli gratuite pour gérer ses mots de passe (pour Windows, MacOSX, iOS et Android).  Je n'aime pas confier mes mots de passe à une appli, mais j'ai une bonne opinion en F-Secure.
(via http://deleurme.net/liens/index.php5?DCNI0w)

+1
Le chiffrement côté serveur n'assure aucune confidentialité puisque par principe ILS ONT LES CLÉS pour chiffrer/déchiffrer.
C'est comme si un fabricant vous installait une super porte antivol que VOUS SEUL pouvez ouvrir... et qu'ils gardent une copie des clés, leur permettant de rentrer chez vous quand ils veulent (eux ou les forces de l'ordre, puisqu'ils coopèrent).

Et oui !... ils n'ont toujours pas corrigé depuis le mois de Janvier: http://sebsauvage.net/links/?afB1AA
(Comment voulez-vous passer pour des "pros" après des gaffes comme ça ?)

Tiens curieux, sur mon compte GitHub aussi il y a eu plusieurs tentatives de connexion il y a deux jours.  Je pense que GitHub a subit des tentatives de piratage de comptes.
EDIT: Ah oui: https://github.com/blog/1698-weak-passwords-brute-forced

Voilà qui est intéressant: Le firmware de la puce qui gère USB/GSM/3G/WiFi/Blutooth/DSP (et autres) est bien séparé de l'OS (Android, iOS)... et il est assez complexe pour être considéré comme un système d'exploitation à part entière. Ce firmware est appelé "baseband software".
Un système d'exploitation totalement propriétaire et fermé, non documenté et visiblement conçu dans l'esprit des années 90, c'est à dire sans sécurisation.  Les failles doivent être très nombreuses.
Donc on peut se pignoler des heures sur la sécurité respective d'iOS ou Android: Au final, tous les smartphones peuvent être p0wnés jusqu'au trognon à cause de ces firmwares.  Et installer une ROM opensource genre Cyanogen ne vous protègera pas.
EDIT: La présentation en vidéo: http://www.youtube.com/watch?v=fQqv0v14KKY

Un outils en ligne pour analyser les exécutables Windows ou Android (.apk): Uploadez votre fichier et il vous fait une analyse.
Voir aussi : http://sanddroid.xjtu.edu.cn/
Note: Ces deux services sont très lents, soyez patient.

Faille OpenSSH, pensez à patcher.

Je l'avais évoqué en 2010 (http://sebsauvage.net/rhaa/?2010/02/24/11/21/13-les-bugs-informatiques-peuvent-tuer), et là nous avons le premier cas jugé: Toyota a été jugé responsable de la mort d'une conductrice à cause de bugs dans le code de son modèle Camry.
N'oublions pas qu'une Toyota Prius, c'est 100 millions de lignes de code...  Peut-on raisonnablement penser qu'il n'y a pas de bugs dans une telle quantité de code ?

Bwwwaaa... j'avais fait la connerie de me désabonner du flux RSS de Gof, parce que j'étais noyé dans les news, mais il y a trop de choses intéressantes à voir dans ses brèves.  Je remet le flux.

EDIT: https://twitter.com/_Gof_/status/395121941637382144   Oui je lis tout ce qui mentionne @sebsauvage ou #sebsauvage  :-)

Rappel: Les principales sources d'infection lors de la consultation de pages web sont les plugins Flash et Java.

Voici comment configurer Firefox pour qu'il n'active ces plugins que sur demande explicite de votre part:
 - dans la barre d'adresse, tapez about:config
 - dans la configuration, passez le paramètre "plugins.click_to_play" à "true".

Ainsi, quand vous arriverez sur une page contenant un plugin (Flash par exemple), il faudra cliquer sur la zone pour charger le contenu du plugin (par exemple la vidéo Flash).

Avantages:
 - par défaut les pubs Flash et contenus malveillants ne s'activeront pas.
 - les plugins n'étant pas activés, les pages se chargeront plus vite (surtout quand il y a plusieurs Flash dans la page, ou que vous chargez plusieurs onglets d'un coup)
 - cela évite d'en prendre plein les oreilles quand des sites font de l'autoplay.
 - vous aurez quand même la possibilité de demander à Firefox de démarrer automatiquement Flash sur certains sites.

Quand vous cliquerez sur un de ces plugins, Firefox vous proposera d'activer les plugin juste pour cette fois ("Activer maintenant") ou toujours sur ce site ("Toujours activer", par exemple pour YouTube).
Vous pouvez changer ce réglage site par site en faisant clic-droit sur le fond de page > Informations sur la page > Permissions.

En évitant d'activer pour rien les plugins, on réduit grandement les risques d'infection.

EDIT: Zut. Depuis Firefox 24, l'option plugins.click_to_play ne sert plus à rien. Il faut aller dans le menu Outils > Modules complémentaires > Plugins > et choisir "Demander pour activer" pour chaque plugin.

Quelques lectures "sécurité web" que je me met sous le coude pour les lire plus tard.

Putain de putain, Google, merde quoi !  Depuis Android 2.3, Google a *baissé* la sécurité de TLS: Au lieu d'utiliser RSA-AES256-SHA, ils sont passés à RC4-MD5. Un truc que plus personne ne devrait utiliser.
Google serait-il noyauté par la NSA ? L'explication semble plus simple: Google a juste collé aux réglages par défaut... de Java 6 (qui d'ailleurs n'est plus supporté par Oracle).
C'est vraiment nul :-(

Oh putain... une backdoor dans certains routeurs D-Link. Et elle est *intentionnelle*. On comprend mieux l'intérêt des firmwares opensource.  :-(
EDIT: Détails technique et reverse-engineer de la backdoor: http://www.devttys0.com/2013/10/reverse-engineering-a-d-link-backdoor/
EDIT: D-Link va corriger: http://www.silicon.fr/d-link-sapprete-fermer-backdoor-ses-routeurs-90090.html et http://threatpost.com/d-link-planning-to-patch-router-backdoor-bug/102581

Oh je la sens vraiment pas bien, cette méthode d'authentification. Vraiment pas.

Oh tiens... Adobe s'est fait piquer des codes source (ColdFusion, Publisher, Acrobat Reader...).  On va sûrement voir arriver des malwares ciblant de nouvelles failles de sécurité.

Puisque Pierre M. me questionne, voici mon avis sur cet article:
Forcer des algos de chiffrements forts (AES 256 bits au lieu de RC4) est une bonne chose...  mais en l'occurrence totalement inutile pour se protéger des attaques MITM.

Pourquoi ? Parce que la NSA peut sans problème faire pression sur l'une des nombreuses autorités de certifications présente par défaut dans les navigateurs afin de générer des certificats SSL valide et intercepter sans lever d'alerte. Gardons à l'esprit le cas de Microsoft/Tunisie. Et là ce n'était même pas la NSA. (http://sebsauvage.net/rhaa/index.php?2011/09/05/09/28/51-anti-microsoftisme-du-jour-et-autres-joyeusetes).

Les autorités de certifications ne sont pas infaillibles. Les procédures de sécurité peuvent être abusées. Elles peuvent se faire pirater (c'est déjà arrivé). Elles peuvent subir des pression. Elles peuvent éventuellement décider de collaborer.

Alors votre super chiffrement en servira à rien si de toute manière votre navigateur accepte n'importe quel certificat signé, même si ce n'est pas le vrai certificat du site que vous visitez (Je rappelle que des vendeurs de firewalls filtrants se targuent, dans leur plaquettes commerciales, de pouvoir faire de la substitution de certificats SSL à la volée.)
Voir: http://sebsauvage.net/rhaa/index.php?2010/03/26/12/03/17-les-certificats-ssl-ne-suffisent-plus

Pour prendre une image: Vous pouvez utiliser les serrures les plus sophistiquées au monde (AES): Si le fabricant de la porte prête une copie des clés à quelqu'un d'autre (certificats SSL signés), votre super serrure sécurisée ne sert à rien.

Quel espèce de crétin développe une application de mail qui exécute automatiquement tout javascript inclus dans les mails reçus ?  SÉRIEUSEMENT ???  ><
EDIT: Voir aussi http://nakedsecurity.sophos.com/2013/09/26/mailbox-app-on-ipads-and-iphones-runs-javascript-from-emails-vulnerability-or-feature/

Juste un rappel: Java 6 n'est plus supporté par Oracle depuis février 2013. Ce qui veut dire plus de mises à jour de sécurité.
Même si vous avez installé Java 7, Java 6 n'est pas automatiquement supprimé. Pensez bien à le déinstaller.

A garder sous la main pour désinfecter un PC. (via http://www.korezian.net/liens/?zbyEWw).
Notez que cela reste particulièrement utile car certains virus ont la capacité d'être totalement invisibles des antivirus après infection (Certains sont capable de se charger avant le système d'exploitation).
En fait, à partir du moment où une machine est infectée, vous ne pouvez jamais avoir la garantie qu'elle est saine, même après passage d'un antivirus. Les admins préfèreront généralement une réinstallation complète du système à partir de supports fiables.

Bwwwaaaaa.... C'est pire que je pensais.
Ceci est la liste d'entreprises utilisant l'algo foireux recommandé par la NSA (cf. http://sebsauvage.net/links/?1YZ3Nw).
On y retrouve Cisco, Apple, Motorola, Toshiba, McAfee, Juniper, HP-UX, IBM, Oracle, Symantec, SAP, Intel, Microsoft, CheckPoint, Thales, RedHat, R.I.M., ZTE, Avaya, WindRiver... et OpenSSL.
Il y en a dans tous les domaines: des firewalls aux VPN en passant par les systèmes médicaux ou la VOIP.
Ça fait froid dans le dos, et il est difficile d'évaluer la quantité de produits réellement touchés: Ils ne listent ici que les libs propriétaires incluant la techno de RSA en question, non les produits les utilisant, ni si cet algo est actif dans la config par défaut.

EDIT: Article complémentaire: http://sebsauvage.net/links/?ZUgdvA

BOUH QUE C'EST LAID.

Résumons: Régulièrement, le NIST (un organisme de standardisation américain) fait voter des standards de crypto. C'est d'eux que proviennent des standards comme l'AES ou SHA-2 (aka SHA256).
En 2007, différents algos générateurs de nombres pseudo-aléatoires avaient été proposés comme standard, dont l'un (Dual EC DRBG) recommandé par la NSA. A l'époque, Bruce Schneier (une sommité en crypto) avait analysé l'algo et trouvé des faiblesses (un biais de l'algo) qui - je cite - "ne peut être décrit que comme une backdoor". Mais il n'avait rien pour le prouver.

Nous sommes en 2013, et nous y somme: Cet algo semble en effet posséder des failles volontaires permettant à la NSA de déchiffrer les protocoles utilisant cet algo. En fait, comme beaucoup d'algo, il contient des constantes. Schneier soupçonne ces constantes d'avoir été calculée à dessein, et de faire partie d'une formule (un peu comme les paires clés privées/clés publiques).
La personne possédant le nombre secret correspondant pourrait déchiffrer un trafic TLS/SSL utilisant cet algo en observant seulement 32 octets échangés.  Et il n'y a pas que TLS qui utilise Dual EC DRBG. Il y a tout un tas de produits, à commencer par ceux de la célèbre société RSA qui - du coup - recommande à ses clients d'éviter cet algo comme la peste.
Le NIST lui-même déconseille désormais Dual EC DRBG et ré-ouvrira des discussions sur les générateurs de nombres pseudo-aléatoires.

La question posée par l'auteur de l'article est pertinente: Pourquoi la société américaine RSA a choisi cet algo comme algo par défaut dans la majorité de ses produits, alors qu'il savaient dès le départ que c'était le bébé de la NSA ?

EDIT: Une liste d'entreprises utilisant cet algo: http://sebsauvage.net/links/?FZvDyA
EDIT: Article complémentaire: http://sebsauvage.net/links/?ZUgdvA

Oho... donc un gouvernement aurait déjà approché Linus Torvalds pour lui demander d'insérer une backdoor dans Linux. Ou alors c'est une blague de Linus.

TL;DR Des conseils pour générer ses clés OpenPGP.

Ouch. Java 6 n'est plus supporté par Oracle, donc plus de correction des failles de sécurité. Or Java 6 est installé chez la moitié des internautes. Cela veut dire des failles de sécurité et des infections qui vont perdurer... encore très longtemps.  :-(
Oracle, tu fous quoi ???

« Ces collaborations lui auraient permis d'insérer « secrètement » des vulnérabilités dans les systèmes de chiffrement des données mis au point par les firmes. »
Du lard ou du cochon ? Si c'est vrai, ça va être un foutu pavé dans la marre des éditeurs de logiciels de sécurité et chiffrement. Effet de bord possible: Ça pourrait donner un bon coup de pouce aux logiciels libres.
EDIT: Chez Numérama: http://www.numerama.com/magazine/26916-comment-la-nsa-peut-contrecarrer-le-chiffrement-des-communications.html