Pourquoi refusez-vous d'utiliser TLS? Cela fonctionne, il a un bon bilan (à part quelques exceptions mineures). Refuser d'utiliser de bons outils sans raison impérieuse n'engendre pas de confiance et ne suggère pas immédiatement du professionnalisme.

De plus, ne lancez pas votre propre système d'authentification. C'est idiot et vous ferez des erreurs. Au lieu de cela, puisque vous vous attendez à ce que vos utilisateurs aient un compte Facebook, utilisez OAuth2 pour consommer une identité et une authentification fédérées. Mieux encore, sous-traiter cela à un service de fédération qui l'a maîtrisé et fournit même des extraits de code ( https://oauth.io/ vient à l'esprit).

Ne vous compliquez pas la vie.

Les certificats SSL / TLS seront gratuits d'ici le deuxième trimestre 2015. Obtenez le certificat ici:

https://letsencrypt.org/

Let's Encrypt proposera gratuitement des certificats validés par le domaine signés via IdenTrust.

Lorsque cela sera mis en ligne, ces questions devraient être fermées, à mon humble avis

Quels autres bons conseils pourraient être pour obtenir autant de sécurité que possible sans utiliser SSL?

Vous pouvez utiliser TLS au lieu de faire quelque chose de stupide.

Ce que vous essayez de faire est impossible sans un moyen sécurisé d'envoyer vos fichiers au client, tel que TLS. Vos approches de hachage du mot de passe côté client nécessitent que le javascript soit envoyé en toute sécurité au client. Sinon, un MITM pourrait simplement servir un script qui ne hache pas le mot de passe, mais leur envoie plutôt le mot de passe en texte clair directement.

La partie importante est que vous avez besoin de code de confiance sur le client . Avec TLS, ce code de confiance est le navigateur, qui à son tour vérifie l'intégrité de votre javascript pour le rendre également fiable. Sans vous fier à cela ou à quelque chose d'équivalent (que je ne connais pas), vous ne pouvez pas faire d'hypothèses sur ce qui fonctionne sur la machine du client.

Le seul moyen d'être sécurisé sans TLS est un plugin de navigateur, qui doit être téléchargé ... via TLS. Et un plugin de navigateur est un énorme inconvénient en termes d'utilisation.

La raison en est qu'il doit y avoir un code de confiance sur l'ordinateur de l'utilisateur. Cela peut être soit le code TLS dans le navigateur de l'utilisateur, soit le code du plugin.

Les autres réponses sont claires - utilisez SSL

cependant, pour indiquer ce qui échouerait si vous l'implémentiez comme décrit:

J'ai pensé à le résoudre avec un premier hachage côté client avec JavaScript, puis côté serveur, si je reçois des valeurs hachées (au cas où quelqu'un supprime du JavaScript), un second hachage et stocker ces valeurs hachées dans la base de données utilisateur. Est-ce un moyen sûr de le mettre en œuvre? De plus, y a-t-il des chances que certaines données soient perdues? Si tel est le cas, comment puis-je savoir si les données reçues ne sont pas compromises?

donc dans ce scénario, un MITM recevrait le hachage envoyé par le client - s'il s'agissait d'une connexion ou similaire, ils peuvent le copier, puis l'envoyer chaque fois qu'ils souhaitent se connecter en tant que X. Risque de perte de données? avec un MITM, il est fondamentalement garanti que certaines données peuvent être perdues - la question est de savoir si vous pourrez les détecter? quant à savoir comment savoir que les données reçues ne sont pas compromises, la manière typique serait de les signer.

Si vous ne devez vraiment pas utiliser SSL, vous pouvez le retirer en toute sécurité via WS Security à la place, mais attention, cela va être plus compliqué que le simple SSL.

Protégez-vous des attaques par dictionnaire et par force brute.

En général, ils peuvent être vaincus comme vous l'avez décrit, mais les fois où vous devez vraiment vous soucier de la force brute les attaques sont des attaques hors ligne - c'est-à-dire lorsque votre code n'est pas en cours d'exécution et ne peut pas protéger les données en limitant la fréquence des tentatives de connexion - de nombreux cycles de hachage sont nécessaires pour le faire

Le formulaire de connexion . Je l'ai implémenté de cette manière (sans le hachage pour le moment)

Quelle serait exactement la différence pour un attaquant s'il voyait une URL hachée ou une charge utile hachée des mêmes données? de toute façon, si vous ne voulez pas les données dans l'URL, utilisez un HTTP POST au lieu d'un HTTP GET

Il existe en fait un système d'authentification "sécurisé" sur le Web qui est antérieur à SSL appelé Authentification d'accès numérique, donc ce que l'interrogateur demande n'est pas tout à fait impossible. Ceci est BEAUCOUP moins sécurisé que SSL, et est sujet au forçage brutal du mot de passe par des attaques hors ligne, ainsi qu'à l'utilisation d'un ancien algorithme de hachage MD5 peu fiable.

Je donnerais toujours le même conseil que tout le monde cependant, et vous dire que SSL est de loin la meilleure solution que de compter sur un système obsolète basé sur des défis-réponses qui n'a pas été mis à jour depuis 1993.