Sécurisation de la connexion unique à l'application Web

Question

Je dois créer une structure de connexion unique et ma question est la suivante: SSL est-il un must?

Détails: L'application aura un lien vers mon application web. Lorsque l'utilisateur clique sur ce lien, son nom d'utilisateur local est transmis à mon application Web, auquel cas une recherche dans un fichier de mappage est effectuée. Si ce nom d'utilisateur local existe sur la carte, l'utilisateur est connecté. Sinon, l'utilisateur sera invité à entrer son nom d'utilisateur et son mot de passe, et une fois authentifié, une entrée dans la carte sera créée.

Comment puis-je m'assurer que l'utilisateur est ce qu'il prétend être et non Joe Blow de la rue envoyant une requête HTTP POST avec ce nom d'utilisateur?

Dois-je utiliser SSL (et si oui, qu'est-ce que cela implique)? Ajouter un sel et chiffrer le nom d'utilisateur suffirait-il? Peut-être le verrouiller afin que l'IP source doit être dans une plage contrôlée? Mon application Web fonctionne sur IIS 6/7 et utilise le framework ASP.NET MVC, si cela est important.

Answer 1

Cela ressemble à une mauvaise façon de procéder à l'authentification puisque l'utilisateur ne transmet aucun secret à la webapp. Comme c'est sur l'intranet le plus probable, je suppose que vous pouvez vous en sortir en utilisant les hashs du nom d'utilisateur + sel comme identificateur de session. Je ne suis pas sûr d'avoir utilisé ASP.NET, mais je suis sûr qu'il vous permet de créer des sessions qui n'expirent jamais la route que j'emprunterais plutôt que de réimplémenter la roue, à moins bien sûr de mettre à jour dynamiquement les ID de session dans l'application de bureau. .

Answer 2

Semble que vous souhaitez utiliser des certificats côté client SSL. La façon dont vous implémentez cela dépend de votre configuration.

Autres informations à garder à l'esprit:

Si je veux envoyer « dmoules » à votre application, je peux. Tu ne peux pas m'empêcher de faire ça. Vous devez vous authentifier via une source fiable qui fournit une preuve d'identité. Vous ne pouvez pas croire que les requêtes HTTP proviennent de votre application sans modification (par exemple, un client-cert).