Организация безопасности на сайте

Всем привет! Как-то не особо углублялся в вопросы безопасности, но сейчас появилась задача, которая толкает в этом направлении. Материалы, которые находил в сети, или же писались лет пять назад, или противоречивы, или не затрагивают важных вопросов. Посему, хочу посоветоваться с сообществом.
Опишу конкретную ситуацию. Попросили меня поработать над безопасностью одного проектика:

• Есть уже работающая, небольшая и самописная CRM-системка. Как я понимаю, начинали её писать давненько и дорабатывалась разными людьми.
  
• Работает по http-протоколу
  
• Сайт не для общественного пользования, не имеет открытой системы регистрации. (босс конторы сам заводит аккаунты сотрудников)
  
• Пароли шифруются по алгоритму CRYPT_BLOWFISH
  
• PDO - для работа с БД
  
• После аутентификации, генереруется случайный хэш, который записывается в БД, сессию и на клиенте в localStorage для добавления ко всем ajax-запросам (в качестве токена). При кадом запросе хэши сверяются.
  
• На сайте единая точка входа.
  
• 99% запросов передаются с помощью Ajax и только методом POST, а всего 15 - GET-запросом. POST-запросы без Ajax-а - блокируются.
  

Я понимаю, что SSL или авторизация по СМС - это лучшие вариант, но задача состоит в том, чтоб найти альтернативные варианты. Да и сверхсложной системы безопасности там не нужно - нет банковских операций, нет личных данных пользователей или данных о счетах. Видел решения с шифрованием пароля на стороне клиента. Я может ошибаюсь, но если это обратимое шифрование, то какой от него толк?
В общем, посоветуйте как, можно услить безопасность:
1) Какие есть ощутимые уязвимости из того, что я описал выше?
2) Как можно защитить передачу пароля от клиента на сервер.
3) Как идентифицировать пользователя поле того, как аутентификация пройдена.
4) Что нужно хранить в сессиях и нужно ли проверять пользователя при каждом запросе.
Честно говоря, от избытка информации за последние два дня, я уже запутался. Интересует практически всё по этому вопросу, т.к. даже те знания, которые у меня были по безопасности, уже под сомнением.
Вопрос этот, я уже поднимал на другом форуме, но вразумительно ответа, кроме как - "только SSL" - я не получил.

Раскатайте VPN, дайте сотрудникам индивидуальные ключи и закройте доступ из внешней сети. Из внутренней офисной сети можно прозрачно маршрутизировать через тот же VPN.


Пароли шифроваться не должны. Пароли должны хэшироваться.


Видел человека, который даже через ORM умудрялся допускать SQL-инъекции. Баз кропотливого анализа кода ничего не говорит.


Необратимое.
Толк - не передаётся именно пароль пользователя, т.к. многие люди используют один пароль много где.
При MitM бесполезен.

-----
PostgreSQL DBA

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

Не просто.
Blowfish (произносится [бло́уфиш]) — криптографический алгоритм, реализующий блочное симметричное шифрование с переменной длиной ключа. (c) wiki

В использовании SSL самое главное - не использовать SSL. В нормальном случае - ни при каких условиях не использоваться SSL, но так не поддерживаются всякие ископаемые винды. Для современных - работа только через TLS. Протокол берёт на себя вектора атак MitM и прослушки соединения между сервером и клиентом, поэтому в этом месте больше что-то делать не требуется.


Сама сессия и есть случайно сгенерированная строка.

-----
PostgreSQL DBA

С этим я уже успел познакомиться и знаю, что рекомендуется TLS1.1, TLS1.2 и исключить SSLv3 и ниже, и некоторые советуют даже TLS1.0
И спасибо за ответы.

Мелкий, судя по всему система у тс крутится не у него непосредственно, а на разных хостах, и к каждой гонять по vpn тунелю дороговато будет

Например, tinc. Или ещё чего из арсенала mesh VPN поискать.

-----
PostgreSQL DBA

Blowfish - да, а CRYPT_BLOWFISH - это алгоритм хеширования на базе blowfish (но не сам blowfish в чистом виде), т.е. проще говоря это алгоритм bcrypt.

-----
self-banned

Хм, да, действительно, это хэш. Спасибо. Наплодили алгоритмов тут

-----
PostgreSQL DBA