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

Question

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

Нужно ли мне хранить зашифрованный хеш ??

РЕДАКТИРОВАТЬ: Это будет достаточно безопасно?

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

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

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

Answer 1

localstorage так же уязвим для чтения с помощью JavaScript, как и cookie.

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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