Différences entre versions de « Security »

De Mi caja de notas

m
 
(15 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
{{stub}}
+
== e-mail ==
 +
 
 +
vérification e-mail : https://sec.hpi.de/ilc/dataprivacy
 +
 
 +
 
 +
== indieweb ==
 +
{{stub-fr}}
 +
 
 +
[[File:Jamstack — wikiducamp 2016-12-30 11-52-46.png|400px]]
  
 +
(source [[JAMstack#slides]])
  
 
Une page voulue pour nourrir [[iwc:security-fr]].
 
Une page voulue pour nourrir [[iwc:security-fr]].
Ligne 8 : Ligne 17 :
 
{{stub}}
 
{{stub}}
  
La '''<dfn>securité</dfn>''' dans le contexte de l'indieweb peut se référer à des préoccupations de sécurité concernant les [[personal-domain-fr|domaine personnel]] s, l'[[hébergement web]], la configuration [[https]], les données privées, l'identité etc. Presque tout sur Internet, y compris le web, et donc l'indieweb, a des problèmes de sécurité.
+
La '''<dfn>securité</dfn>''' dans le contexte de l'indieweb peut faire référence à des préoccupations de sécurité concernant les [[domaine personnel|domaines personnels]], l'[[hébergement web]], la configuration [[https]], les données privées, l'identité etc. Presque tout sur Internet, y compris le web, et donc l'indieweb, a des problèmes de sécurité.
  
  
 
== Pourquoi ==
 
== Pourquoi ==
 +
 
Vous devriez faire en sorte que votre site personnel soit plus sûr afin que vous et d'autres puissent lui faire encore plus confiance.
 
Vous devriez faire en sorte que votre site personnel soit plus sûr afin que vous et d'autres puissent lui faire encore plus confiance.
  
 
== Comment faire ==
 
== Comment faire ==
 +
 
Voir :
 
Voir :
* [[iwc:CSP]]
+
* [[CSP]]
* [[iwc:HTTPS]]
+
* [[HTTPS]]
* [[iwc:sandbox]]
+
* [[sandbox]]
  
 
== Visibilité ==
 
== Visibilité ==
 
__TOC__
 
__TOC__
Services that require logins or act as [[authorization-endpoint|authorization servers]] should provide a way for users to see an audit trail of events relating to their account. For example:
+
 
 +
Les services qui exigent des identifiants logins ou agissent comme des [[authorization-endpoint|serveurs d'autorisation]] devraient fournir un moyen aux utilisateurs de voir une piste de vérification des événements liés à leur compte. Par exemple :
  
 
=== Historique de Sécurité GitHub ===
 
=== Historique de Sécurité GitHub ===
[[GitHub]] provides a [https://github.com/settings/security page listing accesses to your account] with details such as from what device, OS, location, date of access:
+
[[GitHub]] fournit une [https://github.com/settings/security page listant les accès  à votre compte] avec des détails comme la description du terminal, l'OS, le lieu et la date de l'accès.
  
[[File:github-security-history-example.png|400px]]
+
[[Fichier:Github-security-history-example-fr.png|400px]]
  
 
=== Activité Récente de Google ===
 
=== Activité Récente de Google ===
[[Google]] provides a [https://www.google.com/settings/security security recent activity log] with date, browser, OS used to access your account and other information:
 
  
[[File:google-security-history-example.png|400px]]
+
[[Google]] fournit un [https://www.google.com/settings/security journal de sécurité de l'activité récente] avec les dates, navigateurs et OS utilisés pour accéder à votre compte et d'autres informations :
 +
 
 +
 
 +
[[File:800px-google-security-history-example.png|400px]]
  
== Breaches ==
+
== Violations ==
Security breaches as reported by sites
+
Violations de sécurité rapportées par les sites
  
 
=== 2014 ===
 
=== 2014 ===
Ligne 44 : Ligne 58 :
 
== Problèmes reproductibles ==
 
== Problèmes reproductibles ==
  
=== https http botches ===
+
=== sabotages https http ===
Today, when standards like [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS]
+
Aujourd'hui, quand des standards comme [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] essayent de
try to mitigate [[https]] to http degradation [https://en.wikipedia.org/w/index.php?title=Moxie_Marlinspike&redirect=no#Notable_research attacks], there's no reason to allow http at all. All http should redirect to https.
+
réduire [[https]] à une dégradation de http [https://en.wikipedia.org/w/index.php?title=Moxie_Marlinspike&redirect=no#Notable_research attacks], il n'y a pas aucune raison d'autoriser http. Tout http devrait rediriger vers https.
Examples of "willful degradation" in indie web related software and services:
+
 
* Webmentions to [[Known]] only work if you mention the http URL. This may encourage using unsafe links to [[Known]] (that shouldn't exist in the first place).
+
Exemples de «dégradation délibérée» dans les logiciels et services liés à l'intdieweb :
* [[webmention.io]] regards http and https as different URLs. Perhaps this is not a bug, because in a perfect world there ''wouldn't'' be any https.
+
* Les webmentions vers [[Known]] ne fonctionnent que si vous mentionnez l'URL http. Ceci peut encourager des liens peu sûrs vers [[Known]] (qui ne devraient pas exister en première place.)
 +
* [[webmention.io]] considère http et https comme des URLs différentes. Peut-être que ce n'est pas un bug, parce que dans un monde parfait il ne "devrait pas" exister quelque https.
  
 
== Hébergement Web==
 
== Hébergement Web==
Should you write about your [[web hosting]] setup?
+
Devriez-vous écrire votre réglage d'[[web hosting-fr|hébergement web]] ?
  
In some regards yes, to help out other members of the community.
+
A certains égards oui, afin d'aider d'autres membres de la communauté.
  
However from a security perspective, disclosing what web host you use, software, VPS, or how you implement your server configuration are potential security issues because every piece of information you give a potential attacker about your setup helps narrow the space of weaknesses to explore.
+
Néanmoins d'un point de vue sécurité, dissimuler l'hébergeur web que vous utilisez, ou la façon d'implémenter votre configuration de serveur sont des problèmes potentiels de sécurité car chaque pièce d'information que vous donnez à un attaquant potentiel sur votre réglage diminue l'espace des faiblesses à explorer.
  
So, how do you share information without endangering yourself in that regard?
+
Par conséquent, comment partager l'information sans vous mettre vous-même en danger ?
  
You decide you're not a worthy target, or you decide you'd rather share publicly in the hopes that friends will warn you about any flaws before an attacker exploits them.
+
Vous décidez que vous n'êtes pas une cible valable, ou vous décidez que vous devriez plutôt partager publiquement avec l'espoir que des amis vous préviendront de toutes vos faiblesses avant qu'un attaquant ne les exploite.
  
== Dealing with unknown problems ==
+
== Traiter des problèmes inconnus ==
Per https://en.wikipedia.org/wiki/Secure_by_design :
+
Selon https://en.wikipedia.org/wiki/Secure_by_design :
* Peer review existing protocols and [https://dubiousdod.org/indie/2014/11/i-always-think-of-this-classic-http-homakov-blogspot implementations].
+
* Révision par les pairs des protocoles existants et [https://dubiousdod.org/indie/2014/11/i-always-think-of-this-classic-http-homakov-blogspot impleméntations].
* Look for docs, advice, potential peer-reviewers at communities like [https://mailman.stanford.edu/mailman/listinfo/liberationtech MIT's Liberationtech mailing list] (''any other ideas?'').
+
* Cherchez les docs, conseils et révisions par les pairs potentiels dans des communautés comme la  [https://mailman.stanford.edu/mailman/listinfo/liberationtech mailing list Liberationtech du MIT] (''d'autres idées ?'').
* Think in advance about security implications of features like private messages.
+
* Réfléchissez à l'avance sur les implications de sécurité de fonctionnalités comme des messages privés.
* Always prefer existing and ''popular'' (i.e. constantly peer reviewed) technology to reinventing crypto.
+
* Préférez toujours une technologie existante et "populaire" (à savoir constamment sous une révision par les pairs) plutôt que de réinventer la crypto.
* Eventually - prepare guidelines for site owners and developers on the Wiki (similar to [https://ssd.eff.org/en/module/keeping-your-data-safe Eff's SSD]).
+
* Pour finir - préparez des lignes directrices pour les propriétaires de sites et les développeurs sur le Wiki (similaire au  [https://ssd.eff.org/en/module/keeping-your-data-safe SSD de Eff]).
  
 
== Voir aussi ==
 
== Voir aussi ==
* [[iwc:CSP]]
+
* [[CSP]]
* [[iwc:https]]
+
* [[https]]
*[[iwc:WordPress_Security|Sécurité WordPress]]
+
*[[WordPress_Security|Sécurité WordPress]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
<!--
 +
== autres points à classer pour [[La Maison Ducamp]] ==
 +
 
 +
=== {{xtof}} et mémoire (vieillesse) ===
 +
* gros maux de crâne sur la [[sécurité]]. oubli de mes [[mot de passe|mots de passe]] (bug connu) > étudier 1password sur mobile et coût d'une impression personnalisée avec numéros d'urgence sur mon porte-cartes bancaires. Design R&D "secours" ou urgence. En attendant, les ébauches de solutions s'ouvrent
 +
** (carte [[Banques|bancaire]] 3ème essai à tenter. repartir en pensée visuelle
 +
** code de la porte (inscrit sur le wiki dans l'invite à [[thierry]])
 +
-->

Version actuelle datée du 21 février 2019 à 04:39

e-mail

vérification e-mail : https://sec.hpi.de/ilc/dataprivacy


indieweb


Jamstack — wikiducamp 2016-12-30 11-52-46.png

(source JAMstack#slides)

Une page voulue pour nourrir iwc:security-fr.


🔒 Cet article est une ébauche. Vous pouvez m'aider à l'améliorer et le compléter. Merci.

La securité dans le contexte de l'indieweb peut faire référence à des préoccupations de sécurité concernant les domaines personnels, l'hébergement web, la configuration https, les données privées, l'identité etc. Presque tout sur Internet, y compris le web, et donc l'indieweb, a des problèmes de sécurité.


Pourquoi

Vous devriez faire en sorte que votre site personnel soit plus sûr afin que vous et d'autres puissent lui faire encore plus confiance.

Comment faire

Voir :

Visibilité

Les services qui exigent des identifiants logins ou agissent comme des serveurs d'autorisation devraient fournir un moyen aux utilisateurs de voir une piste de vérification des événements liés à leur compte. Par exemple :

Historique de Sécurité GitHub

GitHub fournit une page listant les accès à votre compte avec des détails comme la description du terminal, l'OS, le lieu et la date de l'accès.

Github-security-history-example-fr.png

Activité Récente de Google

Google fournit un journal de sécurité de l'activité récente avec les dates, navigateurs et OS utilisés pour accéder à votre compte et d'autres informations :


800px-google-security-history-example.png

Violations

Violations de sécurité rapportées par les sites

2014

Problèmes reproductibles

sabotages https http

Aujourd'hui, quand des standards comme HSTS essayent de réduire https à une dégradation de http attacks, il n'y a pas aucune raison d'autoriser http. Tout http devrait rediriger vers https.

Exemples de «dégradation délibérée» dans les logiciels et services liés à l'intdieweb :

  • Les webmentions vers Known ne fonctionnent que si vous mentionnez l'URL http. Ceci peut encourager des liens peu sûrs vers Known (qui ne devraient pas exister en première place.)
  • webmention.io considère http et https comme des URLs différentes. Peut-être que ce n'est pas un bug, parce que dans un monde parfait il ne "devrait pas" exister quelque https.

Hébergement Web

Devriez-vous écrire votre réglage d'hébergement web ?

A certains égards oui, afin d'aider d'autres membres de la communauté.

Néanmoins d'un point de vue sécurité, dissimuler l'hébergeur web que vous utilisez, ou la façon d'implémenter votre configuration de serveur sont des problèmes potentiels de sécurité car chaque pièce d'information que vous donnez à un attaquant potentiel sur votre réglage diminue l'espace des faiblesses à explorer.

Par conséquent, comment partager l'information sans vous mettre vous-même en danger ?

Vous décidez que vous n'êtes pas une cible valable, ou vous décidez que vous devriez plutôt partager publiquement avec l'espoir que des amis vous préviendront de toutes vos faiblesses avant qu'un attaquant ne les exploite.

Traiter des problèmes inconnus

Selon https://en.wikipedia.org/wiki/Secure_by_design :

  • Révision par les pairs des protocoles existants et impleméntations.
  • Cherchez les docs, conseils et révisions par les pairs potentiels dans des communautés comme la mailing list Liberationtech du MIT (d'autres idées ?).
  • Réfléchissez à l'avance sur les implications de sécurité de fonctionnalités comme des messages privés.
  • Préférez toujours une technologie existante et "populaire" (à savoir constamment sous une révision par les pairs) plutôt que de réinventer la crypto.
  • Pour finir - préparez des lignes directrices pour les propriétaires de sites et les développeurs sur le Wiki (similaire au SSD de Eff).

Voir aussi