Шифрование данных для Web-Server а

← →
Ega23 © (2008-02-26 11:38) [0]

Народ, вот какой вопрос: если мне из браузера надо авторизоваться на WebServer, то каким образом на сервер передаются мои логин-пароль?
В явном виде, или в шифрованном?
Дайте ссылку почитать на эту тему...

← →
Рамиль © (2008-02-26 11:40) [1]

http в открытом
https в шифрованном

← →
Kerk © (2008-02-26 11:40) [2]

Способов авторизации очень много
Уточни о каком ты говоришь
---

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

← →
Ega23 © (2008-02-26 11:46) [3]

> Уточни о каком ты говоришь

Есть СУБД с какими-то данными. Для неё разрабатывается тонкий клиент - вся логика уходит на WebServer, пользователь только тыкает ссылки в браузере и смотрит полученные страницы.
есть список действий, доступный пользователю. Зависит от его "роли доступа", т.е., фактически, от логин-пароль.
Собственно, перед началом работы пользователь вводит логин-пароль в html-форме и это дело уходит на сервер, где уже формируется контент, разрешённый данной роли.

собственно вопрос: в каком виде этот логи-пароль на сервер уходит?
В виде http://www.xxx.ru/main$uid=user&pwd=pass ?
Или всё-таки как-то более хитрым способом?

← →
Kerk © (2008-02-26 11:50) [4]

> Собственно, перед началом работы пользователь вводит логин-
> пароль в html-форме и это дело уходит на сервер, где уже
> формируется контент, разрешённый данной роли.
>
> собственно вопрос: в каком виде этот логи-пароль на сервер
> уходит?
> В виде http://www.xxx.ru/main$uid=user&pwd=pass ?
> Или всё-таки как-то более хитрым способом?

Так и уходит. Копай в сторону SSL, тогда вообще весь трафик будет шифроваться

← →
Kerk © (2008-02-26 11:54) [5]

Нужно будет просто установить SSL-сертификат на сервер. Если он самодельный, то клиента браузер при первом заходе спросит доверять ли сертификату, если купленный в каком-нить модном месте, то винда сама проверит кто его выдал.

← →
clickmaker © (2008-02-26 12:06) [6]

> собственно вопрос: в каком виде этот логи-пароль на сервер
> уходит?
> В виде http://www.xxx.ru/main$uid=user&pwd=pass ?

если через submit формы и у нее action=post, что через post, т.е. не как часть урла

← →
clickmaker © (2008-02-26 12:14) [7]

PS. в любом случае рекомендовал бы передавать уже хэш пароля

← →
Ega23 © (2008-02-26 12:17) [8]

> PS. в любом случае рекомендовал бы передавать уже хэш пароля

А как его в браузере получить?
Ткните носом в ссылку какую-нибудь (чтобы я вас не мучил своими вопросами глупыми), где это простым доступным способом описано, а то я этим никогда раньше не занимался и практически полный ноль в этих делах.

← →
clickmaker © (2008-02-26 12:20) [9]

> [8] Ega23 © (26.02.08 12:17)
>
> > PS. в любом случае рекомендовал бы передавать уже хэш
> пароля
>
>
> А как его в браузере получить?

средствами языка, на котором пишется страница.
в php - MD5(), SHA1(), к примеру

← →
Kerk © (2008-02-26 12:25) [10]

> Ega23 © (26.02.08 12:17) [8]

Special For You :)
http://forum.antichat.ru/thread47802.html

← →
Kerk © (2008-02-26 12:26) [11]

Но как основное средство защиты - это ничего не меняет. Какая разница злоумышленнику, что перехватывать? Пароль или его хэш? Всяко, что поймал, то и передаешь серверу для авторизации.

← →
DiamondShark © (2008-02-26 12:31) [12]

> А как его в браузере получить?

Известно как: вычислить.
Хинт: В браузере есть скрипты.

В тырнете полно реализаций хэшей на VBScript и JavaScript.

← →
DiamondShark © (2008-02-26 12:33) [13]

> clickmaker © (26.02.08 12:20) [9]

Какой ещё пыхэпэ, если хэш надо в браузере считать?

← →
clickmaker © (2008-02-26 12:37) [14]

> [13] DiamondShark © (26.02.08 12:33)

ну-да, ну-да... это меня переклинило на передачу из веб-сервера в базу )

← →
Ega23 © (2008-02-26 12:53) [15]

Так, с хэшированием понятно, дальше сам разберусь, всем спасибо!

Возник ещё один теоретический вопрос:
Вот есть СУБД (минимальный набор - Oracle, MSSQL, Postgres), вот к ней - клиент. Данные из БД на клиент гонятся по TCP.
А есть ли на этом уровне защита данных? Т.е. я послал запрос типа Select * from Table1. Как мне ответ защитить во время передачи, и вооще, можно ли это сделать стандартными средствами? Или свой "недопротокол" придётся накручивать?

← →
Eraser © (2008-02-26 12:56) [16]

> Ega23 © (26.02.08 12:53) [15]

вроде есть свои встроенные средства защиты коммуникационных каналов, зависит от субд. а вообще обычно сервер на localhost"е находится.

← →
Ega23 © (2008-02-26 12:58) [17]

> а вообще обычно сервер на localhost"е находится.

Вот как раз возможен вариант его нахождения где-то в другом месте. Вероятность небольшая, но тем-не-менее...

← →
Ega23 © (2008-02-26 12:59) [18]

> вроде есть свои встроенные средства защиты коммуникационных
> каналов, зависит от субд.

Ткни в ссылочку, если есть...

← →
DiamondShark © (2008-02-26 13:01) [19]

> Kerk © (26.02.08 12:25) [10]
>
> > Ega23 © (26.02.08 12:17) [8]
>
> Special For You :)
> http://forum.antichat.ru/thread47802.html

За что ты его так?

> Kerk © (26.02.08 12:26) [11]
> Но как основное средство защиты - это ничего не меняет.
> Какая разница злоумышленнику, что перехватывать? Пароль
> или его хэш? Всяко, что поймал, то и передаешь серверу для
> авторизации.

Дык, это не так делается!
Ясен пень, если передаётся хэш только пароля, то это монопенисуально передаче самого пароля.
Обычно делается некое подобие challenge/response протокола.

1. Клиент с формой авторизации получает многобайтную случайную последовательность (challenge), сервер запоминает challenge в сессии клиента.
2. Клиент шифрует challenge, используя в качестве ключа хэш пароля.
3. Клиент передаёт имя и зашифрованный challenge.
4. Сервер по имени добывает из базы хэш пароля, шифрует challenge и сравнивает с полученным от клиента.

Этот метод сносно защищает пароль, но не защищает от перехвата сессии.

← →
DiamondShark © (2008-02-26 13:04) [20]

> Ega23 © (26.02.08 12:53) [15]

За всех не скажу, но MSSQL умеет шифровать трафик.
Оракл, вроде бы, тоже.

Есть другой вариант: поверх открытого TCP канала поднимаешь какой-нибудь защищённый VPN, а уже по виртуальному каналу коннектишься к SQL-серверу.

← →
palva © (2008-02-26 13:05) [21]

> Ega23 © (26.02.08 12:53) [15]
> Так, с хэшированием понятно, дальше сам разберусь, всем спасибо!

Не надо передавать хэш. Это создаст дополнительную уязвимость.
Надо передавать сам пароль. Только под https.

← →
Kerk © (2008-02-26 13:07) [22]

> DiamondShark © (26.02.08 13:01) [19]
> Дык, это не так делается!

Проще и надежнее заюзать SSL, чем делать то, что ты описал :)

← →
Reindeer Moss Eater © (2008-02-26 13:09) [23]

Этот метод сносно защищает пароль, но не защищает от перехвата сессии.

Можно и сессию защитить если в полный рост использовать diggest авторизацию (nonce, ncount, etc)
Но шттпс конечно же проще.

← →
BiN © (2008-02-26 13:14) [24]

> Ega23 © (26.02.08 11:38)

Олег, в промышленных масштабах ssl предпочтительнее, хотя его использование несколько влияет на производительность. Помимо защиты данных здесь еще играет роль фактор однозначной идентификации сервера. К тому же инженерная часть работы всегда обходится дешевле, чем разработка, пусть и на js. Настройка узла iis для работы с ssl занимает пару минут при наличии корректного сертификата.
А что касается шифрования трафика между субд и клиентом.. Ты же вроде как делаешь трехзвенку, то есть клиент у тебя не подключается напрямую к базе, нет?

← →
DiamondShark © (2008-02-26 13:14) [25]

> Проще и надежнее заюзать SSL, чем делать то, что ты описал
> :)

Для SSL гравицапа нужна.

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

А так конечно, проще и надёжнее, кто ж спорит.

> А что касается шифрования трафика между субд и клиентом.
> . Ты же вроде как делаешь трехзвенку, то есть клиент у тебя
> не подключается напрямую к базе, нет?

Ну "клиентом" в данном случае WebServer выступает. В принципе это дело с одной стороны несколько параноидально - шифровать траффик между AppServer и СУБД, с другой стороны прецедент всё-таки может быть и против него не попрёшь.
Что касается общения между клиентом (браузером) и WebServer-ом, то, по всей видимости, действительно SSL проще всего использовать...

> Тока не зажимайте $100 на сертификат от VeriSign. Чтоб уж
> совсем по взрослому :)

Ну это уже не я решаю. Но есть сильное подозрение, что с этим всё в порядке будет...

← →
Пробегал... (2008-02-26 13:30) [29]

clickmaker © (26.02.08 12:14) [7]
PS. в любом случае рекомендовал бы передавать уже хэш пароля

clickmaker © (26.02.08 12:20) [9]
средствами языка, на котором пишется страница.
в php - MD5(), SHA1(), к примеру

Ну ты хоть думай то, что пишешь ;)

Kerk © (26.02.08 12:26) [11]
Какая разница злоумышленнику, что перехватывать? Пароль или его хэш? Всяко, что поймал, то и передаешь серверу для авторизации.

ну в случае MD5 да. Поэтому надо копать в сторону Kerberos ;)

> Ega23 © (26.02.08 13:18) [26]
>
>
> Ну "клиентом" в данном случае WebServer выступает. В принципе
> это дело с одной стороны несколько параноидально - шифровать
> траффик между AppServer и СУБД, с другой стороны прецедент
> всё-таки может быть и против него не попрёшь.

Например, настройка шифрования для MSSQL подробно описана в поставляемой документации aka Books Online. Статья Encrypting Connections to SQL Server. Кстати, доступна и русская версия books online.

> то web-защиту курежит...

Скорее наоборот... :)

> Например, настройка шифрования для MSSQL подробно описана
> в поставляемой документации aka Books Online. Статья Encrypting
> Connections to SQL Server. Кстати, доступна и русская версия
> books online.
>

Тут вот какое дело... Для конкретной СУБД вполне вероятно это и есть. Про MSSQL знаю точно, про Oracle - не знаю (но скорее всего - тоже есть), про Postgres ничего сказать не могу. Хотелось бы какой-нибудь стандартный механизм, типа ODBC->Strong Encryption
Но на ODBC нельзя заложиться, т.к. не исключен вариант нахождения Веб-Сервера под *никсом.
Вобщем, пока кроме какого-то своего сервиса пока в бошку ничего не лезет... :(

> Ты там куда вляпался?

:)
Действительно интересно
И к тому же ветка про "однокласники"... то бишь - как из ничего чего-нибудь утащить :))

Олег, сухари то хоть насушены? :)

> Ega23 © (26.02.08 13:38) [32]

> про Postgres ничего сказать не могу

В 8х SSL включается.

> Но на ODBC нельзя заложиться, т.к. не исключен вариант нахождения
> Веб-Сервера под *никсом.

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

Так, едем дальше.
Ну вот прописал я в httpd.conf
LoadModule ssl_module modules/mod_ssl.so

А что я должен увидеть? при наличии сертификата я смогу зайти на localhost и через http и через https ?

Шифрование данных для Web-Server а Найти похожие ветки