Как безопасно внедрить автоматический вход

15

Я прочитал много, много, много постов о том, что «вы, вероятно, храните пароли неправильно». Они всегда имеют в виду хранение паролей на сервере, на который входит пользователь; они в основном перефразируют (каламбур) повсеместно распространенные советы, такие как неукоснительное использование паролей и т. д. и т. д. Однако я никогда не видел статьи о передовых методах хранения паролей на клиенте, чтобы клиенту не приходилось входить в систему. вручную каждый раз, когда они хотят войти; функция "запомнить меня".

Многие программы имеют эту функцию, от браузеров до таких программ, как Dropbox.

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

Я даже не уверен, как избежать хранения чего-то вроде куки в виде обычного текста. Если вы шифруете его, где вы храните ключ для его расшифровки?

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

Что можно прочитать о безопасном локальном хранении учетных данных для реализации функции автоматического входа? Если принципы слишком просты для всей статьи, каковы они? Рассматриваемое программное обеспечение не должно зависеть от функций, присутствующих не на всех платформах (как, например, «связка ключей» в некоторых дистрибутивах Linux).

security login

— Джей Саймон
источник

2

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

— Люк Франкен

@LucFranken как ты можешь доверять машине? Кто-то может использовать вас, как они сделали Dropbox. Также я бы доверял брелку, но не на всех компьютерах он есть, а в Windows его нет (AFAIK). И если вы храните пароли, как вам избежать их хранения в открытом виде? Если вы их зашифруете, то где храните ключ для его расшифровки?

— Джей Саймон

Это как раз та проблема, которой нельзя доверять. Пользователь может только определить, чтобы доверять ему. Это учитывает, что пользователь понимает, насколько безопасна его машина. Написать вирус, получающий данные из Dropbox, просто возможно. То же самое с локально хранящимися ключами и другими локальными данными. Вы можете помочь сделать его более безопасным (подумайте о приложениях, для которых требуется 5-значный код), но, в конце концов, он локальный и вне вашего контроля.

— Люк Франкен

@LucFranken это только у меня или аутологин кажется вездесущей функцией? Если это так, то почему люди не написали о том, как это сделать правильно?

— Джей Саймон

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

— Люк Франкен

12

Одним из способов является:

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

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

Обратите внимание, что, поскольку протокол HTTP в любом случае не имеет состояния, на самом деле нет никакой функциональной разницы между тем, чтобы кто-то вошел в систему во время одного сеанса использования веб-сайта, и "автоматическим входом в систему" при следующем использовании сайта; это зависит только от того, сколько времени вы дадите до истечения сеанса.

Обновление: также, очевидно, используйте HTTPS для повышения безопасности.

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

1

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

— Джей Саймон

2

@JaySimon, я бы не сказал "не очень помогает". Количество компьютеров за тем же брандмауэром, что и у вас, значительно меньше, чем количество компьютеров в мире. Речь идет об ограничении вашего потенциального воздействия на атаку, и это сильно ограничивает его. Это стандартный подход, и я действительно не думаю, что вы можете многое сделать за его пределами. Если кто-то имеет тот же IP-адрес, что и пользователь, и ему удается получить идентификатор сеанса, этот человек будет неотличим от пользователя с точки зрения сервера. Если у вас есть какой- либо вход в систему на вашем сайте, вы подвергаетесь такой атаке.

3

Как вы думаете, такой подход будет раздражать пользователей мобильных телефонов, чьи IP-адреса могут часто меняться?

— Джей Саймон

@JaySimon, если бы это произошло в течение сеанса, пользователь воспримет это как внезапный выход из системы, что, безусловно, будет раздражать. Я не знаю, как часто они на самом деле меняются (быстрый поиск в Google не дает однозначного ответа). Я не стал бы слишком беспокоиться об этом, если бы IP не мог измениться, когда они фактически использовали это.

Ограничение сессии IP не очень реалистично, как сказано. Пользователи часто меняют местоположение. С мобильными телефонами, а также с ноутбуками; например гибкий рабочий. Лучшее, что вы можете сделать, - это несколько проверок GeoIP в сочетании со временем прохождения этого расстояния; как делает Gmail.

— Лоде

5

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

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

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

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

— Эрик Г
источник

2

На самом деле это не так сложно. Сначала сохраните куки в этом формате:

userID.token

Вы можете использовать хэш sha1 для токена. Затем в вашем userID хранилища таблицы базы данных Remember_me_tokens, хеш токена bcrypt и время его создания.

Затем, когда кто-то посещает ваш сайт, проверьте, установлен ли файл cookie. Если файл cookie установлен, проверьте, есть ли в базе данных действительная строка в течение последних 7 дней. Если в базе данных есть допустимая строка для cookie, установите сеанс, чтобы указать, что пользователь вошел в систему, а также удалите соответствующую строку cookie / базы данных и сгенерируйте новую строку cookie / token / database.

Если они выйдут из системы, удалите куки.

Запустите задание cron, чтобы обрезать Remember_me_tokens старше 7 дней.

— Райан
источник

Что мешает кому-либо скопировать этот ключ и вставить на свой компьютер и получить доступ к учетной записи без имени пользователя или пароля?

— Джей Саймон

как ты собираешься получить ключ? он хранится локально на чьем-то компьютере.

— Райан

вы подходите к компьютеру и открываете файл, в котором он хранится :)

— Jay Simon

2

@JaySimon Тот же аргумент может быть использован для тех, кто входит в систему и уходит в течение 5 минут, не блокируя свой компьютер, или нажимает кнопку «Запомнить меня», и кто-то нажимает на пароль своей учетной записи. Если вы можете принять эту возможную ситуацию безопасности, то удобство ее приятно, но именно поэтому вы не видите функцию «Запомнить меня» в списке CIA NOC :) Сервер должен выдать вам какой-то токен, который должен хранить клиент в файловой системе. Это больше не в ваших руках с точки зрения сервера, хотя.

— maple_shaft

@maple_shaft, почему кто-то был удивлен, что ты мог сделать это с Dropbox? (Я связал это в своем вопросе.)

— Джей Саймон

0

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

Как указано в комментариях:

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

— Люк Франкен
источник