Différences entre versions de « Security »
De Mi caja de notas
m (first draft translation to be continued) |
|||
| (16 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 | + | 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 : | ||
| − | * [[ | + | * [[CSP]] |
| − | * [[ | + | * [[HTTPS]] |
| − | * [[ | + | * [[sandbox]] |
== Visibilité == | == Visibilité == | ||
__TOC__ | __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 === | === Historique de Sécurité GitHub === | ||
| − | [[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 === | === Activité Récente de Google === | ||
| − | |||
| − | [[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]] | ||
| − | == | + | == Violations == |
| − | + | Violations de sécurité rapportées par les sites | |
=== 2014 === | === 2014 === | ||
| Ligne 44 : | Ligne 58 : | ||
== Problèmes reproductibles == | == Problèmes reproductibles == | ||
| − | === https http | + | === 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 : |
| − | * [[webmention.io]] | + | * 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== | ||
| − | + | 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 == | == Voir aussi == | ||
| − | * [[ | + | * [[CSP]] |
| − | * [[ | + | * [[https]] |
| − | *[[ | + | *[[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
vérification e-mail : https://sec.hpi.de/ilc/dataprivacy
indieweb
Cet article est une débauche. Vous pouvez m’aider à l'améliorer.
(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.
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 :
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 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