Différences entre versions de « Security »
De Mi caja de notas
m |
(traduction en cours) |
||
| Ligne 9 : | Ligne 9 : | ||
{{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 : | ||
* [[iwc:CSP]] | * [[iwc:CSP]] | ||
| Ligne 23 : | Ligne 25 : | ||
== 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. |
[[File:github-security-history-example.png|400px]] | [[File:github-security-history-example.png|400px]] | ||
=== Activité Récente de Google === | === Activité Récente de Google === | ||
| − | [[Google]] | + | |
| + | [[Google]] fournit un [https://www.google.com/settings/security journal de sécurité de l'activité récente] avec les date, navigateur et OS utilisés pour accéder à votre compte et d'autres informations : | ||
[[File:google-security-history-example.png|400px]] | [[File:google-security-history-example.png|400px]] | ||
| − | == | + | == Violations == |
| − | + | Violations de sécurité rapportées par les sites | |
=== 2014 === | === 2014 === | ||
| Ligne 45 : | Ligne 49 : | ||
== Problèmes reproductibles == | == Problèmes reproductibles == | ||
| − | === https http | + | === sabotages https http === |
Today, when standards like [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] | Today, when standards like [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] | ||
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. | 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. | ||
Version du 30 décembre 2016 à 11:01
Cet article est une ébauche. Vous pouvez m'aider à l'améliorer et le compléter. Merci.
(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 date, navigateur 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
Today, when standards like HSTS try to mitigate https to http degradation attacks, there's no reason to allow http at all. All http should redirect to 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).
- 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.
Hébergement Web
Should you write about your web hosting setup?
In some regards yes, to help out other members of the community.
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.
So, how do you share information without endangering yourself in that regard?
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.
Dealing with unknown problems
Per https://en.wikipedia.org/wiki/Secure_by_design :
- Peer review existing protocols and implementations.
- Look for docs, advice, potential peer-reviewers at communities like MIT's Liberationtech mailing list (any other ideas?).
- Think in advance about security implications of features like private messages.
- Always prefer existing and popular (i.e. constantly peer reviewed) technology to reinventing crypto.
- Eventually - prepare guidelines for site owners and developers on the Wiki (similar to Eff's SSD).