Différences entre versions de « Security »
De Mi caja de notas
| (2 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}} | {{stub-fr}} | ||
| Ligne 75 : | Ligne 79 : | ||
== Traiter des problèmes inconnus == | == Traiter des problèmes inconnus == | ||
Selon https://en.wikipedia.org/wiki/Secure_by_design : | 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 ?''). | * 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. | * Réfléchissez à l'avance sur les implications de sécurité de fonctionnalités comme des messages privés. | ||
| Ligne 90 : | Ligne 94 : | ||
| + | |||
| + | <!-- | ||
== autres points à classer pour [[La Maison Ducamp]] == | == autres points à classer pour [[La Maison Ducamp]] == | ||
| Ligne 96 : | Ligne 102 : | ||
** (carte [[Banques|bancaire]] 3ème essai à tenter. repartir en pensée visuelle | ** (carte [[Banques|bancaire]] 3ème essai à tenter. repartir en pensée visuelle | ||
** code de la porte (inscrit sur le wiki dans l'invite à [[thierry]]) | ** 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