Хранение учетных данных в локальном хранилище
Могу ли я безопасно использовать локальное хранилище вместо файлов cookie для хранения учетных данных сеанса?
Нужно ли хранить зашифрованный хэш?
РЕДАКТИРОВАТЬ: Это будет достаточно безопасно?
Пользователь входит в систему.
Сервер возвращает сообщение об успешном завершении, включая соленый bcrypt-хеш, смешивающий идентификатор пользователя, пароль, метку времени и, возможно, IP-адрес. Это сохраняется в локальном хранилище.
При будущих подключениях этот хэш отправляется, сервер принимает на себя ответственность, если IP-адрес не изменился, а срок не истек.
4 ответа
localstorage так же уязвим для чтения JavaScript, как и файлы cookie.
localstorage может быть прочитан с использованием JavaScript из того же домена, если вы контролируете все JS в домене, то это не должно быть проблемой. Но если любой другой код будет выполнен (например, с помощью внедрения или если вы поделитесь доменом с кем-то еще), они смогут получить доступ к данным хранилища.
Однако, это то же самое для файлов cookie, но, как правило, для файла cookie установлено значение HTTPOnly, поэтому JavaScript не может его прочитать.
В любом случае обычная текстовая информация для входа не должна храниться ни в файлах cookie, ни в локальном хранилище, так как если кто-то их заполучит, они могут непрерывно создавать новый сеанс для себя.
Вам следует зашифровать аутентифицированный идентификатор (например, его идентификатор пользователя) вместе с датой и временем истечения сеанса, а затем сохранить это значение в файле cookie или в локальном хранилище. Этот токен затем проверяется при каждом вызове сервера.
Если вы собираетесь использовать локальное хранилище, зачем хранить учетные данные пользователя или что-либо полученное из них?
То, что я искал в это:
При успешном входе в систему сгенерируйте совершенно случайную строку, не связанную с учетными данными пользователя, и сохраните ее в базе данных вместе с датой истечения срока действия. Затем я передам эту строку в js для хранения в локальном хранилище.
С тех пор, пока эти учетные данные локального хранилища соответствуют базе данных и время ожидания не истекло, я автоматически считаю, что они вошли в систему.
Таким образом, нет риска в отношении раскрытия учетных данных пользователя из локального хранилища. Однако, поскольку эта временная уникальная строка, по существу, функционирует как sessionID, вам все равно нужно будет знать и принимать меры предосторожности против рисков, связанных с перехватом сеанса.
В любом случае, я понимаю, что локальное хранилище так же безопасно, как сервер за вашим сайтом. Под этим я подразумеваю, что локальное хранилище доступно только через скрипты, поступающие через ваш собственный домен, так что вы в безопасности, пока работает только один передний код.
Ваш сервер должен сгенерировать некоторый токен - уникальный (для сервера) фрагмент данных, который нельзя использовать для обнаружения имени пользователя / пароля. Только этот токен может храниться на компьютере пользователя в любой форме. Ни localStorage, ни cookie не являются безопасными. Таким образом, к ним применяются те же правила.
У вас должны быть какие-то средства для истечения срока действия такого токена, в противном случае после того, как украденный такой токен можно будет использовать вместо реальных учетных данных.
Если вы собираетесь использовать localStorage вместо файлов cookie, вы можете сделать вещи более безопасными, чем файлы cookie. Это потому, что вам не нужно отправлять идентификатор сеанса на сервер с каждым запросом, что делает его токеном-носителем. Вместо этого вы можете хранить секретный ключ пользователя на стороне клиента в localStorage и использовать его для подписи ваших запросов в дополнение к соответствующему открытому ключу, который отправляется и используется в качестве идентификатора сеанса. Таким образом, никто на стороне сервера или прокси не сможет подделать ваши запросы.