Хранение и передача пароля

← →
Bruce (2005-11-12 15:00) [0]

Привет всем.

Итак дано: программа клент и программа сервер, чтобы клиенту работать с сервером необходимо авторизоваться на нём. На сервере установлен пароль, хэш котрого храниться в реестре.

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

Далее, как и в каком виде на клиенте хранить пароли (или их хэши???) чтобы обеспечить опцию "Сохранять пароль", т.е. чтобы пользователю не приходилось вводить каждый раз пароль заново?

Спасибо.

← →
tesseract © (2005-11-12 21:01) [1]

Протокол авторизации случайно не kerberos?

> Далее, как и в каком виде на клиенте хранить пароли (или
> их хэши???)

Хранение паролей по любому не безопасно. попробуй RC4 - он достаточно шустёр и безопасен.

← →
Bruce (2005-11-12 21:08) [2]

> tesseract © (12.11.05 21:01) [1]

> Протокол авторизации случайно не kerberos?

Нет, протокл сам делал, использую RSA.

> Хранение паролей по любому не безопасно. попробуй RC4 -
> он достаточно шустёр и безопасен.

Т.е. как я понимаю, нужно хранить хэши паролей, а не пароли даже на клиентах и передавать при аторизации хэш?

← →
Bruce (2005-11-12 22:24) [3]

Если вопрос не совсем понятен - уточню.
Каким образом храняться пароли в IE, Opera и т.п. очевидно, что хранятся не хэши, а именно пароли, но как максимально их скрыть от "взлома". Может зашифовать какой-нибудь фиксированной passphrase?

← →
DrPass © (2005-11-12 22:33) [4]

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

Обычно посылается хеш - сервер просто сравнивает его со своим хешем.

> Далее, как и в каком виде на клиенте хранить пароли (или
> их хэши???) чтобы обеспечить опцию "Сохранять пароль"

Если требования к безопасности настолько низкие, что допускается сохранение пароля... то не все ли равно, как он будет храниться и передаваться?

← →
Bruce (2005-11-12 22:35) [5]

> DrPass © (12.11.05 22:33) [4]

> Если требования к безопасности настолько низкие, что допускается
> сохранение пароля... то не все ли равно, как он будет храниться
> и передаваться?

Требования не больши чем в том же IE или аське.

> Обычно посылается хеш - сервер просто сравнивает его со
> своим хешем.

Так и сделаю!

← →
Reindeer Moss Eater © (2005-11-13 00:10) [6]

> Обычно посылается хеш - сервер просто сравнивает его со
> своим хешем.

Так и сделаю!

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

← →
Bruce (2005-11-13 00:53) [7]

> Reindeer Moss Eater © (13.11.05 00:10) [6]

Так в [0] я же написал, что пароль, во время передачи, зашифрован алгоритмом с открытым ключём....

← →
DrPass © (2005-11-13 00:54) [8]

> Reindeer Moss Eater © (13.11.05 00:10) [6]

Ну и что? В случае
> Требования не больши чем в том же IE или аське.

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

← →
Reindeer Moss Eater © (2005-11-13 02:44) [9]

Так в [0] я же написал, что пароль, во время передачи, зашифрован алгоритмом с открытым ключём....

Какая разница-то?

Я перехвачу твой зашифрованный пароль и завтра подсуну твоему серверу в зашифрованном виде. И он его примет.

Ну и что? В случае
> Требования не больши чем в том же IE или аське.

Я и сказал, что можно с тем же самым успехом clear password передавать.
Уровень безопастности от этого не уменьшится ни на грамм.

← →
DrPass © (2005-11-13 02:56) [10]

> Reindeer Moss Eater © (13.11.05 02:44) [9]

> Я и сказал, что можно с тем же самым успехом clear password
> передавать

Смысл хеша в данном случае состоит не в том, чтобы от хацкера скрыться, а чтобы не дать юзеру посмотреть пароль в открытом виде в базе данных/реестре

← →
Anatoly Podgoretsky © (2005-11-13 12:17) [11]

Reindeer Moss Eater © (13.11.05 02:44) [9]
А чтобы этого не произошло, надо обмениваться уникальными открытыми ключами.

← →
Набережных С. © (2005-11-13 12:38) [12]

> Reindeer Moss Eater © (13.11.05 02:44) [9]
> Так в [0] я же написал, что пароль, во время передачи, зашифрован
> алгоритмом с открытым ключём....
>
>> Какая разница-то?
>
> Я перехвачу твой зашифрованный пароль и завтра подсуну твоему
> серверу в зашифрованном виде. И он его примет.

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

← →
Набережных С. © (2005-11-13 12:52) [13]

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

В общем, постепенно приближаемся к Kerberos:))

← →
Reindeer Moss Eater © (2005-11-13 16:35) [14]

Ну мне -то не надо объяснять как этого избежать.
Здесь некоторые до сих пор не поняли, что нет никакой разницы с точки зрения безопастности что передавать серверу: открытый пароль, зашифрованный пароль или хеш пароля.
Абсолютно никакой разницы нет.
И если серверу передается зашифрованный пароль, или хеш пароля, то мне не надо откапывать открытый пароль что бы авторизоваться не сервере.
Перехватив сеанс регистрации, я в любом из трех вышеперечисленных случаев сам смогу авторизоваться на таком сервере.

← →
tesseract © (2005-11-13 17:33) [15]

Безопасный метод аутентификации :

Клиент запрашивает сервер.
Сервер генерирует СЛУЧАЙНУЮ (random не рекомедуется) последовательность чисел и отправляет клиенту.
Клиент принимает случайную последовательность чисел. Зашифровывает её своим ключом и отправляет серверу.
сервер проверяет ключ и генеририрует ключ сеанса стратующий гамму псевдослучайных чисел и отпраляет ей клиенту.

ЗЫ RSA: ты там золото партии хранишь?

← →
Bruce (2005-11-13 18:05) [16]

> Reindeer Moss Eater © (13.11.05 02:44) [9]

> Какая разница-то?
>
> Я перехвачу твой зашифрованный пароль и завтра подсуну твоему
> серверу в зашифрованном виде. И он его примет.

Не получиться, уникальная пара ключей генерируется при каждом запуске сервера и при запуске клиента. На сервере после авторизации клиента открытый ключ этого клиента храниться в паре с его IP.

> Набережных С. © (13.11.05 12:52) [13]

Спасибо, возможно воспользуюсь таким вариатом.

А какие слабые звенья есть в описаном мною выше варианте?

← →
Bruce (2005-11-13 18:08) [17]

> tesseract © (13.11.05 17:33) [15]

> ЗЫ RSA: ты там золото партии хранишь?

Не! Даже данные будут пока что отсылаться в открытом виде... в моём случае главное безопасность при авторизации и хранение пароля на клиентах, конечно пользователь может и не ставить галочку (запомнить пароль), до думаю большенство будет лениться каждый раз вводить пароль заново.

← →
Набережных С. © (2005-11-13 18:32) [18]

> 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:47) [19]

> Набережных С. © (13.11.05 18:32) [18]

> Если требуется не только гарантия аутентификации

Пока что требуется только гарантия аутентификации. Но в дальнейшем учту ваше замечание.

← →
tesseract © (2005-11-13 18:55) [20]

> Все, разумеется, имхо.

Точно имхо. Открытый ключ для шифрования не применяется.
Он применяется только для дешифрования.

> Не получиться, уникальная пара ключей генерируется при каждом
> запуске сервера и при запуске клиента.

Типа нажал "OK" и ушёл чай пить на 30 мин ? Генерация ключа RSA довольно длительный процесс.

приведённый мной алгоритм используется в GSM/Netware. Пока не взломан.

← →
Bruce (2005-11-13 19:03) [21]

> tesseract © (13.11.05 18:55) [20]

Прверял на athlon 650 MHz - около 4 секунд. На атлоне 2000 - секунда.
ключ - 256.

← →
Virgo_Style © (2005-11-13 19:06) [22]

tesseract © (13.11.05 18:55) [20]
Открытый ключ для шифрования не применяется.
Он применяется только для дешифрования.

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

>Открытый ключ для шифрования не применяется.

Вот как раз для шифрования он и применяется.

Не получиться, уникальная пара ключей генерируется при каждом запуске сервера и при запуске клиента. На сервере после авторизации клиента открытый ключ этого клиента храниться в паре с его IP.

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

← →
Bruce (2005-11-13 19:27) [25]

> Reindeer Moss Eater © (13.11.05 19:14) [24]

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

Где?

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

← →
Bruce (2005-11-13 19:30) [26]

Открытый ключ применяется для шифрования.

> Точно имхо. Открытый ключ для шифрования не применяется.

Да? Хм, а у меня другие сведения:( Вы бы набрали в каком-нибудь поисковике "ассиметричный ключ" или "RSA", да и почитали бы на досуге. Ну вот хоть это, например. Ну или книжку какую. Да и ИМХО иногда к своим словам не плохо бы добавлять, а то у общественности может сложиться нелестное мнение о Вас, ага.

Вот что верно, так это насчет медлительности RSA. Но в качестве сеансового и симметричный сгодится, если его каждый раз заново генерить и обмениваться, эашифровав ассиметричным.

О, а ссылку-то забыл вставить:( Вот так имелось в виду:
Ну вот хоть это, например: http://algolist.manual.ru/defence/well_known/rsa.php

← →
Bruce (2005-11-13 19:40) [29]

> Набережных С. © (13.11.05 19:30) [27]

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

Спасибо всем за участие, многое прояснилось.

>Где?

Bruce (12.11.05 15:00)
Теперь пошли неясности.
Передачу пароля на сервер при соединении я защищаю шифрованием открытым ключём, при этом после обмена ключами я посылаю на сервер зашифрованый пароль, может нужно посылать хэш?

> может нужно посылать хэш?

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

А если посылать хэш, то это лишит смысла использование хэша при хранении. Взломщик узнает хэш и фактически это и будет паролем.

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

А если посылать хэш, то это лишит смысла использование хэша при хранении. Взломщик узнает хэш и фактически это и будет паролем.

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

Хранение и передача пароля Найти похожие ветки