Différences entre versions de « Security »

De Mi caja de notas

(Page créée avec « {{stub}} Une page voulue pour nourrir iwc:security-fr. == indieweb == {{iwc}} »)
 
 
(17 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 +
== 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]].
 +
 +
 +
<span style="float:right;height:128px;font-size:128px;margin:72px 0 -64px">🔒</span>
 
{{stub}}
 
{{stub}}
 +
 +
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 ==
 +
 +
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 :
 +
* [[CSP]]
 +
* [[HTTPS]]
 +
* [[sandbox]]
 +
 +
== Visibilité ==
 +
__TOC__
 +
 +
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 ===
 +
[[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.
 +
 +
[[Fichier:Github-security-history-example-fr.png|400px]]
 +
 +
=== Activité Récente de Google ===
 +
 +
[[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]]
 +
 +
== Violations ==
 +
Violations de sécurité rapportées par les sites
 +
 +
=== 2014 ===
 +
* 2014-04 [[Heartbleed]]
 +
* 2014-02-15 [[Kickstarter]] https://www.kickstarter.com/blog/important-kickstarter-security-notice
 +
* ...
 +
 +
== Problèmes reproductibles ==
 +
 +
=== sabotages https http ===
 +
Aujourd'hui, quand des standards comme [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] essayent de
 +
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.
 +
 +
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'[[web hosting-fr|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 [https://dubiousdod.org/indie/2014/11/i-always-think-of-this-classic-http-homakov-blogspot impleméntations].
 +
* 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 ?'').
 +
* 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  [https://ssd.eff.org/en/module/keeping-your-data-safe SSD de Eff]).
 +
 +
== Voir aussi ==
 +
* [[CSP]]
 +
* [[https]]
 +
*[[WordPress_Security|Sécurité WordPress]]
 +
 +
 +
  
  
−
Une page voulue pour nourrir [[iwc:security-fr]].
 
  
−
== indieweb ==
+
<!--
 +
== autres points à classer pour [[La Maison Ducamp]] ==
  
−
{{iwc}}
+
=== {{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

Cet article est une débauche. Vous pouvez m’aider à l'améliorer.


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




Récupérée de « https://ducamp.me/index.php?title=Security&oldid=13319 »