Bonsoir,
Existe-t-il des automatismes pour que les données stockées dans une  BD sous SQL Server 2k soient cryptées avec le principe des clés privées/clés publiques?
(bien sur j'ai cherché dans la doc de SQL Server mais je n'ai trouvé que le cryptage SSL pour le transfert des données... Je débute en SQL Server)
 
Si c'est impossible, comment faire alors: crypter/décrypter à partir du PHP/ASP qui interface la base de données
 
 
edit: passage en cat ASP

pas à ma connaissance.  
 
comment veux-tu pas la suite faire une recherche sur des éléments par la suite?  
 
il faut juste donner des droits aux users sur les tables/champs...

"comment veux-tu pas la suite faire une recherche sur des éléments par la suite?  "
 
mince, c vrai ca
bon à la limite je peux laisser les clés intactes, et crypter les données sensibles.
Dans ce cas, il me semble que c'est à ASP de crypter les infos au cas par cas; ca doit bien être possible en utilisant un système asymétrique (clés publiques/privées) puisque ASP a des fonctions de lecture de certificat

ben les fonctions de certificat ça concerne plus la communication entre client et serveur. Le cryptage de données va impliquer des temps de traitement plus longs aussi. Et la bonne solution consisterait plutôt à sécuriser l'accès à SQL Server plutôt qu'à crypter les données.

pour sécuriser l'accès, je compte accorder des droits selon la personne qui se loggue en début de session ASP, que faire d'autre
mais le client vaut aussi que les données soient cryptées (elle sont sensibles), et j'ai du mal à voir concrètement à quel niveau utiliser les clés

oui mais alors seulement les données TRES sensible. de toute façon, si l'accès est sécurisé ça suffit... c'est quoi comme données ultra sensible ?

des signatures electroniques & autre, dans un domaine très surveillé.
bon je vais chercher des fonctions pour crypter en RSA avec ASP

Un petit lien qui pourra peut-etre te rendre service:
http://www.jura.ch/lcp/cours/dm/codage/index.html
 
C'est du javascript, mais tu dois pouvoir transformer ça en Vbscript. Bon courrage

ca a l'air intéressant, merci

Un autre pour la route. Cette fois en ASP:
http://www.weboconcept.com/cours_l [...] ubrique=20

là c'est du cryptage symétrique, mais ca devrait m'aider pour l'asp, merci
 
par contre je suis en train de me poser qques questions.
je vais avoir une BD avec certains champs cryptés.
mais il y a plusieurs utilisateurs, et la valeur des champs reste la même pour tous bien sur.
 
et là, c'est le drame: soit les champs etaient cryptés à l'attention d'un certain type d'utilisateur, avec leur clé publique, mais alors ils sont plusieurs à partager une meme clé privée >> pb! une clé privée, ca ne se transmet pas.
 
soit ils sont cryptés avec la clé privée du serveur, et là tout utilisateur peut le décrypter avec la clé publique du serveur, puisque le but n'est alors que d'authentifier l'émetteur.
 
   
 
(en clair: je suis en train de me dire que le cryptage asymétrique n'est pas du tout adapté à du stockage dans base de données. le cryptage symétrique c'est faisable en mettant les transformations dans le code de l'ASP, mais asymétrique, je vois pas.)

up pour le probleme ci-dessus...

Mmmm... Alors, plusieurs choses.
 
1) Si les données doivent être cryptées, je suppose que c'est parceque le client a peur de se faire pirater. Je suis en général le premier à dire que les produits M$ sont pas si pourris que ça à la base, mais IIS est reconnu comme étant un des serveurs webs les moins sûrs du marché. Ainsi, à moins de sécuriser un max, avec une batterie de protection, et un déploiement extrêment minutieux, vous vous exposez grandement à des trous de sécurités, dont le plus grave, c'est qu'ils sont très vite connus et longtemps applicables (M$ corrige trop lentement les trous connus, ce qui fait qu'un pirate à largement le temps de l'utiliser pour une attaque avant que le correctif soit sorti)
 
2) Crypter la base de données en elle-même me semble, à défaut d'être une ânerie, complètement superflu, et dramatique pour ce qui est des performances... et même de la sécurité !
En effet :
a) Quelque soit le système d'encryption utilisé, à partir du moment où une personne mal intensionnée à réussi à intercepter ces données, c'est qu'elle est relativement bien équipée. A partir de là, tu peux être sûr qu'il ne lui faudra que quelques heures pour décrypter les données.
b) L'ASP est un langage de script interprété. Ainsi, il a des performances extrêment faibles. Si tu lui demandes de faire tourner des algorythmes complexes d'encryption/décryption, tu vas avoir des temps de réponse extrêment lents, et mettre le serveur à genoux.
c) Plus un code est complexe, et plus la probabilité de bugs est grande. Et plus la charge du serveur est élevée, et plus l'ampleur et la fréquence de ces bugs est grande. Ainsi, à vouloir complexifier le code en cryptant tout, tu risques d'augmenter les failles de tes algos, et ainsi ouvrir la porte à des personnes mal intentionnées.
 
3) Windows, SQL Server, et les différents outils réseau qui existent (pare-feu, zone démilitarisée, SSL, etc.) permettent de sécuriser de façon très sûre et très fiable l'accès à un serveur, quelquesoit sa nature. Ainsi, tu peux communiquer entre le serveur SQL et IIS en utilisant des systèmes de cryptage complexes (avec clés changeant réguilièrement, ce qui rend surranné au bout de quelques minutes le travail d'un hacker qui tente de cracker ta clé). Tu peux aussi empêcher toute connection n'émanant pas d'une IP précise. Tu peux aussi interdire tout accès direct aux données, en passant par des procédures stockées, qui peuvent se charger d'effectuer d'ultimes vérifications avant de retourner des données. (validation auprès d'une table de droits que l'utilisateur à le droit de lire les informations qu'il demande, au niveau applicatif). Ce sont autant de systèmes qui font leurs preuves tous les jours.
Ensuite, de la même façon, tu peux protéger ton serveur IIS, en n'acceptant que des connections authentifiées avec les logins NT du serveur, avec un cryptage SSL, voir d'autres cryptages spécifiques à l'OS. Deplus, IIS peut être configuré pour ne répondre qu'à des IP bien spécifiques (si c'est un serveur "public" destiné à un nombre restreints d'utilisateurs bénéficiants d'une IP fixe, c'est parfait). Il y a tout un tas d'autre systèmes permettant de sécuriser un max l'accès au serveur, et le fiabliser.
 
Ci-joint deux White Papers provenant du site  de Microsoft :
 
http://magicbuzz.wanadoo.fr/Window [...] _Guide.zip (2,301 Mo)
http://magicbuzz.wanadoo.fr/Deploy [...] S)_6.0.zip (8,661 Mo)
 
Je n'ai pas trouvé le document pour SQL Server, mais je ne l'ai pas cherché non plus (désolé, c'est celui qui t'aurait certainement le plus intéressé )
Ces documents sont très sérieux, je pense que tu y trouveras beaucoup d'informations succeptibles de rassurer ton client.
 
PS: les fichiers sont gros, attends une petite demi-heure avant de les télécharger... Upload en cours

Ci-dessous quelques url :
 
Recence tous les bulletins de sécurité émis par Microsoft. Tu peux t'abonner au mailer, afin de les recevoir au fur et à mesure. Très important pour garantir au jour le jour la sécurité d'un serveur.
http://www.microsoft.com/security/security_bulletins/
 
Sécurité de SQL Server. Une chiée d'articles permettant de garantir une sécurité optimale.
http://www.microsoft.com/technet/t [...] efault.asp
 
Home page de la section sécurité de Microsoft. Une mine d'informations à la fois de très bon niveau et accessible.
http://www.microsoft.com/security
 
Section sécurité dédiée aux développeurs :
http://msdn.microsoft.com/security/
 
Section sécurité dédiée aux architectes réseau/logiciel
http://www.microsoft.com/technet/t [...] efault.asp

ouah, j'ai de la lecture!
merci beaucoup pour le temps que tu as dû passer à taper tout ca et à retrouver les liens
 
je suis plutôt d'accord avec tout ce que tu dis, excépté ca:

des données cryptées par RSA (ou SSL qui utilise le même principe et dont tu parles ensuite justement) peuvent être, comme pour tout échange, interceptées, mais les décoder c'est carrément impossible, en une vie en tout cas.
 
Par contre pour le problème de performances tu as sûrement raison (remarque je pourrais toujours encrypter en javascript ^^), et sur le fond je suis complètement d'accord; si j'essaie de voir toutes les possibilités de sécurisation c'est parce que l'application web devra être validée par la FDA (US Food & Drug Administration), norme CFR21 part 11, et le client avait donc mis ca dans les specs.
Avec tous ces liens, j'espère sinon le convaincre lui que le cryptage de toute la base n'est pas envisageable, au moins convaincre mon boss.
Encore merci
 
edit: magicbuzz.wanadoo.fr est introuvable pour mon navigateur (perso.wanadoo.fr/magicbuzz et magicbuzz.free.fr aussi, a tout hasard), les docs ne sont pas dispos sur internet par chance?

Argh, désolé. La base de l'url c'est :
 
http://perso.wanadoo.fr/magicbuzz/
 
Sinon, pour ce qui est de l'encryption, que ce soit SSL ou autre, je ne suis pas d'accord.
 
SSL a en effet la réputation d'être quasi inviolable (ce qui n'est pas tout à fait vrai, puisqu'il y a un petit moment déjà, une famille d'algo utilisés par SSL à trouvé sont maître, un petit programme capable de retrouver la clé en moins de 5 minutes) parceque la méthode d'encryption change en fonction du temps. En effet, le SSL sert à transporter des données. Ainsi, la clé elle-même (je ne parle pas du certificat) évolue avec le temps, rendant ainsi différente la forme d'une même donnée en fonction du temps.
 
Mais pour ce qui est d'une base de données, c'est du stockage. Ainsi, l'encryption restera figée. Il existe un tas d'algo, basés à la fois sur le brute-force et l'apprentissage, qui permettent de craquer petit à petit une clé. Il s'agit au départ de faire un brute-force, ce qui est très lent. Mais ensuite, une fois qu'un certain nombre d'informations sont décodées, l'algo évolue, et restreint ses tentatives de brute-force, en tentant de déduire petit à petit la clé. Evidement, ce n'est pas rapide. Mais à l'image des outils qu'on trouve un peu partout pour cracker une base SAM des mots de pass de Windows (pourtant c'est un algo très sûr qui est utilisé pour ce fichier, du moins sous Windows 2K et +, quand on respecte les critères de sécurité), on peut craquer ça en quelques heures/minutes.
 
Je me suis amusé à un moment à "bencher" mon PC en crackant justement ma base SAM.
 
J'ai créé 20 mots de pass de 30 caractères, avec des caractères étendus et tout. Le soft les a cracké en moins de 10 jours.
Associé à un algo d'apprentissage, la vitesse de résolution aurait été de plus en plus rapide avec le temps, jusqu'à ce qu'elle se fasse instantanément.
 
Et moi je suis 100% amateur. C'est des outils à deux balle trouvés en tapant "crack sam password" dans google. Un "vrai" hackeur capable de passer à travers un firewall et pirater une machine qui a été un minimum sécurisée (je parle pas du Windows XP du premier pékin venu), il aura à la fois les softs et les connaissances nécessaires pour obtenir de très largement meilleurs résultats.
 
Donc certes, "quelques heures" dans mon post, c'est un peu éxagéré, mais très clairement, ça reste tout à fait possible, et dans des délais bien plus courts que tu n'imagines (à condition que la clé reste la même au fil du temps, ce qui est forcément le cas avec un stockage en base de données).
 
Pour information, actuellement, la seule librairie que j'avais trouvé en ASP pour encrypter des données (pour un password) c'était SHA256. Cet algo est réputé pour être assez bon. (à la fois performant, et long à cracker).
Je te laisse imaginer ma surprise quand j'ai découvert que dans le SDK .NET, il y avait de base une fonction SHA1024 pour remplacer l'algo 256. Il y a forcément une raison. Le 256 était fiable à l'époque des 486. Maintenant, avec des PC plusieurs milliers de fois plus rapide... Bah faut des algo plusieurs millions de fois plus complexes pour espérer se protéger un minimum La seul véritable chose "sûre", je le rappelle, c'est les clés qui évoluent, mais c'est restreint aux transmissions, pas au stockage malheureusement.
 
Donc la meilleure protection reste le "coffre-fort", c'est à dire sécuriser un maximum les accès, afin de ne pas avoir à brouiller les pistes une fois qu'un intrus est rentré. Mieu vaut prévenir que guérir en somme

   
Je pensais pas que c'était possible, c'est étonnant quand même qu'on puisse les cracker si vite.
SHA-1, c ce avec quoi je pense hasher les mots de passe. De toutes façons c'est soit ca, soit MD5, et apparemment la confiance est plus grande envers SHA-1.
Je vais me renseigner sur SSL et l'appel à un tiers de confiance "authentificateur".
Merci d'avoir partagé ton expérience

Juste une précision : pour le crackage des mots de pass windows, c'est dans la théorie impossible, puisque pour cracker comme je l'ai fait, il faut que le logiciel accède à la base SAM qui contient les mots de pass crypté.
Ce fichier est totalement inaccessible depuis l'extérieur. Ainsi, il faut que le logiciel tourne sur la machine, ou que l'individu ait réussi à accéder au fichier en prenant le contrôle du système de fichiers de l'ordinateur.
S'il n'y parvient pas, la protection basique qui consiste à verrouiller le compte au bout de 3 tentatives infructueuses est la meilleur parade, puisque ça réuduit considérablement la vitesse du brute force.
 
En effet, le soft que j'ai utilisé testait environ 1.5 Go de caractères par seconde. Avec une protection de lock d'une heure du compte, on tombe à 90 o/heure, c'est donc un peu moins rapide
 
Le problème sera le même avec la base de données. Le premier truc que va tenter un hacker, c'est  d'accéder aux fichiers de la base afin de les récupérer et les cracker depuis chez lui, pas à travers le réseau.