Si vous utilisez l'authentification SQL Server (2005), les informations de connexion sont-elles envoyées dans Effacer le texte via le fil?
6 Réponses :
Les informations d'identification sont envoyées en texte clair.
Vous pouvez probablement trouver un certain nombre de sources pour cela, mais Voici un :
"Sécurisez le canal entre le serveur Web et le serveur de base de données car les informations d'identification sont transmises dans un format non crypté. Par exemple, utilisez SSL ou IPSec."
Fait intéressant, c'est la publication que j'ai trouvée qui me conduise à poser ma question. Il semble également de contraire directement cet autre message MSDN: msdn.microsoft.com/fr -us / bibliothèque / ms189067.aspx
Donc, soit le guide Meilleur pratique ASP.NET est faux ou le cryptage SQL Server 2005 Connections Article MSDN est faux ....
Voici un lien vers un Sécurité Meilleures pratiques pour SQL 2005. Que Doc stipule en partie:
en mode d'authentification Windows, Utilisateur de Windows spécifique et groupe Les comptes sont convaincues pour se connecter à SQL Serveur. Les informations d'identification Windows sont utilisées Dans le processus; c'est-à-dire soit NTLM ou des informations d'identification de Kerberos. les fenêtres comptes utilisent une série de cryptage Messages à authentifier à SQL Serveur; Aucun mot de passe n'est passé sur le réseau lors de l'authentification traiter.
Lorsque les connexions SQL sont utilisées, les mots de passe de connexion SQL sont transmis sur le réseau pour l'authentification. Ceci fait connaître les connexions SQL moins sécurisées que les connexions de Windows.
Think Noel demandait à propos de SQL Server Auth, pas d'auth-windows
Tout va bien, merci. Fixé. Dans d'autres nouvelles, les gens utilisent toujours le mode mixte? :)
Et il est difficile d'utiliser Windows Auth lorsque le client est Service réseau ou d'un autre compte à bas prix privilégié ...
Ce doc est également ambigu. «Lorsque les connexions SQL sont utilisées, les mots de passe de connexion SQL sont transmis sur le réseau d'authentification», mais dans le protocole Secure ou via un protocole Secure CommS? De plus, il existe des améliorations de sécurité pour les connexions SQL dans SQL Server 2005 ... Ces améliorations incluent ... Meilleur cryptage lorsque les mots de passe SQL sont passés sur le réseau '
Et Foully 'SQL Server 2005 peut utiliser un canal crypté pour deux raisons: pour chiffrer les informations d'identification pour les connexions SQL'. Ou ça fait !!!!!
"L'autre raison de l'utilisation de SSL consiste à chiffrer les informations d'identification pendant le processus de connexion des connexions SQL lorsqu'un mot de passe est transmis sur le réseau." Cependant, ce document implique que tout cela est facultatif plutôt que par défaut.
aussi sécurisé que vous voulez le faire ...
Vous pouvez configurer SSL assez facilement, et si vous n'avez pas de certificat de confiance, si vous forcez le cryptage, SQL Server peut créer / émettre son propre certificat auto-signé pour votre utilisation ... de cette écriture
Critiques (dans le paquet de connexion) qui sont transmis quand un client L'application se connecte à SQL Server est toujours crypté. SQL Server utilisera Un certificat d'une confiance Autorité de certification si disponible. Si un certificat de confiance n'est pas installé, SQL Server générera un certificat auto-signé lorsque le l'instance est lancée et utilisez le certificat auto-signé pour chiffrer le crédits. Ce auto-signé Le certificat aide à augmenter la sécurité mais cela ne fournit pas de protection contre l'identité de l'identité par le serveur. Si le certificat auto-signé est utilisé et la valeur de la L'option de forcinecryption est définie sur Oui, Toutes les données transmises sur un réseau entre SQL Server et le client L'application sera cryptée en utilisant Le certificat auto-signé
D'accord, mais tous ces efforts de cryptage éliminent l'avantage de la performance de l'utilisation de l'authentification SQL. Mais alors, tout le monde n'a pas le choix d'utiliser l'authentification Windows.
C'est le compromis classique, n'est-ce pas, la performance par rapport à la sécurité?
Toujours pas sûr à 100% que les informations d'identification SQL sont toujours envoyées de manière sécurisée, mais je pense que votre lien est à peu près aussi clair que la SEP l'a fait. «Critiques d'identification (dans le paquet de connexion) qui sont transmises lorsqu'une application client se connecte à SQL Server sont toujours cryptées», mais compte tenu de cette phrase, provient à mi-chemin de la section AA pour la configuration SQL pour utiliser SSL, il est toujours légèrement ambigu (ou peut-être que je suis Être trop prudent!)
@NOELKENNEDY, vous avez raison d'être prudent! TDS (le protocole utilisé entre client et SQL Server) prend en charge les connexions entièrement non cryptées - voir la rubrique cryptage sur MS-TDS 2.2.6.5 Prelogin . Je suppose que les connexions non cryptées sont rares. Cependant, ils sont possibles. J'en ai utilisé avec succès dans un environnement de test lorsque vous testez le code de niveau pilote contre SQL Server 2016.
Outre le fait que les mots de passe sont envoyés en texte clair, il est également possible de remplacer le hachage du mot de passe.
lire ce fil m'a fait encore plus confondre alors j'étais!
Quoi qu'il en soit, j'ai fait des tests avec Wireshark, avec ou sans connexion cryptée Peut-être que c'est le manque de connaissances avec Wireshark pour récupérer les informations d'identification de la connexion, mais comme je pouvais tout pouvoir voir tout ce que je suis à peu près sûr que je regardais le bon endroit et que le mot de passe était toujours caché.
TDS (le protocole utilisé pour les communications client-SQL Server) a un état de cryptage entre complètement crypté et entièrement non crypté, où le premier paquet de la demande de connexion est crypté. Cet état est utilisé lorsque le cryptage est pris en charge mais non requis. Je me demande si le test que vous avez utilisé cet état de cryptage - qui expliquerait pourquoi vous ne pouviez pas voir le nom d'utilisateur et le mot de passe.
Wow, c'était il y a longtemps ... Je ne me souviens pas quelles étaient les configurations, mais je doute que j'ai changé de quoi que ce soit des valeurs par défaut. Seule une chose que je peux penser à attacher un certificat à l'instance.
Je soupçonne que vous n'aviez pas pu identifier votre mot de passe car il est codé en fonction du protocole de flux de données tabulaire (MS-TDS) utilisé pour la communication client avec le client. La procédure de connexion de TDS et de son codage sont détaillées ici: MSDN.MicRosoft.com/ EN-US / Bibliothèque / DD304019.aspx
Si les informations d'identification de connexion sont cryptées ou non dépendent de la capacité de cryptage / de la configuration du client et du serveur.
clients communiquent avec Microsoft SQL Server à l'aide du flux de données tabulaire (TDS) < / a> protocole.
Peu de temps après qu'un client ouvre une connexion TDS sur le serveur, elle informe le serveur de sa capacité de cryptage. Le serveur compare cette annonce avec sa propre configuration / fonctionnalité pour déterminer l'état de cryptage pour la connexion.
En un mot, l'état de cryptage est déterminé comme suit:
Le seul moyen de vous assurer que les demandes de connexion sont Toujours cryptées consiste à définir l'option "Exiger du cryptage" sur le client ou le serveur. Il n'y a aucune option pour interdire les connexions complètement non cryptées sans nécessiter de cryptage complet.
Peu importe si la connexion ou la connexion est cryptée ou non, le mot de passe d'authentification SQL est toujours obscurci mais le brouillage est facilement réversible.
Détails
En plus de lecture:
Merci tout, je suis maintenant sûr que les informations d'identification de connexion sont transmises en cas de hachage, sur SSL. Cependant, il existe un degré d'ambiguïté et même de contradiction dans la documentation de la SP que vous avez découverte. J'ai commenté cela sur vos réponses et j'ai voté le cas échéant.