HTTPS et l'authentification de base sont-ils suffisamment sécurisés pour les services Web bancaires (RESTful)?
J'ai lu sur SSL/TLS ces derniers jours et on dirait qu'il n'a jamais été pratiquement craqué.
Étant donné que SSL/TLS est utilisé pour toutes les communications entre l'application cliente et le serveur, et étant donné que le mot de passe/la clé API est aléatoire et fort et stocké en toute sécurité côté serveur (bcryté, salé), pensez-vous que Basic Auth est suffisamment sécurisé, même pour les services bancaires?
Je vois beaucoup de gens qui n'aiment pas l'idée que le nom d'utilisateur/mot de passe soit envoyé sur le fil à chaque demande. Est-ce un vrai point faible de Basic Auth (même avec SSL/TLS utilisé), ou est-ce juste par peur irrationnelle?
L'authentification de base HTTP n'est pas très utilisée dans les connexions navigateur-serveur car elle implique, du côté du navigateur, une fenêtre contextuelle de connexion contrôlée par le navigateur qui est toujours laide. Bien sûr, cela ne s'applique pas aux connexions serveur-serveur, où il n'y a aucun utilisateur humain pour observer la laideur, mais cela contribue à un climat général de méfiance et de non-utilisation pour l'authentification de base.
De plus, dans les années 1990, avant l'époque de SSL, l'envoi de mots de passe en clair sur le fil était considéré comme une infraction de tir, et, dans leur folie, les gens considéraient que les protocoles de défi-réponse tels que HTTP Digest étaient suffisants pour assurer la sécurité. Nous savons maintenant que ce n'est pas le cas; quelle que soit la méthode d'authentification, le trafic complet doit être lié au moins cryptographiquement à l'authentification pour éviter le détournement par des attaquants actifs. SSL est donc requis . Mais lorsque SSL est en vigueur, l'envoi du mot de passe "tel quel" dans le tunnel SSL est correct. Donc, pour résumer, l'authentification de base en SSL est suffisamment puissante pour des fins sérieuses, y compris les codes de lancement nucléaire, et même pour des questions liées à l'argent.
Il faut tout de même souligner que la sécurité repose sur l'impossibilité de attaques Man-in-the-Middle qui, dans le cas de SSL (comme il est couramment utilisé), repose sur le certificat du serveur. Le client SSL (un autre serveur dans votre cas) DOIT valider le certificat du serveur SSL avec grand soin, notamment en vérifiant l'état de révocation en téléchargeant la liste de révocation de certificats appropriée. Sinon, si le client est redirigé vers un faux serveur, le propriétaire du faux serveur apprendra le mot de passe ... En ce sens, l'utilisation de quelque chose comme HTTP Digest ajoute une couche supplémentaire d'atténuation au cas où la situation deviendrait déjà assez pourrie, car même avec HTTP Digest, un faux serveur faisant un MitM peut toujours détourner la connexion à tout moment.
Si nous allons un peu plus loin, nous pouvons noter que lorsque nous utilisons l'authentification par mot de passe, nous voulons en fait une authentification mutuelle par mot de passe . Idéalement, le client SSL et le serveur SSL devraient s'authentifier en fonction de leur connaissance du mot de passe partagé. Les certificats sont là une complication inutile; théoriquement, le client et le serveur SSL devraient utiliser TLS-PSK ou TLS-SRP dans cette situation, et éviter complètement toutes les activités de certificats X.509.
En particulier, dans SRP, ce que le serveur stocke n'est pas le mot de passe lui-même mais un dérivé de celui-ci (un hachage avec une structure mathématique supplémentaire). Il faut noter un point important: dans le cas d'une API Web, le client et le serveur sont des machines sans intervention humaine. Par conséquent, le "mot de passe" n'a pas besoin d'être suffisamment faible pour être mémorisé par les sacs de viande. Ce mot de passe pourrait être, disons, une séquence de 25 caractères aléatoires, avec une entropie traversant le toit. Cela rend les méthodes de hachage de mot de passe habituelles (hachage lent, sels) inutiles. Nous voulons toujours éviter de stocker dans la base de données du serveur (donc en proie à des injections SQL potentielles) les mots de passe "tels quels", mais, dans ce cas , un hachage simple suffirait.
Cela indique ce qui suit: idéalement, pour qu'une API RESTful soit utilisée par un serveur pour parler à un autre, avec une authentification basée sur un secret partagé (gras), la communication doit utiliser TLS avec SRP. Aucun certificat, uniquement des hachages stockés sur le serveur. Pas besoin d'authentification de base HTTP ou de toute autre authentification basée sur HTTP, car tout le travail aurait déjà eu lieu au niveau SSL/TLS.
Malheureusement, l'état actuel de déploiement des implémentations SSL/TLS compatibles SRP signifie généralement que vous ne pouvez pas encore utiliser SRP. Au lieu de cela, vous devrez utiliser un SSL/TLS plus banal avec un certificat X.509 côté serveur, que le client valide consciencieusement. Tant que la validation est effectuée correctement, il n'y a aucun problème à envoyer le mot de passe "tel quel", par ex. dans le cadre de l'authentification HTTP de base.
Un problème principal avec l'authentification HTTP est qu'il n'y a pas d'autre moyen de se déconnecter que de fermer votre navigateur. Et comme le mot de passe accompagne chaque demande, l'authentification est sans état. Par exemple, vous ne pouvez pas déconnecter les utilisateurs après 20 minutes d'inactivité.
Les sites de haute sécurité comme les banques fourniront généralement (toujours?) Non seulement un moyen à un utilisateur de se déconnecter manuellement, mais également déconnecteront l'utilisateur après une période d'inactivité. Cela aide à prévenir un certain nombre d'attaques opportunistes.
En fait, j'ai vu ces demandes envoyées par ma banque. Cependant, ils utilisent toujours des identifiants de session au lieu d'envoyer le nom d'utilisateur et le mot de passe à chaque fois (ce n'est pas vraiment reposant, je sais). La raison pour laquelle ils n'utilisent pas seulement le nom d'utilisateur et le mot de passe mais une session est parce qu'ils nécessitent un deuxième facteur d'authentification. Cela signifie que vous devrez ressaisir votre réponse au défi pour chaque rechargement de page.
Si votre banque utilise simplement un nom d'utilisateur et un mot de passe, alors honnêtement, je m'en fiche. Mais à mon avis, toute application bancaire qui se respecte devrait utiliser une forme d'authentification à deux facteurs: soit par SMS, lecteurs de cartes, jetons, ...