| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Хранение и передача пароля [D7, WinXP]
Bruce © (2005-11-12 15:00:00)Привет всем.
Итак дано: программа клент и программа сервер, чтобы клиенту работать с сервером необходимо авторизоваться на нём. На сервере установлен пароль, хэш котрого храниться в реестре.
Теперь пошли неясности.
Передачу пароля на сервер при соединении я защищаю шифрованием открытым ключём, при этом после обмена ключами я посылаю на сервер зашифрованый пароль, может нужно посылать хэш?
Далее, как и в каком виде на клиентехранить пароли (или их хэши???) чтобы обеспечить опцию "Сохранять пароль", т.е. чтобы пользователю не приходилось вводить каждый раз пароль заново?
Спасибо.
Reindeer Moss Eater (2005-11-14 09:16:00) [1]А если посылать хэш, то это лишит смысла использование хэша при хранении. Взломщик узнает хэш и фактически это и будет паролем.
Хеш открытого пароля + инициализирующий вектор будет делать то же самое. И файктически в реальных системах именно так и делается.
Клиент не шифрует пароль, а использует хеш.
palva (2005-11-14 00:07:00) [2]> может нужно посылать хэш?
А какой смысл посылать хэш? Для борьбы с перехватом пароля используется шифрование. А хэш нужен для хранения пароля на сервере, чтобы взломщику сервера не досталась парольная база клиентов.
А если посылать хэш, то это лишит смысла использование хэша при хранении. Взломщик узнает хэш и фактически это и будет паролем.
Далее, никакого обмена ключами быть не должно. Открытый ключ сервера должен быть опубликован на сервере и надежно, без риска подмены, должен быть доставлен клиенту. В начале сеанса клиент получает от сервера случайный код, который приписывает к своему паролю и получившуюся строку шифрует открытым ключом сервера. Тогда перехватчик не сможет повторно использовать передаваемый зашифрованный пароль. Получив пароль, сервер расшифровывает его, отбрасывает случайный код, хэширует и сравнивает со своим хэшем.
Reindeer Moss Eater (2005-11-13 21:12:00) [3]>Где?
Bruce (12.11.05 15:00)
Теперь пошли неясности.
Передачу пароля на сервер при соединении я защищаю шифрованием открытым ключём, при этом после обмена ключами я посылаю на сервер зашифрованый пароль, может нужно посылать хэш?
Bruce (2005-11-13 19:40:00) [4]
> Набережных С. © (13.11.05 19:30) [27]
Да в моём случае сеансовый ключ вообще не нужен, т.к. после удачного процесса авторизации, клиент получает идентификатор сессии, и пользуется им до конца сеанса. А данные не шифруются.
В будущем будет шифроваться всё, вот тогда сеансовый ключ пригодиться.
Спасибо всем за участие, многое прояснилось.
Набережных С. (2005-11-13 19:32:00) [5]О, а ссылку-то забыл вставить:( Вот так имелось в виду:
Ну вот хоть это, например: http://algolist.manual.ru/defence/well_known/rsa.php
Набережных С. (2005-11-13 19:30:00) [6]
> Точно имхо. Открытый ключ для шифрования не применяется.
Да? Хм, а у меня другие сведения:( Вы бы набрали в каком-нибудь поисковике "ассиметричный ключ" или "RSA", да и почитали бы на досуге. Ну вот хоть это, например. Ну или книжку какую. Да и ИМХО иногда к своим словам не плохо бы добавлять, а то у общественности может сложиться нелестное мнение о Вас, ага.
Вот что верно, так это насчет медлительности RSA. Но в качестве сеансового и симметричный сгодится, если его каждый раз заново генерить и обмениваться, эашифровав ассиметричным.
Bruce (2005-11-13 19:30:00) [7]Открытый ключ применяется для шифрования.
Bruce (2005-11-13 19:27:00) [8]
> Reindeer Moss Eater © (13.11.05 19:14) [24]
> Вначале ветки ты говорил открытым текстом, что у тебя посылается
> либо хеш пароля, либо зашифрованный пароль.
Где?
> Передачу пароля на сервер при соединении я защищаю шифрованием
> открытым ключём, при этом после обмена ключамия посылаю
> на сервер зашифрованый пароль, может нужно посылать хэш?
>
Reindeer Moss Eater (2005-11-13 19:14:00) [9]Не получиться, уникальная пара ключей генерируется при каждом запуске сервера и при запуске клиента. На сервере после авторизации клиента открытый ключ этого клиента храниться в паре с его IP.
Вначале ветки ты говорил открытым текстом, что у тебя посылается либо хеш пароля, либо зашифрованный пароль.
Reindeer Moss Eater (2005-11-13 19:12:00) [10]> Открытый ключ для шифрования не применяется.
Вот как раз для шифрования он и применяется.
Virgo_Style (2005-11-13 19:06:00) [11]tesseract © (13.11.05 18:55) [20]
Открытый ключ для шифрования не применяется.
Он применяется только для дешифрования.
Ну... так выпьем же за то, чтобы наши враги открывали ключи, используемые для дешифровки...
Bruce (2005-11-13 19:03:00) [12]
> tesseract © (13.11.05 18:55) [20]
Прверял на athlon 650 MHz - около 4 секунд. На атлоне 2000 - секунда.
ключ - 256.
tesseract (2005-11-13 18:55:00) [13]
> Все, разумеется, имхо.
Точно имхо. Открытый ключ для шифрования не применяется.
Он применяется только для дешифрования.
> Не получиться, уникальная пара ключей генерируется при каждом
> запуске сервера и при запуске клиента.
Типа нажал "OK" и ушёл чай пить на 30 мин ? Генерация ключа RSA довольно длительный процесс.
приведённый мной алгоритм используется в GSM/Netware. Пока не взломан.
Bruce (2005-11-13 18:47:00) [14]
> Набережных С. © (13.11.05 18:32) [18]
> Если требуется не только гарантия аутентификации
Пока что требуется только гарантия аутентификации. Но в дальнейшем учту ваше замечание.
Набережных С. (2005-11-13 18:32:00) [15]
> Reindeer Moss Eater © (13.11.05 16:35) [14]
Ну извини:)) Мне следовало адресовать [12] не тебе, а автору вопроса.
> Bruce (13.11.05 18:05) [16]
> уникальная пара ключей генерируется при каждом запуске сервера
> и при запуске клиента. На сервере после авторизации клиента
> открытый ключ этого клиента храниться в паре с его IP.
А как происходит обмен открытыми ключами? Имхо, если некто перехватит оба открытых ключа, и сервера, и клиента, в момент обмена, то вся защита накроется.
Преимущество ассиметричного шифрования при аутентификации в том, что открытый ключ можно свободно опубликовать, при условии, что закрытая часть недоступна за пределами сервера.
Если требуется не только гарантия аутентификации, но и защищенный обмен данными, то после аутентификации клиент действительно может сгенерить новый ключ и открытую часть передать серверу, зашифровав ее открытым ключом сервера.
Но сама-то аутентификация должна защищаться единожды опубликованным открытым ключом сервера, одним для всех клиентов. И вот тут-то и необходимо обеспечить уникальность аутентификационного пакета в каждом сеансе, о чем и говорил Reindeer Moss Eater ©.
Все, разумеется, имхо.
Bruce (2005-11-13 18:08:00) [16]
> tesseract © (13.11.05 17:33) [15]
> ЗЫ RSA: ты там золото партии хранишь?
Не! Даже данные будут пока что отсылаться в открытом виде... в моём случае главное безопасность при авторизации и хранение пароля на клиентах, конечно пользователь может и не ставить галочку (запомнить пароль), до думаю большенство будет лениться каждый раз вводить пароль заново.
Bruce (2005-11-13 18:05:00) [17]
> Reindeer Moss Eater © (13.11.05 02:44) [9]
> Какая разница-то?
>
> Я перехвачу твой зашифрованный пароль и завтра подсуну твоему
> серверу в зашифрованном виде. И он его примет.
Не получиться, уникальная пара ключей генерируется при каждом запуске сервера и при запуске клиента. На сервере после авторизации клиента открытый ключ этого клиента храниться в паре с его IP.
> Набережных С. © (13.11.05 12:52) [13]
Спасибо, возможно воспользуюсь таким вариатом.
А какие слабые звенья есть в описаном мною выше варианте?
tesseract (2005-11-13 17:33:00) [18]Безопасный метод аутентификации :
Клиент запрашивает сервер.
Сервер генерирует СЛУЧАЙНУЮ (random не рекомедуется) последовательность чисел и отправляет клиенту.
Клиент принимает случайную последовательность чисел. Зашифровывает её своим ключом и отправляет серверу.
сервер проверяет ключ и генеририрует ключ сеанса стратующий гамму псевдослучайных чисел и отпраляет ей клиенту.
ЗЫ RSA: ты там золото партии хранишь?
Reindeer Moss Eater (2005-11-13 16:35:00) [19]Ну мне -то не надо объяснять как этого избежать.
Здесь некоторые до сих пор не поняли, что нет никакой разницы с точки зрения безопастности что передавать серверу: открытый пароль, зашифрованный пароль или хеш пароля.
Абсолютно никакой разницы нет.
И если серверу передается зашифрованный пароль, или хеш пароля, то мне не надо откапывать открытый пароль что бы авторизоваться не сервере.
Перехватив сеанс регистрации, я в любом из трех вышеперечисленных случаев сам смогу авторизоваться на таком сервере.
Набережных С. (2005-11-13 12:52:00) [20]Можно даже усложнить:
1. Клиент(К.) подключается к серверу(С.) и без аутентификации запрашивает у него уникальную метку.
2. С. генерит метку, запоминает ее, и в зашифрованном виде отдает К.
3. К. расшифровывает метку, вставляет ее в пакет вместе с хешем своего пароля и отправляет на С.
4. С. расшифровывает пакет, сравнивает метку с запомненной и при совпадении сверяет хеш пароля. А при несовпадении меток сразу дает отлуп.
В общем, постепенно приближаемся к Kerberos:))
| |
Страницы: 