Question:
BASIC-Auth est-il sécurisé s'il est effectué via HTTPS?
Morten
2010-12-06 04:42:45 UTC
view on stackexchange narkive permalink

Je suis en train de créer une API REST et il est simple de se connecter avec l'authentification BASIC. Ensuite, laissez HTTPS sécuriser la connexion afin que le mot de passe soit protégé lorsque l'API est utilisée.

Cela peut-il être considéré comme sécurisé?

Oui, l'utilisateur / pass http sera OK car il passe sur SSL, mais le mot de passe doit être fort.
Eh bien, je pourrais mettre une logique dans mon serveur qui interdit un client qui tente trop de mots de passe. Cela empêcherait-il le DoS et le mot de passe de deviner?
Neuf réponses:
#1
+303
AviD
2010-12-06 05:18:48 UTC
view on stackexchange narkive permalink

Il y a quelques problèmes avec l'authentification de base HTTP:

  • Le mot de passe est envoyé sur le câble en codage base64 (qui peut être facilement converti en texte brut).
  • Le mot de passe est envoyé à plusieurs reprises, pour chaque demande. (Fenêtre d'attaque plus grande)
  • Le mot de passe est mis en cache par le navigateur Web, au minimum pour la longueur de la fenêtre / du processus. (Peut être réutilisé silencieusement par toute autre demande au serveur, par exemple CSRF).
  • Le mot de passe peut être stocké de manière permanente dans le navigateur, si l'utilisateur le demande. (Identique au point précédent, en plus peut être volé par un autre utilisateur sur une machine partagée).

Parmi ceux-ci, l'utilisation de SSL ne résout que le premier. Et même avec cela, SSL ne protège que jusqu'à ce que le serveur Web - tout routage interne, journalisation du serveur, etc. verra le mot de passe en clair.

Donc, comme pour tout ce qui est important, il est important de regarder la situation dans son ensemble.

HTTPS protège-t-il le mot de passe en transit? Oui.

Est-ce suffisant? Généralement non. (Je veux dire, toujours non - mais cela dépend vraiment de ce qu'est votre site et de sa sécurité.)

en fait, même avec HTTP Digest, vous pourrez peut-être faire un hachage du mot de passe (`md5 (username: realm: password)`, parfois appelé HA1).
@AviD ♦ Imho vos points 3) et 4) sont rarement valides pour les API REST.
En cas d'authentification de base, le mot de passe «doit être» stocké dans le navigateur, ce qui ne peut être fait que via un cookie, ce qui ne peut jamais être considéré comme sûr. J'ai posté une question similaire ici: http://stackoverflow.com/questions/27177224/how-to-keep-state-at-the-client-safely/27177995#27177995 Ma conclusion était que l'authentification de base n'est PAS sûre, qu'elle ne doit PAS être utilisé en tant que tel, et que le stockage de données sensibles chez le client (comme un mot de passe utilisateur) ne doit même pas être envisagé.
@KimGysen for Basic Auth, le mot de passe n'est PAS transmis ou stocké dans un cookie, il est envoyé dans l'en-tête de demande `Authorization:`, et stocké dans une partie spéciale (protégée) de la mémoire du navigateur. Non pas que je ne sois pas d'accord avec vous, dans le cas général, l'authentification de base ne devrait pas être utilisée, mais il existe certaines situations où le compromis pourrait être viable.
Le deuxième point n'est pas un problème. L'envoi d'informations d'identification avec chaque demande maintient votre backend sans état.
En plus de la «fenêtre d'attaque plus large», il n'y a pas de mécanisme intégré comme le verrouillage de compte pour se protéger contre le forçage brutal.
@Artjom: L'envoi d'informations d'identification de base sur chaque demande est un problème, non pas parce que vous devez continuer à envoyer les informations d'identification, mais plutôt parce que la même chaîne est envoyée à chaque demande. Il existe d'autres mécanismes d'authentification, comme HMAC, où l'en-tête d'autorisation ne peut pas être déchiffré vers le secret de l'utilisateur, et le serveur peut authentifier la demande sans connaître réellement le secret de l'utilisateur. Dans ce mécanisme, la chaîne envoyée sur l'en-tête d'autorisation change en fonction du hachage de la demande.
@LieRyan Honnêtement, je ne comprends pas: - \. Quel est le problème avec l'envoi de la même chaîne? Est-ce parce que la variété est le piment de la vie?
Attaque de relecture @DavidS:. De plus, si vous passez votre trafic via un proxy ou un service CDN, vous avez l'assurance qu'un attaquant ne peut pas attaquer le proxy / CDN pour modifier les demandes de l'utilisateur.
@Bruno, HTTP Digest est * pire * car il oblige le serveur à stocker les mots de passe utilisateur en texte brut!
@Jacco En principe, le serveur ne peut stocker que `md5 (username: realm: password)` et n'a pas besoin du mot de passe en clair (vous pouvez vérifier le contenu d'un fichier généré avec `htdigest` par exemple).Cela dépend de la mise en œuvre.Cela dit, ce n'est toujours pas génial (également avec l'inconvénient d'être facilement vulnérable aux attaques de rétrogradation vers Basic).
"Fenêtre de pièce jointe plus grande" Donc, le jeton de session normal qui envoie comme cookie a également le même problème, non?
@JithinJose qui n'inclurait pas le mot de passe de l'utilisateur, ni statique + valide pendant très longtemps.
@LieRyan HMAC ne fait pas partie des mécanismes d'authentification HTTP standard, contrairement à Basic et Digest.Parliez-vous de [celui implémenté par AWS] (https://docs.aws.amazon.com/en_us/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader)?
@LieRyan: La relecture et le scénario proxy / CDN ne sont pas possibles avec TLS, sauf si TLS présente une faille.
#2
+91
Nemo
2012-07-15 08:27:07 UTC
view on stackexchange narkive permalink

Essayez d'y penser de cette façon: lorsque vous vous connectez à un site Web en utilisant SSL, vous transmettez probablement le mot de passe en texte brut sur HTTPS (par exemple, GMail).

La seule différence que Basic-Auth fait est que nom d'utilisateur / mot de passe est passé dans les en-têtes de la requête au lieu du corps de la requête (GET / POST).

En tant que tel, en utilisant basic-auth + https n'est ni moins ni plus sécurisée qu'une authentification par formulaire via HTTPS.

Il y a une légère différence entre ces situations: avec l'authentification de base http, le mot de passe est envoyé pour * chaque demande *, tandis qu'avec une connexion basée sur un formulaire, il n'est envoyé qu'une seule fois, puis quelque chose comme un cookie de session est utilisé. Cela diminue * très légèrement * la surface d'attaque.
Le mot de passe de l'utilisateur n'est envoyé qu'une seule fois mais le cookie d'authentification est également envoyé à chaque demande, donc la question est uniquement d'envoyer l'utilisateur et le mot de passe à la place du cookie d'auth
@deFreitas et vous avez donc la prémisse d'OAuth: utiliser un autre jeton pour l'authentification au lieu d'envoyer le u / p tout le temps.
Je pense qu'il y a plus qu'une légère différence: dans l'exemple de formulaire POST, le rendu de la page initiale doit être envoyé via HTTPS avant que l'utilisateur ne décide de saisir ses informations d'identification et de les POST (en toute sécurité). Avec l'authentification de base HTTP, même si le serveur refuse de traiter une requête non HTTPS et de la rediriger vers HTTPS, les informations d'identification sont déjà passées sur le fil de manière non sécurisée et sont alors vénérables pour le snooping MiTM. Le client doit décider de POST HTTPS initialement ou risquer un canal non sécurisé. Cela est moins probable avec le scénario POST de formulaire.
@PepijnSchmitz Je noterais que la différence d'une clé de session (qui peut être invalidée) est très différente du vol des informations de connexion.Des dommages peuvent toujours être infligés pendant qu'une autre partie a votre clé de session privée, mais leur nature est beaucoup plus limitée, d'autant plus que vous pouvez demander à votre application de se déconnecter de l'API une fois son exécution terminée pour invalider la clé.
#3
+23
goodguys_activate
2010-12-06 11:49:54 UTC
view on stackexchange narkive permalink

L'authentification de base sur HTTPS est bonne, mais elle n'est pas totalement sûre. De la même manière que Fiddler fonctionne pour le débogage SSL, un proxy HTTPS d'entreprise gère la connexion entre le navigateur Web et le proxy (dont l'adresse IP apparaît dans les journaux de votre serveur Web). Dans ce cas, le mot de passe HTTPS est décrypté, puis rechiffré au niveau du proxy d'entreprise.

Selon qui gère le proxy et comment ses journaux sont utilisés, cela peut être acceptable ou une mauvaise chose de votre point de vue.

Pour plus d'informations sur la façon dont l'interception SSL est effectuée , voir ce lien:

Lorsque le proxy SSL intercepte une connexion SSL, il présente un certificat de serveur émulé au navigateur client. Le navigateur client envoie une fenêtre contextuelle de sécurité à l'utilisateur final car le navigateur ne fait pas confiance à l'émetteur utilisé par ProxySG. Cette fenêtre contextuelle ne se produit pas si le certificat d'émetteur utilisé par SSL Proxy est importé en tant que racine de confiance dans le magasin de certificats du navigateur client.

Le ProxySG rend tous les certificats configurés disponibles pour téléchargement via sa console de gestion. Vous pouvez demander aux utilisateurs finaux de télécharger le certificat d'émetteur via Internet Explorer ou Firefox et de l'installer en tant qu'autorité de certification de confiance dans le navigateur de leur choix. Cela élimine la fenêtre contextuelle de certificat pour les certificats émulés ...

Certaines entreprises contournent le problème de la fenêtre contextuelle de certificat mentionné ci-dessus en déployant les certificats racine (du proxy) sur chaque poste de travail via GPO. Bien que cela n'affecte que les logiciels qui utilisent le magasin de certificats Microsoft. Les logiciels tels que Firefox doivent être mis à jour différemment.

En fait, cela dépend du site dont vous parlez. Par exemple. si vous naviguez vers votre banque depuis le travail et qu'ils utilisent l'authentification de base, cela n'est pas déchiffré par le proxy de votre travail. SSL passe par là.
Cela n'a aucun sens pour moi - à quel scénario pensez-vous? Les proxys ne peuvent pas voir ce qu'il y a à l'intérieur d'une session https, si le navigateur l'a configuré avec le point de terminaison réel, correctement authentifié avec un bon certificat (ou DNSSEC ou autre).
L'électeur négatif doit lire la documentation liée, car il s'agit d'un point réel et valide qui n'est pas largement connu. Documents: http://www.bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf
Ouais, vous avez raison - BlueCoat ressemble à un malware d'entreprise, utilisant FUD pour rendre l'entreprise non sécurisée.
Et btw - Chrome utilise le magasin de certificats Windows ...
Une âme bienveillante devrait voter pour cette réponse pour qu'elle ne soit plus (-1) Cette réponse contient des informations vraies et factuelles
@AViD, il existe certains cas où les proxys d'entreprise décrypteront en fait le trafic SSL en présentant leur propre certificat (qui est signé par un certificat d'entreprise interne importé en tant que certificat d'autorité racine de confiance sur tous les postes de travail de l'entreprise). Mon entreprise le fait pour quelques sites, y compris Gmail (mais pas pour les sites bancaires). Cela fonctionne, et est souvent invisible pour les utilisateurs car l'entreprise gère également les bureaux / navigateurs. Notez que Strict Transport Security (HSTS) peut vaincre cela ... c'est l'avertissement de firefox HSTS qui m'a alerté en premier lieu!
@MichaelLucas - oui, voir les commentaires précédents concernant BlueCoat (un logiciel malveillant populaire, erm, éditeur de logiciels dans cet espace). Comme je l'ai laissé entendre, il s'agit d'un anti-modèle, avec de nombreux inconvénients (par exemple, l'utilisateur n'a aucune indication sur les certificats de serveur invalides ou problématiques ... et c'est en plus des problèmes de confidentialité)
@MichaelLucas À ma connaissance, s'ils le font correctement, HSTS ne peut pas vaincre cela, pouvez-vous expliquer comment HSTS aborde ce problème? Je pense que vous remarquerez si vous jetez un coup d'œil à la chaîne Certficate dans votre navigateur et commencez à vous demander pourquoi votre entreprise est l'autorité de certification d'un site tiers. Si mon entreprise faisait cela, je me plaindrais!
@Nappy Peut-être qu'il s'agissait de [HPKP] (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) plutôt que HSTS?Cela pourrait certainement vaincre les méchants scanners d'entreprise.Sauf que Wikipédia déclare que la plupart des navigateurs désactivent HPKP vérifie les certificats avec des racines privées spécifiquement pour autoriser ces scanners.Tant pis...
Si l'entreprise fait des attaques MITM contre le trafic des employés, elle va à l'encontre de presque toutes les formes d'authentification, pas seulement de l'authentification de base.Donc, à moins que le serveur Web ne veuille utiliser quelque chose de plus complexe comme l'authentification à 2 facteurs, Basic est presque aussi sécurisé que toute autre forme d'authentification.
#4
+12
nealmcb
2012-07-14 07:04:17 UTC
view on stackexchange narkive permalink

Vous notez la nécessité d'authentifier le client et vous posez des questions sur la sécurité de l'authentification de base HTTP, via SSL. C'est pour cela que SSL a été conçu et fonctionnera bien tant que le mot de passe est bon. Si vous configurez vraiment cela pour un seul client, cela est facile à garantir en choisissant un long mot de passe aléatoire, par exemple. 12 caractères utilisant une bonne source d'aléatoire, ou d'autres techniques discutées sur ce site.

Votre client doit également s'assurer que vous avez le bon certificat pour le serveur. Dans la situation comme celle que vous décrivez, utiliser un certificat auto-signé comme décrit sur la page python ssl référencée sera très bien.

Si vous allez vous auto-signer, assurez-vous de communiquer les empreintes digitales SHA1 et MD5 du certificat afin qu'ils puissent vérifier sa légitimité lors de la connexion. Ou distribuer à l'avance, si possible.
L'utilisation de l'authentification de base HTTP pose un autre problème: le mot de passe complet est envoyé via le tunnel SSL. En d'autres termes, le mot de passe n'est pas haché avant d'être soumis, et pourrait donc éventuellement être capturé (bug dans le code de votre application, etc). Ce n'est généralement pas une préoccupation majeure (cela est vrai pour la plupart des mots de passe que vous soumettez via HTTPS, même dans les formulaires de connexion au site Web, et même dans le mot de passe SSH), mais cela vaut la peine d'être noté.
@ChrisKuehl N'y a-t-il pas de solides arguments contre le cryptage en javascript côté client? Est-ce ce que vous suggérez? Il me semble que TLS est à peu près aussi bon que je peux obtenir à part payer pour signer le certificat.
@StevenLu pas que je sache ou que je peux trouver rapidement, mais je serais intéressé à lire quoi que ce soit sur le sujet. Je ne vois aucun moyen de hacher quelque chose au préalable avant de l'envoyer côté serveur pourrait diminuer la sécurité, même si le côté serveur le hache davantage avant de le stocker. Je serais tenté d'utiliser [SSL / TLS auth] (http://goo.gl/xmzFI) à la place (les navigateurs modernes autorisent l'authentification bidirectionnelle avec des sites Web utilisant l'authentification par clé), en particulier pour une page qui n'est pas destinée à être consultée par des utilisateurs réguliers. Cela dépend beaucoup de votre cas d'utilisation, cependant, et est probablement difficile avec votre serveur Web Python.
Qu'en est-il de TLS dans TLS, je pense que 4 fois l'envelopper serait plus sûr que l'envelopper une fois. De cette façon, vous pouvez répartir les clés racine dans différents emplacements, donc si vous utilisez 4 entreprises pour le faire, il est probable qu'elles (ILS) n'auront pas la clé racine secrète, ou toutes.
Jetez un œil: http://www.matasano.com/articles/javascript-cryptography/
@StevenLu intéressant, mais manque le point; L'authentification TLS, [telle qu'implémentée dans les navigateurs] (http://www.browserauth.net/tls-client-authentication), n'implique pas JavaScript. C'est une fonctionnalité du navigateur lui-même. Il y a des problèmes qui le rendent inadapté à une utilisation avec l'authentification face à l'utilisateur, mais pour les développeurs / administrateurs, je pense qu'il y a un argument solide qui peut être fait pour cela.
@ChrisKuehl Donc, je suppose que je vais devoir creuser un peu plus pour trouver un moyen de configurer mon serveur pour faire une authentification client TLS complète?
@StevenLu,, votre configuration me semble correcte, mais tout dépend du niveau de sécurité souhaité. Jeter juste une idée supplémentaire :-).
L'authentification du serveur @ChrisKuehl TLS est certainement suffisante pour mes besoins et j'ai été agréablement surpris de découvrir la simplicité avec laquelle j'ai pu le mettre en place. Je me demande maintenant ce qu'il faudrait pour obtenir une authentification complète du client.
#5
+9
Steve
2010-12-06 04:59:26 UTC
view on stackexchange narkive permalink

Dépend entièrement de sa sécurité. L'authentification de base sur ssl enverra toujours les informations d'identification en texte brut, ce qui signifie que vous n'avez qu'une seule couche de protection.

Vous feriez mieux de hacher le mot de passe avec un nonce, ou mieux encore d'utiliser le modèle de revendications qui transmet l'autorisation à un tiers de confiance.

#6
+4
Weber
2010-12-06 06:25:50 UTC
view on stackexchange narkive permalink

De nombreux sites importants et populaires utilisent l'authentification de base (ou une autre basée sur des formulaires) sur HTTPS. Il obtient généralement un «soupir» de personnes soucieuses de leur sécurité. Pouvez-vous hacher le mot de passe côté client et envoyer le hachage à la place? Cela soulèverait un peu plus la barre.

Cela dit, c'est généralement considéré comme acceptable, à condition que votre page de destination hébergeant le formulaire de connexion soit également HTTP / S. Dans votre cas d'une API RESTful, vous n'avez probablement pas de page de destination, donc ça va. Si vous le pouvez, vérifiez votre application avec des outils de sécurité gratuits tels que Watcher et Skipfish.

seul un défi-réponse avec hachage est une mise à niveau de la sécurité, sinon l'attaquant peut simplement fouiner le hachage et toujours y accéder lorsque la session expire
#7
+4
Luc
2012-07-15 05:47:41 UTC
view on stackexchange narkive permalink

Je l'utilise moi-même pour beaucoup de choses, et tant que vous n'ignorez aucun avertissement TLS du navigateur, vous devriez être bon.

TLS fonctionne sous HTTP, donc toutes les données transmises via HTTP sera crypté. Ce sera aussi sûr que d'envoyer n'importe quel formulaire de mot de passe.

Au lieu d'utiliser un certificat auto-signé, je suggérerais d'utiliser Let's Encrypt. Ils fournissent des certificats gratuits et sont approuvés par Microsoft, Mozilla, etc., et ne donnent donc pas d'avertissement TLS dans le navigateur. Je pense qu'il vaut mieux utiliser ceci au lieu d'un certificat auto-signé; si jamais vous voyez une erreur TLS, vous savez qu'elle est réelle et pas seulement parce que votre certificat est auto-signé.

Je ferais certainement quelque chose comme ça, surtout si c'est gratuit. Les erreurs "certificat invalide" sont assez criantes.
Oui, StartSSL est vraiment une sorte de solution homebrew, mais elle a la confiance des grandes parties, donc je suppose que c'est bien tant que vous ne sécurisez pas quelque chose qui vaut des millions. Tout vaut mieux qu'un certificat auto-signé. La façon de sécuriser l'auto-signature consiste à vérifier l'empreinte digitale, mais vous pouvez toujours le faire en utilisant (par exemple) StartSSL.
J'héberge mon contenu sécurisé sur un serveur différent de celui sur lequel je peux définir le domaine cible pour un certificat (à émettre par StartSSL). C'est parce que je ne paie pas pour un VPS avec une IP statique, j'utilise le service No-IP pour me rediriger vers mon IP. Est-il possible pour moi d'obtenir une clé / un certificat qui me permettra d'ouvrir mon site de n'importe où sans qu'il montre des erreurs de certificat invalides?
Il me semble donc clair qu'avec une adresse IP dynamique, il n'y a absolument aucun moyen de configurer un certificat SSL approprié. D'accord, je suppose que je suis coincé avec l'erreur du navigateur alors (à moins que je ne fasse une sorte de configuration de proxy).
Mise à jour: StartSSL a fermé ses portes.Votre prochaine meilleure option est Let's Encrypt.
Merci @starbeamrainbowlabs!J'ai mis à jour la réponse.
#8
+2
lightxx
2015-03-06 17:32:02 UTC
view on stackexchange narkive permalink

Un autre argument non mentionné (je suppose) jusqu'à présent est le fait que de nombreux appareils mobiles tels que les téléphones intelligents ne permettent pas à l'utilisateur de vérifier le certificat lors de l'authentification de base via HTTPS dans le navigateur. Cela signifie que contrairement à l'authentification basée sur les formulaires, vous ne pouvez pas contourner la fenêtre contextuelle d'authentification de base qui est une boîte de dialogue modale sur la plupart des plates-formes mobiles pour vérifier le certificat avant de saisir vos informations d'identification. Cela peut présenter un risque lorsqu'un attaquant utilise un certificat valide.

#9
+1
Daniel Szpisjak
2019-02-05 13:05:44 UTC
view on stackexchange narkive permalink

Voici un peu plus de contexte pour l'histoire. Tout comme d'autres ont dit que l'authentification de base sur TLS fonctionne bien si vous pouvez vivre avec quelques limitations.

Utilisé du côté client , vous devez probablement gérer la gestion de session, ce qui est assez difficile avec l'authentification de base.

Sur le backend , l'authentification de base fonctionne bien mais repose entièrement sur TLS pour la confidentialité et l'intégrité. Il est similaire à l'authentification basée sur un jeton. Si vous avez besoin de quelque chose de plus sonore, pensez à utiliser des schémas de signature ou une authentification du client TLS.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...