Как усилить безопасность аутентификации на сайте?

Question

[Денис]

Здравствуйте!
Для начала, опишу вкратце то, что есть:

• имеется небольшая, самописная, уже действующая CRM-системка
  
• работает по http-протоколу
  
• пароли шифруются по алгоритму CRYPT_BLOWFISH
  
• после аутентификации, генереруется случайный хэш, который записывается в БД, сессию и на клиенте в localStorage для добавления ко всем ajax-запросам. При кадом запросе хэши сверяются.
  

Главное, что беспокоит хозяина - это передача пароля в открытом виде, но SSL он ставит в конец очереди возможных решений. На данный момент, я пока нашел на просторах инета единственный вариант - шифрование пароля на стороне клиента (например, в этой статье), но т.к. я никогда с этим не сталкивался, то сложно представляю алгоритм такого сценария, который можно прикрутить к уже работающей системе и не знаю насколько это будет эффективно, если это обратимое шифрование. В общем, интересует то, по какому бы пути двигались вы, есть ли смысл от шифрования пароля на клиенте и какие есть альтернативные решения? И еще один попутный вопрос - а вообще, насколько опасна передача пароля в открытом виде?

Answer 1

[He11ion]

Без SSL(TLS) все навороты - бесполезная трата времени или защита от дурака, на выбор.
Система весьма уязвима к перехвату хэша, идущего простым текстом - узнал хэш - получил доступ к админке, как это сделать - вариантов масса.

Comments

[Денис]

Спасибо, будем стараться переубедить.

[Денис]

He11ion , vilgeforce, Николай Петюх и другие читающие... В общем, похоже, что мне удалось переубедить клиента в необходимости использования SSL. Вопрос теперь в том, а нужно ли что-то менять при этом в существующем алгоритме аутентификации, который я описывал в вопросе? Надо ли что-то добавить/убрать или при использовании SSL можно оставить "как есть"?

[He11ion]

Денис: Нет, у Вас и так описана более-менее стандартная схема работы сессий в том же php, например. Если хэш случайный, а не просто md5 от пароля, скажем, то проблем я не вижу. Разве что сделать безусловный редирект всех запросов с хешем на https

[Денис]

Николай Петюх , спасибо. И правильно ли я понимаю, что при использовании SSL, отпадает необходимость в постоянной идентификации пользователя при каждом запросе, после прохождения им аутентификации? Как я писал выше, там при любом запросе идет сравнение хэша из сессии с хэшем в БД. Есть ли необходимость в этом "телодвижении" или достаточно проверять наличие сесси?

[Денис]

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

[Денис]

Николай Петюх , я так понимаю, что речь идёт о:

session_set_cookie_params(0, '/', 'mydomen.com', true, true);

И всем еще раз большое спасибо за советы.

Answer 2

[Владимир Мартьянов]

"генереруется случайный хэш" - имея только этот хэш можно успешно выдать себя за другого клиента?

Comments

[Денис]

Это всё-таки вопрос или утверждение? )

[Владимир Мартьянов]

Денис: Все-таки вопрос, там вопросительный знак в конце :-D

[Денис]

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

[Владимир Мартьянов]

Денис: Если id последовательны и атакующий сможет зарегистрироваться у вас - он получит диапазон id для атаки и пример хэша. Если хэш генерится "в лоб" через rand()/mt_rand(), то в самом плохом случае атакующему нужно будет провести не более 4 млрд попыток авторизации для выбранного id. В общем, генерация "хэша" может быть очень слабым местом.

[Денис]

Регистрации нет. Точнее - нет открытой регистрации, босс конторы сам заводит аккаунт для сотрудника. Хэш и соль для пароля у них генерируется в таким кодом:

$salt = str_replace('+','.', substr(base64_encode(openssl_random_pseudo_bytes(17)),0,22));

Но насколько это отличается от генерирования "в лоб" - я не знаю )

[Владимир Мартьянов]

Денис: openssl в данном случае, думаю, более чем достаточен.