Online Documentation Server
 ПОИСК
ods.com.ua Web
 КАТЕГОРИИ
Home
Programming
Net technology
Unixes
Security
RFC, HOWTO
Web technology
Data bases
Other docs

 


 ПОДПИСКА

 О КОПИРАЙТАХ
Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.




Вопросы и ответы по безопасности в WWW


Наверх, к Содержание
Назад, к Поддержка защищенного сервера
Вперед, к Скрипты CGI

5. Защита конфиденциальных документов на вашем сервере

В17: Какие существуют типы ограничения доступа?

Существует три типа ограничения прав доступа:
  1. Ограничения на основе IP адреса, подсети или домена.

    Отдельные документы или целые директории могут быть сделаны доступными только для браузеров, имеющих конкретный адрес IP (адрес в Internet), либо принадлежащих определенной подсети, либо принадлежащих определенному домену.

  2. Ограничения по имени пользователя и паролю

    Документы или директории защищены таким образом, что для доступа к ним удаленный пользователь должен предоставить имя и пароль.

  3. Шифрование с использованием открытого ключа (public key cryptography)

    И запросы документов, и сами документы шифруются таким образом, что их текст не может быть прочтен никем кроме того, кому они направлены. Шифрование с открытым ключем может быть также использовано для надежной проверки пользователя. См. далее.


В18: Насколько надежно ограничение по IP адресу или имени домена?

Ограничение доступа по IP адресу эффективно против случайных попыток доступа, но не против хакера, действующего целенаправленно. Существуют различные способы обхода такого рода ограничений. Имя необходимую аппаратуру и программное обеспечение, хакер может "замазать" свой IP адрес, имитируя соединение не с того места в сети, где действительно расположен его компьютер, а из какого-либо другого. Кроме того, нет никакой гарантии того, что человек, обращающийся к вашему серверу с компьютера, доступ с которого вы разрешили, является именно тем человеком, которого вы имеете в виду. Компьютер мог быть взломан и использован хакером. Ограничения по сетевому адресу должны для надежности дополняться какими-нибудь проверками пользователя, такими как проверка пользовательского имени и пароля.

Ограничения доступа по IP адресам могут быть сделаны гораздо более надежными путем защиты вашей машины брандмауэром, способным определять и предотвращать попытки использования фиктивных адресов IP (IP spoofing). Проще всего перехватываются пакеты, приходящие из внешнего мира, но составленные так, как будто они посланы с компьютера в вашей локальной сети.

Следует также понимать, что в том случае, если браузер настроен на использование сервера - представителя (proxy), ваш Web сервер получит только IP адрес представителя, но не той машины, на которой работает пользователь. Это значит, что при наличии proxy в домене, которому вы доверяете, любой человек может использовать proxy для доступа к серверу. Если вы не знаете точно, что можете доверить определенному серверу-представителю накладывать собственные ограничения доступа, не добавляйте IP адресов proxy серверов или доменов, содержащих proxy, к списку адресов, с которых разрешен доступ к вашему узлу.

Ограничения доступа по имени компьютера или домена, обладающие теми же слабостями, что и ограничения по IP адресам, чуствительны, кроме того, к "замазыванию имен DNS" (DNS spoofing) - атаке, при которой ваш сервер убеждают на время в том, что разрешенное имя соответствует другому (нужному хакеру) IP адресу. Для уменьшения подобного риска некоторые серверы могут быть настроены на дополнительную проверку имени DNS для каждого клиента. После преобразования IP адреса, с которого пришел запрос, в имя компьютера, сервер использует систему DNS для обратного преобразования имени в адрес IP. Если два IP адреса не совпадают, то доступ не предоставляется. Смотри ниже инструкции по использованию этой возможности в NCSA httpd.


В19: Насколько надежны ограничения доступа по имени пользователя и паролю?

Ограничения по имени пользователя и паролю имеют свои недостатки. Пароль хорош только в том случае, если он правильно выбран. Очень часто пользователи выбирают простые пароли, такие, как собственное имя, дату своего рождения, номера своих рабочих телефонов или имя любимой собаки. Такие пароли могут быть относительно легко найдены, а серверы WWW, в отличие от программ входа (login) в Unix, не обращают внимания на повторяющиеся неудачные попытки доступа. Опытный хакер может использовать программу перебора паролей для проникновения на сервер посредством грубой силы (простого перебора возможных паролей). Вам следует также учитывать возможность того, что удаленные пользователи могут предоставлять свои имена и пароли другим лицам. Использование комбинации ограничений доступа по сетевым адресам и по паролям безопаснее, чем использование только одного из этих двух способов защиты.

Другая проблема состоит в возможности перехвата пароля при его передаче по сети от браузера на сервер. Хакер, обладающий соответствующим оборудованием и программами, имеет возможность "вытащить" пароль из Internet при его прохождении. Кроме того, в отличие от прямого входа (login) пользователя в систему, когда пароль передается по Сети только один раз, браузер посылает пароль заново при каждом обращении к защищенному документу, что делает задачу хакера по перехвату пароля более легкой. Для избежания перехвата необходимо шифровать данные при передаче. Смотри далее.

Если вам необходимо защищать документы от доступа _локальных_ пользователей системы, на которой установлен сервер, то вам придется запускать сервер с правами, отличными от прав пользователя "nobody", и устанавливать права доступа к файлам документов и скриптов CGI так, чтобы они не были общедоступны для чтения. Смотри В9.


В20: Что такое проверка пользователя (user authentication)?

Это любой способ определения и проверки личности удаленного пользователя. Простейший способ проверки - имя пользователя и пароль. Системы шифрования с открытым ключем (public key encryption), описание которых можно найти ниже, являются более сложным способом проверки, использующим электронные подписи.

В21: Как мне ограничить доступ к документам по IP адресу или имени домена удаленного браузера?

Способы различны для различных серверов. Обратитесь к документации вашего сервера за подробностями. Для серверов, построенных на основе NCSA httpd, необходимо добавить раздел управления директорием в файле access.conf, который должен выглядеть примерно так:
   <Directory /полный/путь/к/директорию>
<Limit GET POST> order mutual-failure deny from all allow from 192.198.2 .zoo.org allow from 18.157.0.5 stoat.outback.au </Limit> </Directory>

Таким образом вы запрещаете доступ для всех, кроме указанных машин (18.157.0.5 и stoat.outback.au), подсети (182.198.2) и домена (.zoo.org). Хотя имеется возможность использовать либо цифровые IP адреса, либо имена машин, безопаснее использовать цифровые адреса, поскольку этот способ идентификации труднее "обмануть" (В18).

Один из способов повышения надежности ограничений по именам доменов состоит в настройке сервера на двойную проверку имен DNS. Вы можете включить эту возможность в NCSA httpd (и в родственном сервере Apache) установив флаг -DMAXIMUM_DNS в файле Makefile перед компиляцией.

Для сервера CERN необходимо объявить схему защиты при помощи директивы Protection и связать ее с локальным адресом URL директивой Protect. Фрагмент файла httpd.conf, разрешающий доступ только из определенных доменов, может выглядеть следующим образом:

   Protection LOCAL-USERS {
GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5) }
Protect /относительный/путь/к/директорию/* LOCAL-USERS

В22: Как мне добавить новых пользователей и пароли?

Серверы на основе систем Unix используют файлы, подобные файлам passwd и group системы Unix. Хотя формат этих файлов таков, что позволяет использовать для сервера Web те же файлы, что и для самой операционной системы, делать этого не следует. Незачем давать хакеру, нашедшему пароль для доступа к серверу WWW, право на вход в систему Unix.

Обратитесь к документации вашего сервера за подробными инструкциями по добавлению пользователей. Для сервера NCSA httpd вы можете добавить пользователя к файлу пользователей с помощью программы htpasswd, которая распространяется вместе с программным обеспечением сервера:

   htpasswd /путь/к/файлу/паролей имя_пользователя

htpasswd попросит вас затем ввести пароль для нового пользователя. При первом запуске программы htpasswd нужно использовать флаг -c для создания нового файла паролей.

Сервер CERN снабжен иной программой, называемой htadm:

   htadm -adduser /путь/к/файлу/паролей имя_пользователя

htadm попросит вас ввести пароль для пользователя.

Когда пользователи определены, вы можете устанавливать защиту по паролю на директории, которые вы выбираете. Для NCSA httpd и производных серверов, добавте что-нибудь в таком роде к файлу access.conf:

   <Directory /полный/путь/к/защищаемому/директорию>

     AuthName          имя.вашего.сервера
     AuthType          Basic
     AuthUserFile      /usr/local/etc/httpd/conf/passwd
     <Limit GET POST>
       require valid-user
     </Limit>

</Directory>
Вам придется заменить AuthUserFile на полный путь к файлу паролей. Такой способ защиты может быть скомбинирован с защитой на основе IP адресов, как описано в предшествующем разделе. Документация NCSA (http://hoohoo.ncsa.uiuc.edu/) и книга автора (How to Set Up and Maintain a Web Site) описывают это более подробно.

Для сервера CERN соответствующий фрагмент файла httpd.conf выглядит примерно так:

   Protection AUTHORIZED-USERS {
     AuthType     Basic
     ServerID     имя.вашего.сервера
     PasswordFile /usr/local/etc/httpd/conf/passwd
     GetMask      All
}
Protect /относительный/путь/к/директорию/* AUTHORIZED-USERS
Опять же, обращайтесь к документации сервера или книге автора за деталями.

В23: Существуют ли скрипты CGI, позволяющие пользователю изменять его пароль при работе с сервером?

Различные скрипты подобного рода находятся в обращении. Автор предпочитает скрипт собственного производства, user_manage. Он работает с файлами паролей и групп, используемыми серверами Apache, NCSA httpd, CERN и серверами Netscape для Unix. Возможно, его можно использовать и для других серверов для систем Unix. Скрипт может быть использован пользователями для безопасной смены пароля и администраторами для добавления пользователей, манипулирования группами, изменения прав существующих пользователей. Этот скрипт можно получить на URL:
http://www.genome.wi.mit.edu/~lstein/user_manage/

Bill Jones написал многофункциональный скрипт под названием WebPass. Кроме пароля Web пользователи могут изменять свои пароли для входа в систему и для доступа к POP и news серверам, если они имеют такие пароли. Скрипт использует сочетание Perl и Expect для осуществления этих чудес. Скрипт можно найти по адресу:

http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.html

Различные коммерческие серверы также имеют скрипты для удаленного управления пользователями. Смотрите документацию вашего сервера для получения подробной информации.


В24: Использование для управления доступом к директориям индивидуальных файлов контроля так удобно, почему я должен использовать файл access.conf?

Большинство серверов предоставляют возможность вместо того, чтобы указывать все директории в центральном файле управления доступом, помещать в каждом директории "спрятанный" (hidden) файл, регулирующий права доступа к этому директорию (такой файл называется .htaccess в серверах семейства NCSA и .www_acl в сервере CERN). Использование таких файлов очень удобно, поскольку вы можете ограничить доступ к директорию избегая редактирования центрального файла управления доступом. Но существует ряд причин, по которым не следует слишком доверяться файлу .htaccess. Одна из них состоит в том, что управляющие файлы разбросаны по дереву документов, а не находятся в одном месте, доступ к которому на уровне операционной системы четко контролируем. Другая причина состоит в том, что эти файлы могут быть легко стерты или изменены случайно, что откроет неограниченный доступ к части иерархии документов. Наконец, многие серверы (в том числе и NCSA) содержат ошибку, позволяющую получить файл управления доступом точно так же, как и любой другой файл документов WWW, используя подобный адрес URL:
   http://имя.вашего.узла/защищенный/директорий/.htaccess
Это безусловно опасное свойство, поскольку таким образом можно получить важную информацию о системе, включая местонахождение файла паролей сервера.

Еще одна проблема состоит в том, что при замене программного обеспечения сервера гораздо проще отредактировать или заменить один центральный файл управления доступом, чем искать и редактировать сотни маленьких файлов.


В25: Как работает шифрование?

Шифрование осуществляется путем кодирования текста с использованием ключа. В традиционных системах шифрования один и тот же ключ использовался для шифровки и расшифровки текста. В современных системах с открытым ключем, или асимметричных системах, используются парные ключи - один для шифрования, другой - для расшифровки сообщения. В такой системе каждый владеет уникальной парой ключей. Один ключ, называемый открытым (public key), широко распространяется и используется для кодирования сообщений. Другой ключ, называемый личным ключем (private key), хранится в секрете и используется для расшифровки приходящих сообщений. При такой системе сторона, посылающая сообщение, может закодировать его при помощи открытого ключа, принадлежащего адресату. Такое сообщение может быть расшифровано только тем, кто имеет секретный ключ, что предотвращает расшифровку при перехвате. Такая же система может быть использована для создания электронных подписей.

Большинство существующих систем шифрования в Internet используют на самом деле комбинацию современной асимметричной и традиционной симметричной систем шифрования. Шифрование с открытым ключем используется для передачи симметричного ключа, который используется при шифровании передаваемой информации.

Поскольку коммерческие предприятия испытывают острую нужду в безопасной передаче данных через Web, существует активный интерес к разработке схем шифрования данных для передачи между браузером и сервером.

Более подробную информацию о шифровании с открытыми ключами можно найти в книге "Applied Cryptography", автор - Bruce Schneier.


В26: Что такое: SSL, SHTTP, Shen?

Это все - предложенные стандарты для шифрования данных и проверки пользователя в Web. Каждый из них требует для работы сочетания поддерживающих его браузера и сервера, и поэтому пока ни один из них не является универсальным решением проблемы безопасной передачи данных.

SSL (Secure Socket Layer) - это схема, предложенная Netscape Communications Corporation. Это схема шифрования на низком уровне, используемая для кодирования транзакций протоколов более высокого уровня, таких как HTTP, NNTP и FTP. Протокол SSL поддерживает проверку сервера (server authentication - подтверждение идентичности сервера для клиента), шифрование данных при передаче и возможность проверки клиента (client authentication, подтверждение идентичности клиента для сервера). SSL в настоящее время реализован коммерчески в различных браузерах, включая Netscape Navigator, Secure Mosaic и Microsoft Internet Explorer; и в различных серверах, включая серверы Netscape, Microsoft, IBM, Quarterdeck, OpenMarket и O'Reilly and Associates. Детали протокола SSL можно найти по адресу:

http://home.netscape.com/newsref/std/SSL.html

SHTTP (Secure HTTP - безопасный HTTP) - это схема, предложеная CommerceNet, объединением организаций, заинтересованных в развитии Internet для коммерческого использования. Это протокол более высокого уровня, который работает только с протоколом HTTP, но потенциально более расширяемый, чем SSL. В настоящее время SHTTP реализован для сервера Open Marketplace Server, распространяемого компанией Open Market, Inc, на стороне сервера и в Secure HTTP Mosaic от Enterprise Integration Technologies на стороне клиента. Здесь можно найти детали:

http://www.eit.com/creations/s-http/

Shen - схема, предложенная Phillip Hallam-Baker из CERN. Подобно SHTTP, это замена существующего протокола HTTP. Хотя предложение существовало около двух лет, оно не было реализовано ни в одном браузере или сервере. Более того, поскольку URL с описанием Shen более не доступен, есть основания считать эту схему отмершей.


В27: Существуют ли некоммерческие ("freeware") защищенные серверы?

Существует некоммерческая реализация SSL, известная как SSLeay. Эта реализация распространяется в виде исходных текстов на языке C, которые могут быть использованы в таких приложениях, как Telnet и FTP. Среди поддерживаемых приложений - свободно распространяемые Web-серверы для Unix - Apache и NCSA httpd, а также различные браузеры для Unix, включая Mosaic. За пределами США этот пакет может быть использован бесплатно как в некоммерческих, так и в коммерческих приложениях. В США необходимо купить лицензию у RSA Data Security для использования SSL в коммерческих приложениях (может оказаться проще приобрести одну из коммерческих версий Apache-SSL, в цену которых включена стоимость лицензии).

Пакет состоит из нескольких компонентов. Для получения работающего Web сервера с поддержкой SSL вам придется получить и установить их все:

The SSLeay FAQ
http://www.psy.uq.oz.au/~ftp/Crypto/. Вам придется это внимательно прочесть.
SSLeay
Это собственно библиотека SSL. Она может быть получена через FTP на ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/
Исправления (patches) для различных приложений Internet
Это исправления для исходных текстов telnet, ftp, Mosaic и им подобных, необходимые для использования SSL. Их можно получить по FTP: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/.
Исправления для сервера Apache
В настоящее время есть исправления для серверов Apache 0.8.14h и 1.0.1a. Исправления могут работать и для других версий, но это не гарантировано. ftp://ftp.ox.ac.uk/pub/crypto/SSL/
Исходные тексты сервера Apache
http://www.apache.org
Вы можете получить откомпилированные заранее версии сервера Apache из двух источников. В США вы можете получить Stronghold от Community ConneXion, Inc. За пределами США вы можете получить Stronghold от Thawte Consulting, Ltd и на stronghold.ukweb.com. Эта версия Apache доступна со скидкой для некоммерческих организаций и образовательных учреждений.

После установки поддерживающего SSL сервера вам необходимо получить удостоверение сервера (server certificate) от утверждающей организации. Сертификаты предоставляют различные компании, со слегка различающимися правилами подачи заявки и расценками. В США первой была корпорация VeriSign Corporation, которая остается наиболее популярной и в настоящее время. Однако, по причине недавнего поднятия цен корпорацией VeriSign ($495 за сертификат коммерческого сервера) она стала одной из самых дорогих. Хорошей альтернативой VeriSign является Thawte Consulting; их цены значительно ниже и процедура подачи заявки для компаний за пределами США проще. Другие сертифицирующие организации включают:

Entrust
http://www.entrust.com/

GTE CyberTrust
http://www.cybertrust.gte.com/

EuroSign
http://eurosign.com

COST
http://www.cost.se

BiNARY SuRGEONS
http://www.surgeons.co.za/certificate.html

Keywitness
http://www.keywitness.ca

SoftForum
http://www.softforum.co.kr/

CompuSource
http://www.compusource.co.za/
Прежде чем заказывать сертификат у какой-либо сертифицирующей организации (CA) убедитесь, что сертификат будет распознаваться теми браузерами, которые вы собираетесь поддерживать. VeriSign и Thawte распознаются последними версиями браузеров Netscape и Microsoft. Другие сертификаты могут не распознаваться. Для просмотра списка сертификатов, распознаваемых браузером, выберите в меню: Options-<Security Preferences->Site Certificates в Netscape Navigator, View->Options->Security->Sites в Internet Explorer. В Netscape Communicator информация доступна по кнопке Security на панели инструментов.

Процесс получения сертификата слегка различен у различных CA, но схож в основных моментах. После выбора CA соединитесь с их узлом Web и найдите раздел подачи заявки на сертификат. Выберите и заполните форму, подходящую для вашего программного обеспечения. У вас будут запрошены имена вашего узла Web, вашей компании и информация для связи. У вас также будут запрошены какие-либо документы, подтверждающие существование вашей организации и информация для приема оплаты (например, номер кредитной карты).

Заполнение формы - только половина процесса. Вы должны также создать запрос на электронный сертификат. После заполнения формы CA, используйте программу, входящую в состав программного обеспечения вашего сервера, для создания пары открытого и личного ключей. В пакете сервера Apache-SSL такая программа называется genkey.

Программа генерации ключа создаст файл, содержащий запрос на ключ. В некоторых случаях файл будет автоматически послан CA по электронной почте, в других Вам придется самостоятельно отсылать файл по e-mail. В любом случае вам придется ждать несколько дней или недель, в течение которых CA будет проверять достоверность вашего запроса. После проверки вы получите по электронной почте подписанный сертификат, который вы должны установить на своем сервере. Способ установки зависит от используемого сервера, для сервера Apache-SSL используйте программу getca.

Теперь пользователи могут получать документы с вашего сервера и передавать данные на сервер без боязни перехвата. Сертификат вашего сервера идентифицирует сервер для пользователя.


В28: Можно ли использовать личные сертификаты (Personal Certificates) для контроля доступа к серверу?

SSL можно использовать и для идентификации пользователя, что обеспечивает более надежную проверку, чем обычные имя пользователя и пароль. Для использования такой схемы каждый пользователь должен получить личный сертификат ("personal certificate") у CA.

Недорогой личный сертификат можно получить у VeriSign. VeriSign предлагает сертификаты двух классов. Сертификаты первого класса стоят всего $9.95 в год, но не дают полной гарантии того, что пользователь действительно является тем, кем он представляется, поскольку VeriSign не проверяет данные, предоставляемые пользователем при заказе сертификата. Сертификаты первого класса гарантируют, что пользователь может получать электронную почту по адресу, предоставленному программой. Сертификаты второго класса, стоящие $19.95 в год, дают больше гарантий, поскольку информация о пользователе, получившем такой сертификат, подвергается проверке.

Если вы используете интранет, то вам может иметь смысл создать свои собственные личные сертификаты для использования служащими вашей компании. Для этого вам необходимо получить и установить сервер сертификатов. Такие системы можно получить у следующих компаний: Microsoft, Netscape, XCert, Entrust и GTE.

Для использования личных сертификатов с целью контроля доступа к серверу вам необходимо будет настроить сервер соответствующим образом. Обсуждение того, как это сделать, выходит за рамки рассмотрения настоящего документа, но подробные инструкции содержатся в книге автора оригинального документа The Web Security Reference Guide, которая будет доступна в декабре 1997 года.


В29: Как получать заказы по кредитным картам через Web?

Всегда можно попросить пользователя позвонить по телефону :-). Если серьезно, то вы _не должны_ предлогать удаленному пользователю вводить номер его кредитной карты, если вы не используете пару браузер/сервер, поддерживающую шифровку данных. Альтернативой может служить использование представительских систем (credit card proxy system), описываемых в следующем вопросе.

Даже при использовании шифрования, следует быть осторожным в части того, что происходит с номером карты после того, как он получен на сервере. Убедитесь например, что после получения он не попадает в общедоступный для чтения файл трассировки и не передается на другую машину по электронной почте.


В30: Что такое: First Virtual Accounts, DigiCash, CyberCash, SET?

Это все - схемы, предназначенные для обработки коммерческих заказов с использованием Web без передачи номеров кредитных карт или другой конфиденциальной информации.

First Virtual

Схема First Virtual разработана для продажи программ по низким и средним ценам, предоставление платной информации и других "нематериальных" ценностей, которые могут быть переданы по Internet. Она не предназначена для продажи вещественных товаров, таких, как компьютеры или посудомоечные машины.

Перед использованием системы First Virtual потребитель должен подписаться и получить счет, заполнив форму ввода на узле First Virtual (см. ниже). Процесс подписки заканчивается по телефону. В ходе подписки потребитель предоставляет информацию о номере своей кредитной карты, информацию для контакта, и получает свой персональный идентификационный номер (PIN, Personal Identification Number) в системе First Virtual. Далее при заказах у членов First Virtual потребитель использует свой номер PIN вместо номера кредитной карты. Прежде чем снимать деньги с карты, First Virtual запросит подтверждения заказа по электронной почте. Чтобы открыть счет в системе First Virtual потребитель должен уплатить разовый сбор в размере двух долларов США. Дополнительных выплат нет, и пользователю не требуется устанавливать у себя какого-либо специального программного обеспечения для использования системы.

Поставщики, желающие принимать оплату через систему First Virtual, должны открыть в системе счет за одноразовую плату в размере $10.00. First Virtual предоставит поставщику простую программу для проверки пользовательских номеров PIN и информирующую First Virtual о полученных заказах. Эта программа легко может быть использована в скрипте CGI, принимающем заказ. First Virtual получает с поставщика плату в размере $0.29 за каждый заказ плюс 3% от суммы заказа.

Дальнейшую информацию о First Virtual можно получить по адресу:

http://www.fv.com/

DigiCash

DigiCash, продукт компании DigiCash, расположенной в Нидерландах, представляет собой нечто вроде системы обычных телефонных карточек. В этой системе пользователь покупает "КиберБаксы" (CyberBucks) в банке, поддерживающем систему DigiCash. КиберБаксы могут быть куплены по кредитной карте или через телеграфный перевод. КиберБаксы, представляющие собой наборы закодированных особым образом серийных номеров, используются тем же образом, как и настоящие деньги: они могут быть переданы в обмен на материальные или нематериальные ценности или переданы от одного человека другому при взаимных расчетах. В любой момент вы можете обменять КиберБаксы на "нормальные" деньги в банке.

Программное обеспечение, поддерживающее DigiCash, препятствует повторному использованию КиберБаксов. Как и настоящие деньги, КиберБаксы могут быть использованы анонимно. Вы не должны идентифицировать себя для того, чтобы иметь возможность потратить или получить "цифровую валюту", и ее использование не оставляет следов. Это отличает систему DigiCash от систем, основанных на кредитных картах, таких, как CyberCash и SET, в которых каждая операция фиксируется на бумаге, что может быть использовано для изучения привычек потребителя. В дополнение, DigiCash может использоваться для безопасной передачи денег между индивидуумами, позволяя обычным людям продавать услуги и товары через Internet без вовлечения банковской системы.

DigiCash требует установки специальных программ на компьютерах заказчика и продавца. В настоящее время имеются версии для Windows 95, Windows NT и некоторых систем Unix. В силу своей молодости эта система пока не получила широкого распространения, однако ситуация должна измениться. Дальнейшую информацию, включая список банков, поддерживающих DigiCash, можно получить на URL:

http://www.digicash.nl/

CyberCash

CyberCash, продукт корпорации CyberCash, использует специализированные программы на стороне продавца и покупателя, позволяя безопасно производить оплату через Internet. Чтобы производить оплату по системе CyberCash, потребитель должен получить бесплатную копию программы под названием Wallet с узла Web, принадлежащего CyberCash, и настроить ее с использованием личных данных и данных для выплат. Данные, необходимые для выплат, в настоящее время включают номер кредитной карты и номер банковского счета. Wallet сохраняет эту информацию на компьютере пользователя в зашифрованном виде.

При заказе в магазине, поддерживающем CyberCash, wallet открывает окно и запрашивает у пользователя информацию о выборе системы оплаты. Пользователь может выбрать оплату через кредитную карту или переводом со счета. Программа, установленная на стороне продавца, проверяет и фиксирует операцию, соединяясь с сервером CyberCash. Этот процесс занимает 10-15 секунд. Wallet ведет учет всех заказов, позволяя пользователю сверять данные записей с информацией о состоянии кредитной карты или счета, полученной из банка. Программа доступна для многих платформ, включая Macintosh, Windows 95 и Windows NT.

Система использует надежное шифрование для защиты передаваемой информации от перехвата третьими лицами. Более того, поскольку реальные номера кредитных карт не попадают на сервер продавца, то нет опасности получения номеров кредитных карт людьми, проникнувшими на сервер продавца.

Для того, чтобы принимать платежи через CyberCash, продавцу необходимо открыть счет в банке, поддерживающем систему. Счет похож на счет, открываемый для принятия платежей по кредитным картам через заказы по почте, и требует примерно тех же затрат: разовая выплата 100 долларов при открытии счета, примерно 15 долларов в месяц для его поддержания и выплаты 2-3% от стоимости с каждого заказа. Точные расценки устанавливаются самостоятельно местными банками и могут несколько различаться. Сейчас несколько сотен банков поддерживают систему CyberCash, и это число постоянно растет.

После открытия счета продавец устанавливает у себя на сервере программу "электронный регистратор валюты" (Electronic Cash Register). Программа запускается при нажатии заказчиком кнопки "заплатить" ("pay") или ее аналога и берет на себя соединение, создавая запись, которую продавец может использовать в своей системе доставки. Программа распространяется бесплатно и существует в вариантах для различных платформ, включая Windows NT и Unix.

Основное преимущество системы CyberCash в сравнении с DigiCash состоит в том, что заказчик обеспечен в ней той же степенью защиты потребителя, которую дает кредитная карта сама по себе. Если продавец не предоставляет товар, или предоставляет товар неудовлетворительного качества, то потребитель может обратиться в компанию, выдавшую кредитную карту. Недостатки включают потерю анонимности, характерную для всех расчетов по кредитным или дебетным картам и невозможность осуществления расчетов между равными. Кроме того, выплаты продавцов за обработку заказов делают систему невыгодной для мелких поставщиков, таких как поставщиков интерактивных видеоигр. Эта последняя проблема однако решается CyberCash путем введения системы CyberCoin, позволяющей заказчику вносить единовременно некоторую сумму, после чего использовать ее частями в мелких заказах.

Для получения дальнейшей информации можно обратиться на http://www.cybercash.com

SET

Протокол SET, или Secure Electronic Transaction (безопасное электронное взаимодействие), представляет собой открытый стандарт для обработки выплат по кредитным картам в Internet, созданный совместно фирмами Netscape, Microsoft, Visa и Mastercard. Основное преимущество SET - универсальность. Программы, поддерживающие его, будут иметь возможность взаимодействовать с программами других производителей.

Учитывая широкие возможности для мошенничества в Internet, SET использует сложную систему проверки всех сторон, участвующих в операции - заказчик, поставщик, организация, выпустившая карту и банк продавца - все идентифицируются при помощи специальных заверенных сертификатов. Для сохранения прав личности, поставщик получает доступ к информации в части предмета заказа, стоимости заказа и подтверждения оплаты, но не в части способа оплаты, выбранного заказчиком. Фирма, выпустившая кредитную карту, в свою очередь, имеет доступ к информации о стоимости заказа, но не о том, где он был сделан. Однако, не смотря на эти предосторожности, SET не предоставляет того уровня анонимности, которого достигает система DigiCash.

SET требует специального программного обеспечения и на стороне продавца, и на стороне покупателя. По крайней мере, на стороне заказчика программа может быть загружена тут же в форме апплета Java и/или элемента ActiveX. В настоящее время имеются два продукта, поддерживающие SET. Microsoft Merchant - система, предлагаемая фирмой Microsoft Corporation. Построенный вокруг Internet Information Server, Microsoft Merchant предлагает проверку кредитных карт с использованием службы Verifone. Вдобавок, Microsoft Merchant предлагает такие услуги, как поддержание каталогов, скрипты для заказов, вычисление налогов с продаж. Microsoft Merchant существовал в виде предварительной (beta) версии в ноябре 1996 года, и должен быть доступен в то время, когда вы это читаете.

В свою очередь, корпорация Netscape, в сотрудничестве со своим стратегическим партнером First Data, предлагает LivePayment. Это - добавочный модуль для сервера Netscape Secure Commerce Server, предоставляющий возможность защищенной передачи, прверки и обработки информации о кредитноц карте. вы можете добавлять модули для поддержки каталогов, связи с корпоративной базой данных и другие. В его теперешней реализации, LivePayment использует предшественник SET, похожий на стандарт, но не идентичный. Полностью SET-совместимая версия должна быть выпущена в скором времени.

Open Market Web Commerce System

Open Market, Inc., также предлагает систему сетевой коммерции. В этой схеме Open Market сам действует как компания, выпускающая кредитные карты, обеспечивая выписку, ведение счетов и выплаты. Схема встроена в сервер Open Marketplace Server и требует использования браузера, поддерживающего протокол SHTTP или SSL. Продукты предназначены в первую очередь для больших корпораций, банков и поставщиков услуг, которые хотят организовать виртуальные супермаркеты, и имеют соответствующие цены. Информацию можно получить по адресу:

http://www.openmarket.com


Наверх, к Содержание
Назад, к Поддержка защищенного сервера
Вперед, к Скрипты CGI

Lincoln D. Stein (lstein@w3.org)
WWW Consortium

Перевод - Дмитрий Громов

SSL-сертификаты

Last modified: Thu Apr 16 10:39:53 EST 1998


With any suggestions or questions please feel free to contact us