The Web-site of design Company Chelyabenergoproekt in English   English
Maison Écrire le courrier Carte
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




       

Projets de maîtrise intellectuelle!
Nos Nouvelles
22.12.2016 Bonne année!
Bonne année! Administration ...
30.12.2015 Bonne année!
Bonne année! Administration ...
21.12.2015 Energie heureux!
Energie heureux! Administration ...



Nouvelles CAD
Caractéristiques de sécurité pour la communication entre les travaux du projet dans l'environnement Internet
Aujourd'hui la multitude de services Internet coopèrent l'un avec l'autre dans Internet. La classe spéciale des coopérations ceux-là, à qui se réalise la transmission de l'information confidentielle (les données personnelles, les messages confidentiels) ou les commandes, l'exécution de qui doit être absolument validée par quelqu'un (par exemple, le virement ou la publication du message d'un nom de quelqu'un). Il est évident que les services semblables doivent être de façon certaine protégés contre les malfaiteurs.

Malheureusement, non tous les architectes réfléchissent au degré de la sécurité des applications. Le problème s'aggrave un peu par ce que plusieurs représentants du business électronique élaborent les protocoles, que, étant réalisé aux services finaux, peuvent créer sérieux à la vulnérabilité, si les utiliser sans compréhension nécessaire.

L'objectif de l'article donné décrire brièvement les types possibles des attaques à inter-projet (i.e. le serveur-serveur) la coopération et le moyen de défense d'eux pour utiliser plus avec pénétration les protocoles prêts et élaborer. On examine préalablement les bases de la sécurité d'information, puisque souvent les connaissances des architectes finaux arrivent dans ce domaine un peu fragmentaire.

La sécurité (ou l'absence de la sécurité) de divers types des attaques est présentée à l'exemple des protocoles des systèmes populaires aujourd'hui: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa et PayPal (les systèmes de paiement), ainsi qu'OpenID, OpenAuth, OAuth (décentralisé authentification).

Nous examinerons la notion de la coopération sûre.

Donc, nous serons défini que nous sous-entendons par les mots la coopération sûre:
1. Authentification. Que le serveur Mais veuille transmettre le message au serveur. Devrait avoir la possibilité de contrôler que le message est expédié notamment de Mais. La vérification donnée s'appelle authentification du serveur Mais sur le serveur B
2. Lintégrité des données. Nous voulons être assurés que le message à la transmission n'était pas changé (par exemple, était payé 50$, mais la confirmation est reçue sur 500$).
3. La confidentialité de la coopération. Le point donné sous-entend que le message est reçu seulement par ces parties, qui ont droit à cela. En général, le point donné sous-entend La cryptographie Les informations à la transmission. On peut examiner dans certains cas encore deux points: la vérification des droits d'accès et l'impossibilité du refus de la paternité (non-repudiation), mais maintenant nous laisserons cela de côté.

Pour la considération des primitifs cryptographiques Les intéressés peuvent passer selon les références à Wikipedia et apprendre les détails.

Nous examinerons les manques SSL/TLS et HTTPS.

Cela ne nous arrange pas toujours SSL/TLS:
- La complexité de la vérification de l'authenticité du serveur arbitraire dans le code de l'application. Par voie de conséquence l'utilisation partielle du protocole, sans sécurité contre l'attaque La personne au milieu.
- Unilatéral authentification (oui, il y a des modifications du protocole pour bilatéral, mais c'est utilisé moins souvent, et non pour tous les langages de programmation il est facile de trouver la décision prête).
- En outre l'architecture SSL/TLS ne permet pas d'enregistrer le message avec la signature digitale de l'expéditeur pour plus tard utiliser cela pour cette preuve que le message était expédié en effet par l'auteur (i.e. la sécurité contre le refus contre la paternité ne travaille pas).

Nous examinerons limplémentation de la sécurité pratiquement:
1. Pour authentification utilisent d'habitude ou la vapeur connexion le mot de passe ou la signature digitale générée par n'importe quelle méthode.
2. Pour la vérification les intégrités des données utilisent SSL/TLS et les signatures digitales formées par l'application.
3. Pour les cryptographies des données, c'est-à-dire les supports de la confidentialité la plupart des systèmes utilisent SSL/TLS (il y a des exemples de la cryptographie indépendante des clés, cependant les données chiffrent par les méthodes relativement rarement).

En disant sur les services Web, le plus souvent SSL/TLS utilisent en forme de HTTPS.

Nous examinerons les types des applications protégées.

Avant que, enfin, passer aux attaques contre les protocoles, il est nécessaire de dire sur les bornages, à qui le système projeté travaille. Il est nécessaire de mentionner trois principal comme les applications, pour qui on peut examiner les questions de la coopération sûre:
1. Deux parties coopérant ont la possibilité d'avance d'échanger selon le fossé de manière garantie protégé l'information nécessaire: par la clé totale, les certificats, les mots de passe etc. Un tel fossé peut être la transmission de l'information nécessaire entre les gens (le mieux), la voie de communication alternative (le lien cellulaire, le téléphone) ou même Internet si les deux parties sont assurées de l'absence La personne au milieu ou un autre moyen de l'interception ou la modification du message.
2. Larchitecture centralisée. Chaque deux parties n'ont pas la possibilité de se mettre d'accord l'un avec l'autre d'avance, mais n'importe quel participant du réseau croit à un certain tiers, qui signe les certificats des parties coopérant et les garantit validité. On peut appeler À titre d'exemple l'infrastructure des clés ouvertes (Public Key Infrastructure, PKI) ou, sous certaines clauses, le même Internet, dans qui les browsers croient au nombre fini des centers de certification (CA), et à la base de cela peuvent se persuader qu'ils coopèrent avec le site nécessaire.
3. Larchitecture décentralisée. Dans les applications semblables il n'y a pas de tiers commun. Il est important de comprendre que des architectures semblables l'objectif principal se persuader qu'à une deuxième fois la même personne que venait auparavant est venue à vous. C'est-à-dire, pour la première fois vous permettez de passer authentification à qui on désire (par exemple, sur les sites supportant OpenID, chacun peut passer authentification). Qu'ensuite vous fassiez quelque dépôt dans le système: par exemple, ont écrit le message. Quand vous viendrez ici une fois suivante, le site devra vous accorder (et seulement) l'accès à l'édition de ce message. Les exemples des protocoles: OpenID, OAuth, les protocoles Peer-to-Peer.

Nous examinerons les attaques et les moyens de la sécurité.

1. L'absence de la vérification de la paternité ou l'authenticité du message.

Je permettrai de me rappeler une vieille plaisanterie. Dans la programmation existe deux types des bogues: l'absence de la vérification des données d'entrée et toutes les autres bogues.

Si à vous le message M de la partie Mais, il faut se persuader qu'est venu: le message est venu en effet de Mais; que Mais envoyait notamment le message M, et il n'était pas changé en passant.

L'exemple du protocole avec fautes créé est le protocole de la coopération du système de paiement Assist avec le magasin en ligne. Après le paiement de l'achat sur le serveur d'Assista, l'utilisateur revient à une certaine adresse URL_RETURN_OK, qui est transmise dans l'aspect ouvert et peut être modifié par l'utilisateur-acheteur lui-même. C'est-à-dire, l'utilisateur revient après le paiement de l'achat à notre magasin en ligne, lui disent: Merci, vous avez payé tout à l'heure le paiement sur la somme 1000$ mais le magasin n'a pas d'absolument aucune possibilité de se persuader que c'est vrai. Seulement plus tard, les mains du manager ou est automatisé (mais non plus souvent 1 fois à 10 minutes!) on peut contrôler que le paiement a passé en effet. Le protocole d'Assista, à propos, n'était pas modifié déjà plus de 4 ans. Mais tout il faut ajouter la signature digitale.

Donc, comment réalisent la vérification de la paternité et l'intégrité du message.
- Utilisent les signatures digitales sur la base d'une paire de la clé confidentielle et ouverte. Probablement, c'est le plus sûr et universel (i.e. travaillant à n'importe quelles conditions) le moyen. La clé ouverte peut être transmise au pays d'accueil d'avance (le moyen semblable utilisent aujourd'hui WebMoney, Cyberplat, OAuth et plusieurs autres). Aussi la clé ouverte peut être reçue plus tard selon la composition non protégée et est contrôlé à l'aide du certificat du center de certification (Certification Authority, CA). Ce moyen est à la base du fonctionnement de l'infrastructure des clés ouvertes (Public Key Infrastructure, PKI), utilisé à de grandes compagnies.
- Forment la clé totale Vers par exemple, à la base du protocole Diffie-Hellman ou analogue et l'utilisent pour signature des messages (par exemple, avec l'utilisation HMAC-SHA1). Est utilisé à OpenID.
- Si à nous n'est pas importante l'intégrité du message, mais la confirmation de la paternité est importante seulement, parfois utilisent une paire connexion- le mot de passe ou la ligne confidentielle pour l'accès à la ressource protégée. Par exemple, Flickr rend la photo selon le protocole XML-RPC en réponse à la requête contenant connexion et le mot de passe. Le système reCAPTCHA permet de contrôler le CAPTCHA-code introduit par l'utilisateur, authentification contrôlant selon la ligne confidentielle. Il faut comprendre que ce moyen, bien que soit simple, extrêmement par ce que l'interception du message découvre votre mot de passe, et par la suite le malfaiteur peut librement expédier les requêtes en votre nom. En cas de l'utilisation de la signature digitale l'interception du message ne permettra rien de faire au malfaiteur.
- Est plus simple (bien que non protégé des attaques de la substitution du serveur et La personne au milieu) le moyen de la vérification de l'authenticité du message. Par exemple, PayPal dans le protocole Instant Payment Notification (IPN) oblige chez le serveur acceptant la confirmation sur le paiement passé, expédier la copie du message à l'inverse sur le serveur avec la question si en effet tu m'envoyais cela ? Le moyen analogue est utilisé dans le protocole OpenID (à vrai dire, au travail en mode non recommandé), seulement on envoie à l'inverse non simplement le message, mais le message avec la signature digitale, et la requête a l'air déjà comme contrôle, si tu mettais cette signature digitale. Le schéma semblable travaille et à OpenAuth. On peut trouver comme l'avantage de l'approche l'absence de la nécessité de réaliser les algorithmes cryptographiques avec un ou de deux parties.
- Robokassa a inventé le moyen original de la formation de la signature digitale: la signature digitale est formée comme la fonction hash MD5 du message et le mot de passe confidentiel. Il faut traiter avec prudence le moyen donné quand même parce que le mot de passe doit être assez sûr. Si le mot de passe court, et, surtout, s'il sort par la personne, le déchiffrement de votre mot de passe peut se trouver l'objectif simple pour le pirate.

2. Espoir de la sécurité HTTPS.

Comme était indiqué ci-dessus, la réalisation dans le cadre de l'HTTPS-procès-verbal authentification du serveur arbitraire, à qui on connecte votre application, l'objectif assez complexe. Plus haut nous examinions les détails, la sortie brève desquels est simple: sans vérification de l'authenticité du certificat du serveur le sens HTTPS peut être réduit au zéro. Aucun des protocoles décentralisé authentification que ce soit OpenID, OpenAuth, OAuth, n'est pas protégé contre l'attaque de la substitution du serveur ou La personne au milieu. Dans certains cas on peut attaquer les systèmes de paiement (PayPal, Assist) par le moyen semblable. Au total, vous pouvez persuader l'application du magasin en ligne qu'il y avait un paiement, bien qu'en fait elle ne soit pas.

Nous soulignerons encore une fois que l'on peut se défendre de cette attaque, si le serveur établissant l'HTTPS-liaison possède la quantité suffisante des certificats des essentiels CA de l'Internet (VeriSign, COMODO etc.), mais pratiquement c'est difficilement réalisé parfois.

Nous soulignerons que pour des systèmes décentralisés cela le problème principalement insoluble. Pendant que pour les systèmes commerciaux de paiement se rapportant selon notre classification (voir plus haut) vers les systèmes, les parties de qui peuvent d'avance se mettre d'accord l'attaque donnée est prévenue par la conception compétente du protocole. L'exemple de l'implémentation semblable montre WebMoney, le certificat accordant pour la vérification de l'authenticité de l'HTTPS-liaison. 3. L'attaque La personne au milieu (Man in the Middle, MITM).

Nous avons examiné l'attaque MITM pour le protocole HTTPS. Cependant, d'autres protocoles peuvent être aussi vulnérables pour un tel type des attaques. L'exemple de cela Diffie-Hellman, utilisé à OpenID. Comme était indiqué plus haut, son essentiel dans la génération de la clé totale Vers deux parties: Mais et B.No si chez nous est quelqu'un au milieu (M), qui peut changer le trafic, peut se trouver ainsi que Mais a généré total avec M la clé K1, mais total avec M la clé K2. Au total La personne au milieu M peut signer et lire n'importe quelles données allant dans n'importe quelle direction.

Certainement, l'attaque semblable ne passera pas à OpenID, si le client et le serveur (OpenID Provider et Relying Party) coopèrent selon HTTPS avec la vérification à valeur requise du certificat.

4. La transmission de la clé confidentielle selon le fossé ouvert.

Plusieurs architectes ne comprennent pas l'essentiel de la clé confidentielle. Toute la sécurité dans l'infrastructure avec l'utilisation de la clé ouverte est construite sur ce que les parties coopérant peuvent inconditionnellement croire à quelqu'un. Il n'est pas important pour le deuxième serveur, le tiers-. En général, la question de la confiance s'appuie sur la vérification de la signature digitale avec l'utilisation de la clé ouverte du souscripteur du message. Toute la sécurité peut s'écrouler, si cette clé (certificat) ouverte est transmise selon le fossé non protégé et peut en passant être modifié.

À sérieux les compagnies il y a des gens spéciaux répondant pour la transmission, le stockage, la rénovation de cette clé. La transmission se passe d'habitude à Hors ligne dans les courriers sûrs.

Si vous créez le protocole pour le système de paiement, idéale est la transmission de la clé ouverte de votre serveur personnellement aux mains au propriétaire du magasin en ligne (sur la disquette ou flash drive) à la signature du contrat dans le bureau. Oui, pour n'importe quelles raisons cela réaliser non réellement pas toujours. C'est pourquoi le certificat répandent souvent dans Internet. Mais dans ce cas il faut entreprendre les mesures de prévention toutes possibles de la substitution de la clé. On ne peut pas envoyer la clé selon le courrier électronique. On ne peut pas le donner transférer selon HTTP seulement HTTPS. Sur le site on doit installer l'information sur la vérification de l'information transférée (par exemple, hachage de la clé pour la vérification de son authenticité).

5. L'expédition réitérée de la requête.

Nous examinerons l'aspect donné de l'attaque à deux exemples.

L'exemple 1: le système de paiement. Que je, le serveur respectable, veuille expédier 10$ dans le système de paiement. De plus pour la composition avec le serveur de paiement des systèmes j'utilise HTTP ou mauvais HTTPS (sans vérification du certificat). Je forme honnêtement la requête et je signe par son certificat. Une autre partie reçoit la requête, et miens 10$ partent au destinataire. Mais puisque j'utilisais le protocole ouvert, le malfaiteur a pu lire ma requête vers le serveur. Si ce malfaiteur me veut ruiner, il prend et expédie la même requête au serveur du système de paiement encore une fois. Le serveur contrôle la signature (elle fidèle, puisque est formée juste par le serveur), et autres 10$ sont dépréciés de mon compte. L'exemple 2: le protocole OpenID. Dans le protocole OpenID Authentication 1.1 il y avait une vulnérabilité suivante. Si le malfaiteur écoutait la coopération de l'OpenID-client (Relying Party) et l'usager final, il pouvait initier dans quelque temps réitéré authentification cet utilisateur sur Relying Party avec son utilisation OpenID. Dans ce cas à logs Relying Party il y avait un enregistrement que la personne passait sur le site. Dans les cas spécialement irréfléchis de l'implémentation le malfaiteur pouvait même passer authentification sous le nom de cet utilisateur. Oui, contre cela il y a des moyens de la sécurité, mais ils n'étaient pas déclarés comme obligatoire dans le protocole.

La vulnérabilité donnée ont éliminé dans la version OpenID Authentication 2.0, ayant introduit les changements dans la conduite comme du serveur (OpenID Provider), et le client (Relying Party). Aux lecteurs familiers avec le protocole OpenID Authentication, je propose la devinette sur la compréhension: comment réaliser la sécurité semblable dans le client OpenID de la version 1.1, si le serveur modifier il n'y a pas de possibilité ?
Pour la sécurité contre un tel type des attaques il y a des moyens suivants:
- Cyberplat, par exemple, engage les clients à insérer dans chaque requête le numéro unique de la session. Un tel numéro unique appellent aussi comme le mot nonce (Number used ONCE). Le système de paiement refusera de travailler deux requêtes avec le numéro identique de la session simplement. Mais changer le numéro de la session le malfaiteur ne pourra pas, puisqu'il n'a pas la possibilité de former la signature juste digitale pour le message changé.
- On peut aussi utiliser la sécurité par temps, en insérant dans la requête la balise avec le temps en cours. les vieux les requêtes sont coupées.
- OpenID 2.0 utilise deux ceux-ci de la méthode pour la sécurité contre le type semblable des attaques: nonce coupe le temps en cours et la ligne (pas forcément accidentelle.

6. Pour la plénitude de la description il faut mentionner aussi à la banalité. Si le système est construit sur le caractère secret du mot de passe ou la clé, ces données doivent être de façon certaine protégées. L'étalage des UNIX-privilèges 07XX sur l'accès à tous les fichiers sur la Shared-installation peut s'achever par ce que le fichier du certificat ou le mot de passe vers le BD, où se trouvent les secrets lira le voisin du serveur. Ne se trouve pas oublier d'exposer les mots de passe, les privilèges, délimiter l'accès. D'ailleurs, je ne me répandrai pas longtemps, puisque tout connaissent (bien que, non tous font).

7. Encore un aspect vulnérabilités ce qu'est créé par les programmeurs à l'implémentation du protocole. Je citerai un exemple simple (heureusement, n'étant pas combien de par vulnérabilité sérieuse): il y a 2 ans à deux de cinq implémentations les plus populaires de l'OpenID-serveur les architectes ont embrouillé les notions life_time (le temps de la vie de la clé en des secondes) et expires_time (le temps de l'expiration de la clé en des secondes du 1 janvier 1970). Les terrains spécialement critiques du code il est désirable de soumettre au parcours par les autres participants du projet (OK, cela aussi à la banalité ? Alors nous passerons à la conclusion).

Nous examinerons dix bogues les plus répandues dans la sphère de la sécurité informatique, qui on ne peut pas faire en aucun cas:
1. Lexpédition des données confidentielles dans les lettres non chiffrées électroniques. N'est pas admis envoyer les mots de passe, les handles personnels et les données des écritures comptables dans les lettres non chiffrées électroniques.
2. Lutilisation de contrôle des questions, la réponse sur qui il est facile de deviner. Le numéro de l'assurance, le nom de jeune fille de la mère, le nom de l'élève domestique, la date de la naissance toute cela n'est pas le moyen sûr de l'authentification de la personnalité. L'utilisation de tels de contrôle des questions pour la restitution du mot de passe de l'usager final fait le mot de passe lui-même pratiquement inutile, parce que chacun, qui a un temps et le désir, peut dans tel cas avec facilité choisir key vers l'écriture comptable étrangère.
3. Lutilisation des bornages trop sévères sur le choix du mot de passe. Nous devons souvent nous heurter aux systèmes de gestion les finances en ligne (le type banking Internet), qui établissent tels bornages sévères sur le choix du mot de passe que la sécurité de l'interface de cela baisse seulement. Les mots de passe de six chiffres sont populaires.
4. La confiance aveugle dans les questions de la sécurité aux producteurs du logiciel. Les fournisseurs de la LD, à qui peuvent inconditionnellement croire, n'existent pas simplement. En fin de compte, seul qu'intéresse les producteurs est leur bénéfice personnel et la part sur le marché. Parfois cela les incite à affermir en effet la sécurité des produits de programme et les services, mais parfois tout à fait au contraire. C'est pourquoi la définition de la sécurité sûre du fournisseur de la LD il faut mettre toujours sous le doute. Ne permettez pas aux producteurs de décider pour vous que pour vous est plus important.
5. Lincompréhension de, autant est importante l'expérience professionnelle de la sphère de la sécurité. Les chefs des multinationales (et les It-spécialistes techniquement ferrés y compris) ne donnent pas souvent l'attention voulue au problème du professionnalisme dans le domaine de la sécurité. Arrive à ce que les programmeurs talentueux entrent dans les groupes scientifiques de l'élaboration des standards de la sécurité et aucun spécialiste en la cryptographie beaucoup de (comme c'était en cas avec WEP) avec cela qu'ils tentent de créer les standards s'appuyant directement sur les chiffrement algorithmes.
6. Lincompréhension de, autant est importante la vérification indépendante. Même le travail des experts des aspects spécifiques de la sécurité doivent être contrôlé par les mêmes spécialistes expérimentés. Dans la sphère de la sécurité le contrôle mutuel quelque chose comme Graalja sacré de la sécurité absolue, et aucun système ne peut pas être considéré sûr jusqu'à ce que soit soigneusement et est profondément éprouvée par les spécialistes non impliqués dans son élaboration.
7. Le soin superflu du caractère secret. Plusieurs architectes du logiciel dans la sphère de la sécurité non seulement sous-estiment l'importance de la vérification indépendante, mais aussi surestiment l'importance du caractère secret. Ils argumentent le refus expédier le travail sur la vérification à ces spécialistes indépendants que le principal tiendra en secret la politique de la sécurité. Tandis qu'annonce le principe de Kerkgoffs (un des axiomes fondamentaux de la science de la sécurité), si la sécurité du système dépend exceptionnellement de la sauvegarde de son architecture dans le secret, un tel système ne peut pas être considéré par de façon certaine protégé.
8. Lutilisation des moyens de l'authentification de la personnalité, qui il est facile de falsifier. N'importe quels systèmes prévoyant l'envoi par le fax des signatures, les photocopies ou scans des certificats/passeports à titre du moyen de l'authentification de la personnalité, sont, au fond, décoratif les tas de l'oripeau et l'absence du résultat réel (c'est-à-dire, dans le cas présent, la sécurité). Falsifier telles copies de mauvaise qualité faites avec l'aide des équipements du passé (ou même avant-dernier) les générations, est plus faciles du poumon. En fait, les copies des signatures et les passeports peuvent servir du moyen sûr de l'authentification de la personnalité seulement alors, quand aux copies ne sont pas du tout semblables. En d'autres termes, seulement la contrefaçon qualitative préméditée de l'original peut être considérée par une bonne copie compliquant la contrefaçon malintentionnée.
9. Linvention absurde de la bicyclette. Très souvent les architectes de la nouvelle LD dans la sphère de la sécurité tentent de nouveau de créer ce qu'était déjà créé jusqu'à eux, sans avoir sur cela les raisons sérieuses. Plusieurs producteurs du logiciel souffrent par le syndrome de l'originalité et créent au total les programmes n'ayant pas les nouvelles fonctions utiles. Même ce n'est pas encore terrible, mais en effet, un nouveau logiciel ne passe pas souvent la vérification indépendante, abonde en bogues déjà éliminées dans d'autres réalisations des programmes semblables, et à total, terriblement tout gâte. Avant de procéder à l'élaboration de la nouvelle LD, pensez, s'il n'y a pas déjà d'applications prêtes qualitatives de telle sorte, et si votre futur programme possède en effet les fonctions nouvelles et utiles, si ne pas ajouter mieux ces fonctions à quelque chose déjà existant au lieu de créer et les gens le tas de problèmes, en tentant existant de remplacer ce.
10. La substitution de la sécurité réelle par le sentiment faux de la sécurité. La bogue tellement absurde que même est difficile de formuler son essentiel. Néanmoins, elle est répandue ainsi que ne pas la couper à ce répertoire on ne peut pas simplement. Les gens remettent les clés du système de la sécurité à chacun, qui se présentera par l'expert, et en outre font cela volontiers, avec l'enthousiasme et parfois même les gouttes sans hésiter. les centers de la certification disent, à qui croire, en ôtant la possibilité les utilisateurs indépendamment de prendre les décisions de la confiance; les providers des services du courrier électronique proposent la cryptographie de serveur et le décodage des données, en ôtant la possibilité les gens indépendamment de chiffrer les lettres et diriger personnel les cryptographiques clés; les systèmes d'exploitation lancent sans autorisation les services et les applications, en ôtant la possibilité les utilisateurs de se défendre de la LD mobile nuisible. Ne croyez pas la gestion de la sécurité aux tiers! Certes, non tous peuvent élaborer le programme sûr ou la politique dans le domaine de la sécurité est exceptionnellement indépendant, mais cela ne signifie pas encore qu'un tel programme ou la politique doit vous ôter la possibilité diriger personnellement.

Ainsi, ne se trouve pas compter sur les architectes de n'importe quel protocole, que même les auteurs soient les compagnies avec le nom illustre.


Les sources:
1. Kopytin D. Sécurité dans l'inter-projet de collaboration [http://www.infosecurity.ru/cgi-bin/mart/arts.pl?a=091215]
2. Perrin Ch. Dix bogues les plus répandues dans la sphère de la sécurité informatique, qui on ne peut pas faire en aucun cas [http://www.winblog.ru/security/1147765822-15090802.html]

L'auteur:
La date: 23/03/2010

Les commentaires des spécialistes de :
Non

© –  info@chepr.ru, 2007-2013
DRA.RU - ;  «»
| ||
 / |