Сохранение учетных данных в локальном хранилище

Могу ли я безопасно использовать локальное хранилище вместо файлов cookie для хранения учетных данных сеанса?

Мне нужно сохранить зашифрованный хеш?

EDIT: будет ли это достаточно безопасным?

  • Пользователь входит в систему.

  • Сервер возвращает сообщение об успешном завершении, в том числе соленое хэширование bcrypt, имя пользователя, пароль, временную метку и, возможно, IP-адрес. Это сохраняется в локальном хранилище.

  • В будущем, когда этот хэш отправляется, сервер принимает на себя ответственность, пока IP-адрес не изменился, и срок не истек.

Ответы

Ответ 1

localstorage так же уязвим для чтения JavaScript как файлы cookie.

localstorage может быть прочитан с использованием JavaScript из того же домена, если вы контролируете все JS в домене, тогда это не должно быть проблемой. Но если какой-либо другой код выполняется (например, посредством инъекции или если вы обмениваетесь доменом с кем-то другим), они смогут получить доступ к данным хранилища.

То же самое и для файлов cookie, но обычно cookie устанавливается на HTTPOnly, поэтому JavaScript не может его прочитать.

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

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

Ответ 2

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

То, что я искал, это:

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

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

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

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

Ответ 3

Сервер должен сгенерировать некоторый токен - уникальный (для сервера) фрагмент данных, который не может использоваться для обнаружения имени пользователя/пароля. Только этот токен может храниться на пользовательской машине в любой форме. Ни localStorage, ни cookie не защищены. Таким же образом применяются к ним те же правила.

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

Ответ 4

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