Connexion sans HTTPS, comment la sécuriser ?

Question

Dans le cas d'une application Web, lorsque le protocole HTTPS n'est pas disponible par mesure de sécurité, est-il possible de sécuriser quelque peu la connexion ? Par exemple :

• Tokeniser les logins, pour rendre les attaques répétées difficiles ?
• Comment crypter le mot de passe envoyé à partir d'un champ de mot de passe HTML ?

En particulier, j'utilise CakePHP et un appel POST AJAX pour déclencher l'authentification (incluant le nom d'utilisateur et le mot de passe fournis).

Mise à jour du problème :

• HTTPS n'est pas disponible. Point final. Si vous n'aimez pas la situation, considérez-la comme une question théorique.
• Il n'y a pas d'exigences explicites, vous disposez de tout ce que HTTP, PHP et un navigateur (cookies, JavaScript, etc.) offrent dans la vie réelle (pas de binaires RSA magiques, de plugins PGP).
• La question est, quel est le meilleur, vous pouvez faire à partir de ce c'est mieux que d'envoyer les mots de passe en clair. Connaître les inconvénients de chacune de ces solutions est un plus.
• Toute amélioration meilleure que les mots de passe simples est la bienvenue. Nous ne visons pas une solution 100% l33tG0Dhx0r-proff. Difficile à craquer est mieux que compliqué à pirater, ce qui est mieux qu'un simple reniflage révélant le mot de passe.

Answer 1

HTTPS est absolument indispensable en maintenant une connexion sécurisée entre un site web et un navigateur. Les réseaux wifi publics mettent les utilisateurs en danger et lorsqu'il est utilisé correctement, HTTPS est le seul outil qui peut protéger les comptes utilisateurs de cette vulnérabilité .

Si votre hôte ne prend pas en charge HTTPS, un service comme SSL universel de Cloudflare peut être utilisé pour s'assurer que tous les navigateurs se connectent à votre site en utilisant HTTPS, même si votre serveur ne supporte pas SSL/TLS . La connexion entre Cloudflare et votre site web ne sera toujours pas protégée, mais ce service Cloudflare est destiné à protéger les utilisateurs contre les menaces présentes sur les réseaux wifi publics. Du point de vue d'un testeur de pénétration, ne pas fournir HTTPS est très suspect. Si vous ne fournissez pas une exigence de sécurité de base comme la livraison du trafic, alors quelles autres exigences de sécurité manquez-vous ? Les certificats HTTPS peuvent être obtenus gratuitement à l'aide des outils suivants Let's Encrypt ou Démarrer SSL il n'y a aucune raison légitime de ne pas prendre en charge le protocole HTTPS.

HTTPS est vital parce qu'il fait beaucoup plus que simplement "crypter les mots de passe". Un autre rôle important est qu'il doit empêcher l'utilisateur de se connecter à un serveur malveillant qui se fait passer pour un vrai serveur. L'utilisation d'un système pour protéger le mot de passe seul est toujours une violation de la loi sur la protection des données. OWASP A9 - Protection de la couche de transport insuffisante car vous transmettez toujours les informations d'identification de la session en texte clair, ce qui est tout ce dont l'attaquant a besoin ( Mouton de feu ).

1. La cryptographie basée sur JavaScript ne peut pas être utilisée pour construire une couche de transport sécurisée. .

2. "Tokenize logins" : Si un attaquant renifle le trafic, il aura le nom d'utilisateur et le mot de passe en texte clair et pourra ils peuvent se connecter avec ces nouvelles informations d'identification. (Replay attack)

3. "Crypter d'une manière ou d'une autre le mot de passe transmis" : Après que la personne se soit connectée un attaquant peut renifler le trafic pour obtenir le mot de passe valide. identifiant de la session (cookie) et ensuite l'utiliser au lieu de se connecter. Si la session entière a été protégée par SSL/TLS, ce n'est pas un problème.

Il existe d'autres attaques plus complexes qui touchent à la fois ce système et notre infrastructure SSL actuelle. Le site SSLStrip attaque entre plus en détail. Je recommande vivement regarder la conférence Blackhat 2009 de Moxie Marlinspike qui conduisent à la Norme HTTP-Strict-Transport-Security .

Answer 2

Étant donné que vous ne pouvez pas mettre en place le protocole SSL sur le serveur web et que vous n'êtes pas un expert en sécurité, recherchez un service d'authentification sécurisée existant que vous pouvez utiliser et laissez-le gérer le protocole SSL et la complexité de la gestion des informations d'identification pour vous.

En particulier, je vous suggère d'utiliser un service d'authentification tiers gratuit, par exemple OpenID . Ils disposent de bibliothèques pour PHP dont un pour CakePHP .

---

Edit : (à propos des risques)

Si l'utilisation d'un service d'authentification sécurisé tiers (qui utilise lui-même le protocole HTTPS) peut atténuer le problème de l'authentification sans utiliser le protocole HTTPS (sur votre serveur), elle n'élimine pas entièrement la possibilité d'attaques.

Les deux attaques les plus courantes sont relecture les attaques, et détournement de session où l'attaquant est en mesure soit de réutiliser ultérieurement un jeton de session de connexion authentique, soit d'utiliser un jeton de session valide à des fins malveillantes.

L'attaque par rejeu peut être atténuée par l'expiration du jeton de session et, de préférence, par l'utilisation d'une méthode d'authentification. nonce pour empêcher la relecture des sessions et réduire le risque de détournement de session. Avec un nonce, une session légitime génère une erreur si elle est détournée avec succès, car le nonce a expiré (a été utilisé), de sorte que sa propre session n'est plus valide.

Si vous ne pouvez pas utiliser le protocole HTTPS pour crypter le jeton de session lors de sa transmission vers et depuis votre serveur, vous ne pouvez pas entièrement prévenir les attaques actives telles que les suivantes détournement de session ou man-in-the-middle attaque. Ce site mai être acceptable dans certains cas, comme les sites web ayant une petite base d'utilisateurs pour un usage non commercial.

Answer 3

En bref, sans cryptage SSL de point à point, il est impossible de le faire en toute sécurité...

L'une des raisons principales est qu'il est impossible de faire de la cryptographie sécurisée dans un navigateur. Voir cette référence - Javascript Cryptography Considered Harmful .

De plus, il n'y a aucun moyen d'être sûr que la source des informations d'identification est bien celle à laquelle vous vous adressez. En d'autres termes, il n'y a absolument aucun moyen, sans SSL, d'être sûr qu'il n'y a pas un Attaque Man-In-The-Middle en cours.

Donc non, tu ne peux pas le faire.

De plus, n'essayez même pas. Obtenez le SSL. Vous pouvez obtenir des certificats gratuits. Les hébergeurs vous donneront généralement une adresse IP dédiée pour quelques $$$ par mois. Et si vous vous souciez vraiment de la sécurité, vous utiliserez de toute façon au moins une VM avec une adresse IP dédiée.

Essayer de le faire serait La sécurité par l'obscurité au mieux, et rien au pire. SSL est un problème résolu. Pourquoi ne pas utiliser cette solution ? La sécurité n'est pas quelque chose à deviner. Utilisez les techniques appropriées. N'essayez pas d'inventer les vôtres. Cela ne marchera pas...

Answer 4

Comme vous l'avez suggéré, vous pouvez peut-être générer un jeton unique à chaque fois que la page est créée. Ce même jeton devra être renvoyé avec les données du formulaire et ne pourra pas être réutilisé. Vous pourriez également sécuriser le mot de passe en utilisant JavaScript pour le hacher, si vous pouvez compter sur l'activation de cette fonction par vos utilisateurs.

Ce système n'est cependant pas encore sûr. Un attaquant peut toujours voir tout ce qui se passe sur le réseau. Il pourrait intercepter le jeton et vous renvoyer une réponse avant que l'utilisateur ne le fasse. Il pourrait aussi attendre que quelqu'un se connecte, voler les informations d'identification de cette personne (pendant qu'elles sont envoyées par câble) et faire sa propre demande de connexion plus tard.

Ligne de fond - vous devez utiliser HTTPS pour garantir que le site est sécurisé.

Answer 5

Je ne sais pas si vous avez lu des articles sur la connexion sans mot de passe ( http://notes.xoxco.com/post/27999787765/is-it-time-for-password-less-login ) Le visiteur se rend sur votre site Web, entre son nom, son nom d'utilisateur et son adresse électronique et reçoit une adresse de connexion dans son courrier électronique. Je pense que cela devrait être suffisamment sécurisé sans https.