Tout d'abord, cela n'améliore PAS la sécurité de votre application (en supposant qu'il s'agisse d'une webapp).
Utilisez SSL (ou en fait TLS, qui est communément appelé SSL), ce n'est pas vraiment cher (mesurez le temps que vous utilisez pour trouver des moyens de le contourner et multipliez-le par le salaire minimum, l'achat d'un certificat gagne presque toujours).
Le pourquoi de cela est simple. TLS résout un problème (lorsqu'il est utilisé avec des certificats achetés et non auto-signés) qui est assez important en cryptographie: Comment savoir que le serveur auquel je parle est le serveur auquel je pense parler? Les certificats TLS sont une façon de dire: «Moi, l'autorité de certification, approuvée par votre navigateur, certifie que le site Web à [url] possède cette clé publique, avec une clé privée correspondante, que (clé privée) seul le serveur connaît, regarde J'ai signé ma signature sur tout le document, si quelqu'un l'a modifié, vous pouvez le voir ".
Sans TLS, tout cryptage devient inutile, car si je suis assis à côté de vous dans un café, je peux faire croire à votre ordinateur portable / smartphone que je suis le serveur et MiTM (Man in The Middle) vous. Avec TLS, votre ordinateur portable / smartphone criera "CONNEXION NON DE CONFIANCE", car je n'ai pas de certificat signé par une autorité de certification correspondant à votre site. (Cryptage vs Authentification).
Avis de non-responsabilité: les utilisateurs ont tendance à cliquer à droite sur ces avertissements: "Connexion non approuvée? Quoi? Je veux juste mes photos de chatons! Ajouter une exception Cliquez sur Confirmer Cliquez OUI! Chatons!"
Cependant, si vous ne voulez vraiment pas acheter de certificat, implémentez toujours le hachage javascript côté client (et utilisez la bibliothèque standford (SJCL) pour cela, NE JAMAIS IMPLÉMENTER CRYPTO YOURSELF ).
Pourquoi? Réutilisation du mot de passe! Je peux voler votre cookie de session (ce qui me permet de prétendre à votre serveur que je suis vous) sans HTTPS facilement (voir firesheep). Cependant si vous ajoutez un javascript à votre page de connexion qui, avant l'envoi, hache votre mot de passe (utilisez SHA256, ou mieux encore, utilisez SHA256, envoyez-leur une clé publique que vous avez générée puis cryptez le mot de passe haché avec cela, vous ne pouvez pas utiliser de salt avec ceci), puis envoie le mot de passe haché / chiffré au serveur. REHACHEZ le hachage sur votre serveur avec un sel et comparez-le à ce qui est stocké dans votre base de données (stockez le mot de passe comme ceci:
(SHA256(SHA256(password)+salt))
(enregistrez également le sel en texte brut dans la base de données)). Et envoyez votre mot de passe comme ceci:
RSA_With_Public_Key(SHA256(password))
et vérifiez votre mot de passe comme ceci:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Parce que, SI quelqu'un renifle votre client, il pourra se connecter en tant que client (piratage de session) mais il ne verra JAMAIS le mot de passe en clair (à moins qu'il ne modifie votre javascript, cependant, un pirate informatique de Starbucks ne saura probablement pas comment / être intéressé dans ce cas.) Ils auront donc accès à votre webapp, mais pas à leur email / facebook / etc. (pour lequel vos utilisateurs utiliseront probablement le même mot de passe). (L'adresse e-mail sera son nom de connexion ou sera trouvée dans son profil / paramètres sur votre application Web).