connexion sécurisée avec des informations contextuelles supplémentaires passe par (qui doit également être sécurisé)

Question

Mon application web sera lancée par les applications clientes existantes d'épaisseur. Lors de son lancement, une requête HTTP POST sera généré, y compris des informations telles que l'ID utilisateur et des informations contextuelles supplémentaires (essentiellement de choses comme le nom de l'utilisateur cible, anniversaire, etc.).

Mon plan d'authentification consiste à créer une table de consultation dans la base de données. Si le nom d'utilisateur est déjà là, connectez-vous automatiquement à l'utilisateur, mais s'il n'y a pas d'entrée dans la base de données, rediriger l'utilisateur vers une page de connexion initial qui sera utilisé pour créer cette entrée de la base de données.

Ma question est comment sécuriser cela contre MITM et d'autres failles de sécurité. Comment la requête générée par le client lourd peut-elle être sur une connexion SSL? Une connexion SSL ne doit-elle pas d'abord être authentifiée avec le nom d'utilisateur (et le mot de passe)? Et si oui, les informations contextuelles supplémentaires seront-elles exposées publiquement jusqu'à ce que l'utilisateur soit connecté? Désolé, c'est une question de sécurité de base de 101. Des références sur les bases de la sécurité seraient également très appréciées.

Answer 1

Non, SSL ne nécessite aucun nom d'utilisateur ou mot de passe pour fonctionner. SSL crypte uniquement les données entre le client et le serveur. Vous pouvez servir un site accessible de manière entièrement anonyme via SSL. La plupart du temps, les gens assimilent SSL et les connexions parce que vous voulez crypter vos identifiants de connexion et l'une des informations accessibles à l'aide ces informations d'identification.

Si vous souhaitez utiliser votre méthode, il vous suffit de publier l'ID utilisateur et d'autres informations sur votre site SSL. Le message et toute réponse seront cryptés. Si vous utilisez une page Web, cela ressemblerait à ceci.

<form method="POST" action="https://mysite.com/login"> 

Génération à partir d'une application, utilisez https: // lors de la création de votre URL à publier. En ce qui concerne les autres problèmes de sécurité, nous n'avons pas assez d'informations pour parler de la sécurité globale de votre déploiement planifié, mais ce qui précède devrait prendre en compte vos questions initiales sur SSL et le cryptage.