Доступ к серверу с СМС-авторизацией через nginx

Question

[haik_vm]

У нас тут для клиента было необходимо организовать СМС-авторизацию.
У клиента большое веб-приложение к которому доступ осуществляется только с логином и паролем. Но кроме этого клиент захотел сделать еще и авторизацию через СМС. Влезть в приложение и встроить проверку туда возможности нет, да и паранойя клиента ставила задачу так, что без СМС-авторизации доступа к приложению не должно быть совсем. Ну что ж. Раз просят, решили делать.


На сервере поставили nginx и apache. В апаче два виртуальных хоста на разных портах. 88 и 8080. Эти порты на сервере закрыты извне.
nginx висит на порту 80, который как раз единственный открытый.

По умолчанию nginx проксирует все запросы на порт 88. Там лежит наша система СМС-авторизации. Человек вводит логин и пароль, по этой паре наше приложение получает номер телефона, отправляет на этот телефон СМС со случайно сгенерированным кодом. Пользователь получает СМС, вводит код. Наше приложение сравнивает его с тем что было отправлено, если всё ОК, то устанавливает пользователю куку AUTH. В нее устанавливает уникальную строку из 32х абсолютно случайных символа. И кроме этого бросает на диск файлик с таким же именем. После этого обновляет страницу.
Пользователя опять встречает nginx. Он берет куку, смотрит, есть ли такой файлик на диске, и если есть, то проксирует запрос пользователя уже на клиентское приложение. Кука живёт сессию. Пока есть кука, человек пользуется клиентским приложением. Если сессия кончилась, то человека опять встретит наша система авторизации.

Вот кусок конфига nginx, который отвечает за проверку:

set $flag 0;
if (-f /tmp/auth/$cookie_AUTH) {
	set $flag 1;
}
set $folder 'www';
if ($flag = 1) {
	set $folder 'wwwApp';
}
root /home/$folder;
index  index.html index.htm index.php;
location / {
	if ($flag = 1) {
		proxy_pass http://127.0.0.1:8080;
	} proxy_pass http://127.0.0.1:88;
}

Получилось так, что nginx дёргает диск на наличие файла на абсолютно каждом хите. Запрашивается ли js-ка, jpeg или что-либо другое, он всё равно каждый раз проверяет наличие файла. Хотя пользователей и немного, но решили перенести место хранения этих файлов на рам-диск, чтобы уменьшить количество обращений к диску.

С организацией такой авторизации столкнулись первый раз и придумывали велосипед сами :)
Может быть кто посоветует более красивый вариант реализации такой штуки?
Ну и есть ли какие-то прям очевидные минусы данного решения?

Answer 1

[rozhik]

Распишу подробнее.
Итак имеем 2 недостатка 1) лишняя проверка на существование файла. 2) затраты на создание этого флаг файла и очистку.

Идея здесь. Создаём хэш как

$expire = time() + 3600; //Время, на которое даём доступ
$hash = $expire.':'.md5($secret  . $expire); // Вот это шлём в куки значение

Дальше в nginx на луа, перле или модулём делаем

// Это псевдокод
list( $expire, $md5 ) = explode( $cookieValue ); 
if( $cookieValue == $expire.':'.md5($secret  . $expire) && $expire >= time() ) {
  // Авторизированы
} else {
  // Не авторизированы
}

У вышеописаной идеи есть недостаток — нужно либо иногда обновлять куку, либо ставить длинное время жизни сессии. Но обращений к диску нет.

Comments

[haik_vm]

Хм… Спасибо, будем пробовать!

[ntkt]

Удивляюсь, почему авторы модуля тупо сложили строки в хэшируемых данных.
Это же MD5, надо надежно трансформировать строку перед хэшированием!

А то в данном случае злоумышленник может, например, пробовать, заполучив как-либо хэш от (..., $expire), посчитать хэш от (..., $expire.«0») и так далее.
Ведь если нет проверки на диапазон значения $expire — что это, хотя бы, 32-битный integer — то все ОК, кука будет считаться валидной
PHP-то сейчас уже на 64-битах, берем и развлекаемся с хэшами для эпохи $evil_expire=$expire.«12345678» в далеком-далеком будущем.

[haik_vm]

Всё таки тут проблема с временем жизни.
Некоторые сотрудники будут сидеть в приложении не больше 5 минут, другие будут сидеть часами. В моём случае кука устанавливается на время сессии. Это как раз нормально, кончилась сессия — авторизация сбросилась. В вашем же примере мне действительно надо следить жизнью этой куки. Я не уверен, конечно, но не даст ли это большую задержку? Ведь на каждом хите надо не только вычислять md5 и проверять значение, но так же еще где-то нужно хранить связь между сессией и кукой, чтобы каждый раз проверять жизнь сессии и в случае чего обновить эту куку. В то время как в моём случае на каждом хите мы только обращаемся в рам-диск за наличием файла. Хотя слово «только» тут можно поставить в кавычки :)

[rozhik]

В вашем же примере мне действительно надо следить жизнью этой куки.

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

Я не уверен, конечно, но не даст ли это большую задержку?

Задержка маленькая. Вычисление md5 от сьтроки на несколько порядков быстрее проверки существования файла, и даже обращения к мэмкэшу.

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

Не нужно ничего хранить или ставить в соответствие. У Вас есть подписанная кука на время, и всё, достаточно. А по поводу обновления куки — фреймик с доступом на 88 порт её обновит.

[haik_vm]

Не нужно ничего хранить или ставить в соответствие. У Вас есть подписанная кука на время, и всё, достаточно. А по поводу обновления куки — фреймик с доступом на 88 порт её обновит.

Тогда нам придётся встраиваться в клиентское приложение, куда доступ для нас ограничен. Но спасибо, подумаем, поговорим с клиентом. Может быть получится.

Answer 2

[rozhik]

Есть модуль secure link. Базируется на тривиальной идее. Почитайте о нем. Там подписуется кука на время.

Comments

[haik_vm]

В приложение лезть никак не могу и добавлять в адрес какой-то параметр тоже никак не могу. Как почитал, то подумал, что там без параметра в урле никак не обойтись…

Answer 3

[Василий]

Еще как вариант можно читать данные из memcahe (nginx это умеет штатно) в переменную с помощью модуля eval (www.grid.net.ru/nginx/eval.ru.html‎)

Comments

[rozhik]

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

[Василий]

Я имею ввиду что это лучше чем файл…