Le SSL est-il vraiment important pour la plupart des sites Web?

11

J'ai été assez paranoïaque pour apprendre à "bien faire la sécurité" pour ce site que je construis (premier site non trivial que j'ai créé), et j'ai remarqué quelque chose qui me dérange: SSL.

J'ai lu de nombreux threads de sécurité ici, sur StackOverflow et ailleurs, qui parlent longuement de la régénération des identifiants de session après n utilisations et de la façon dont vos mots de passe doivent être salés, hachés et jamais stockés en texte brut. J'ai lu beaucoup de choses sur la façon de détecter lorsqu'une session a été piratée, en suivant les adresses IP, les agents utilisateurs et en utilisant les cookies de suivi.

Ce que je ne comprends pas, c'est ce qui importe lorsque le site Web vous connecte via un POST HTTP normal et envoie votre mot de passe sur le fil en texte brut?

Je comprends que toutes les autres méthodes que j'ai énumérées sont nécessaires pour réduire votre exposition globale, et peut-être qu'il y a des sites qui n'ont tout simplement pas besoin de beaucoup de sécurité de toute façon, mais je suppose que ce que je demande est:

Quand est-il acceptable de ne pas s'embêter avec SSL?

Des sites comme Gmail, votre banque et LinkedIn, je peux voir qu'il y a une raison d'utiliser SSL, mais ce qui fait que des sites comme Facebook et reddit ne dérangent pas (bon sang, PlentyOfFish stocke même votre mot de passe en texte brut et même par e-mail) à vous chaque semaine pour rappel!?!)?

Dans quelle mesure devrais-je m'inquiéter de m'assurer que SSL est configuré (d'autant plus que je commencerais avec un hôte partagé et que je suis assez bon marché pour commencer)? Mon site ne contiendra aucune information particulièrement personnelle, si cela vous aide. Si le site devient un succès, j'envisagerais sérieusement de payer le supplément pour la sécurité supplémentaire.

https security authentication

— AgentConundrum
source

7

Cela compte autant que vous et vos utilisateurs le pensez. L'envoi de mots de passe sur http en texte brut les rend vulnérables au reniflage de paquets. Maintenant, si quelqu'un va vraiment déranger ces paquets, c'est une toute autre histoire. Si vous souhaitez garantir à vos utilisateurs l'expérience la plus sécurisée possible, utilisez SSL pour leurs soumissions de connexion. Si vous pensez que vos utilisateurs seront plus heureux et plus susceptibles d'interagir avec votre site Web de manière positive (par exemple, acheter des choses, faire des choses, etc.), utilisez SSL pour leurs soumissions de connexion. Si vous avez quelque chose qui mérite d'être volé (c'est-à-dire des informations utilisateur), utilisez SSL.

Si vous n'avez rien à voler, ne pensez pas que SSL améliorera la sécurité beaucoup ou pas du tout, ou que vos utilisateurs ne la verront pas comme une fonctionnalité utile, alors vous voudrez peut-être ne pas utiliser SSL.

Pour ce qu'il en coûte pour installer un certificat SSL, à moins que vous n'ayez un budget restreint, ce n'est jamais une mauvaise chose de sécuriser la connexion d'un site. Et ne laissez pas ce que font d'autres sites vous influencer, car de nombreux sites plus importants ne suivent pas nécessairement les meilleures pratiques, c'est pourquoi il y a apparemment un flux constant de nouvelles sur l'un d'entre eux compromis d'une manière ou d'une autre.

— John Conde
source

1

+1 "de nombreux sites plus importants ne suivent pas nécessairement les meilleures pratiques" - Je suis sûr qu'il y aura des gros titres risibles lorsque les 419 nigérians trouveront un moyen de monétiser les profils de sites de rencontres volés :)

— danlefree

"à moins que vous ayez un budget restreint" - mais je le suis. Je suis vraiment, vraiment, au point que j'envisage d'aller m + m sur un hôte partagé bon marché plutôt que de payer considérablement moins par mois pour payer une année d'avance. De cette façon, je peux débrancher si le site ne commence pas à se payer assez rapidement. Je pense que pour l'instant je penche vers le no-ssl, car le simple fait d'obtenir l'ip statique nécessaire doublerait presque mon coût mensuel, sans parler du coût du certificat lui-même. Le site est assez proche d'être un forum, et la plupart des données sont publiques, il n'y a donc pas besoin de chiffrement en dehors de la connexion.

— AgentConundrum

@danlefree, c'est facile. Utilisez les informations personnelles sur les sites de rencontres pour répondre aux questions de récupération de mot de passe pour le courrier électronique et le site bancaire des utilisateurs. Ou capturez simplement le mot de passe, car les gens réutilisent leur mot de passe, beaucoup trop.

— Zoredache

@AgentConundrum Startssl propose un certificat SSL gratuitement. Si vous avez un budget serré mais que vous avez une adresse IP statique, vous pouvez opter pour cela.

— Rana Prathap

@AgentConundrum vous n'avez plus besoin d'une IP dédiée pour SSL, tant que votre hôte prend en charge SNI (et s'il ne le fait pas, trouvez un nouvel hôte car il ne sait pas ce qu'il fait). Vous pouvez obtenir un certificat gratuitement, donc ce n'est pas un coût supplémentaire non plus ...

— Doktor J

3

En adoptant l'approche opposée à la réponse de John, je pense que vous devriez sérieusement considérer SSL si vous manipulez des informations personnellement identifiables - pour inclure: les noms avec des adresses physiques, des adresses e-mail, des informations financières et des communications que les utilisateurs pourraient raisonnablement s'attendre à être privées .

À moins que votre site ne permette aux utilisateurs de publier des informations sur eux-mêmes, vous devez considérer que toutes les informations personnellement identifiables fournies par vos utilisateurs sont détenues par vous et uniquement sous une stricte confidentialité, à moins que la politique de confidentialité de votre site n'en informe autrement vos utilisateurs.

Empêchez les tiers non autorisés de voir les informations de vos visiteurs et tenez vos utilisateurs informés de la façon dont vous utilisez leurs informations pour maintenir la confiance de vos visiteurs.

Même Facebook le fait, pour autant que je sache.

<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit=";var d=document.documentElement;if (d.onsubmit) { return d.onsubmit(event); }else { return Event.fire(d, &quot;submit&quot;, event); }">

(Source HTML de connexion Facebook.com)

— danlefree
source

Impair. Je ne sais pas comment je n'ai pas remarqué cela pour Facebook. Je le regardais depuis HTTPFox et j'ai en quelque sorte manqué le 's' lors de la demande initiale. Je vais modifier pour supprimer cela. Il n'en reste pas moins que de nombreux sites le font (reddit, hacker news, TDWTF, etc.), donc au pire je ne serais pas meilleur qu'eux. Le budget est une énorme préoccupation pour moi, donc dépenser 5 $ de plus / mois pour une adresse IP statique (sur un hôte de 8 $ / mois ...) ainsi que l'achat d'un certificat décent .. J'envisagerais presque de ne pas construire le putain de putain site.

— AgentConundrum

@AgentConundrum - À strictement parler, il est OK de passer un mot de passe exécuté via un algorithme de hachage unidirectionnel sur HTTP si le mot de passe est salé, donc je ne serais pas trop surpris de voir une implémentation de hachage MD5 sur des sites qui n'utilisent pas SSL: pajhome.org.uk/crypt/md5

— danlefree

et comment la création d'un hachage côté client aiderait-elle quelque chose? Dans ce cas, le hachage est essentiellement le mot de passe . Je devrais pouvoir capturer le hachage et le rejouer aussi facilement que je peux capturer un mot de passe.

— Zoredache

1

@Zoredache C'est pourquoi le hachage doit être salé . Voici comment cela fonctionne: je vous envoie la page de connexion avec un jeton prérempli qui comprend un microtime()appel du serveur. Votre hachage transmis est une combinaison de votre mot de passe + le microtime()et, une fois que j'ai reçu votre hachage, j'invalide la microtime()paire défi / réponse + mot de passe (il ne peut pas être réutilisé).

— danlefree

3

En août 2014, Google a officiellement indiqué que HTTPS serait utilisé comme signal de classement.

Cela signifie que même si votre site Web est un site Web complètement statique, si vous vous souciez du référencement, vous devriez au moins envisager de configurer un certificat SSL.

Bien sûr, HTTPS n'est qu'un signal de classement sur des centaines, il y a donc probablement des choses plus importantes que vous pouvez faire pour le référencement.

— kqw
source

Google a également annoncé que la configuration d'un certificat SSL nécessitant des ressources, vous ne devez le faire que si votre site Web l'exige. En bref, ils ont mentionné que votre classement ne sera pas affecté simplement parce que vous n'avez pas configuré de certificat SSL sur votre blog personnel.

— Rana Prathap

1

Voici un angle que vous n'avez peut-être pas considéré: ne pas utiliser SSL / TLS peut exposer vos utilisateurs à une surveillance passive même si votre site n'a pas de connexion.

Un acteur de la menace peut simplement s'asseoir entre votre utilisateur et le reste d'Internet, regarder toutes les URL que votre utilisateur demande et créer des modèles de choses que votre utilisateur consulte. Les informations individuelles peuvent certes être insignifiantes isolément, mais la combinaison de nombreuses informations peut créer une image beaucoup plus large.

C'est pour cette raison que je propose HTTPS sur mon propre site, qui ne fournit que du contenu statique.

— zigg
source