Можно ли делать делать выборку секретных данных из бд по guid?

Question

[Вадим Некрасов]

Заходит пользователь в свой профиль изменить свои данные(e-mail, пароль и еще что-нибудь) и тут из бд делается выборка по гуиду из куки пользователя и заполняет поля в профиле. Потом он изменяет поля нажимает сохранить и все это идем в бд... Можно такое на сайте делать вообще или нет? Если нет, расскажите как делаете Вы, например(если не секрет).

Answer 1

[pi314]

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

А, вообще, детство это все... SSL с двухсторонней авторизацией - вот в чем залог счастья :)

Comments

[Вадим Некрасов]

Вообще заботиться о безопасности кук - это забота пользователя. Где хранить пароль, если не в куках? И почему абсолютно на каждом форуме говорят: "украдут куку"? Разве нам предлагал бы браузер сохранить пароль, если бы это было не безопасно?

[pi314]

Ну дык, потому и говорят, что таки крадут. А крадут по двум причинам. Во-первых, это сравнительно просто... намного проще, чем украсть пароль, сохраненный браузером. Во-вторых, к сожалению, существует еще множество систем, разработчики которых рассуждая тиким простым, но неверным образом, и не понимая, что куки для этого не предназначены, таки помещают в них "секреты". А это печальное явление вызвано, в свою очередь, недостатком знаний и логическими ошибками в рассуждениях. Например, что о безопасности кук нужно заботиться - неверно! Нужно проектировать систему так, чтоб угон кук не компромитировал безопасность системы :) Или утверждение, что это, мол, забота пользователя... рассуждать таким образом - все раво, что согласиться с тем, что люки на дорогах можно и нужно оставлять открытыми, т.к. не падать в них - это забота пешеходов. Вы бы хотели ходить по таким дорогам?
Ну, и наконец - если речь зашла о паролях... их хранить вообще нельзя нигде, кроме головы пользователя. Хранить нужно только хеш, и только в одном месте - на сервере!
Этому можно верить или не верить, однако, как говорится, незнание закона не освобождает от ответственности :)

[Вадим Некрасов]

@pi314 если не хранить пароль в куках, так значит пользователю надо будет вводить логин и пароль на каждой странице или после редиректа.

[pi314]

@vadimnekrasov нет, не значит. Когда пользователь впервые (при регистрации!) вводит пароль и отправляет его на сервер, сервер считает хеш, и сохраняет его (а не пароль) в БД. Впоследствии, когда пользователь вводит пароль (при логине), сервер снова считает хеш и сравнивает его со значением в БД. Если совпало (пользователь авторизован), сервер генерирует токен (который уже можно положить в куку) и запоминает его в сессии. Сам пароль вообще НИГДЕ не хранится. При следующем запросе сервер сравнивает значение токена в куке со значением в сессии, и если совпало - пользователь авторизован. Тогда генерируется новый токен, и т.д. по кругу, до тех пор, пока пользователь не разлогинится или сессия не закончится по таймаут. (Если же токен не совпал - сессия немедленно убивается и редирект на ввод пароля.) Таким образом время, за которое злоумышленник теоретически может угнать акк, сводится к минимуму: от получения ответа (с новым, одноразовым токеном) до следующего запроса пользователя. Угон, хоть и не исключается теоретически, но затрудняется настолько (особенно по сравнению с хранением пароля в куке), что для него уже нужны нехилая мотивация и возможности.
Это - просто пример обеспечения секюрити, адекватной уровню угрозы / ценности информации. Т.е. злоумышленнику принципиально не поможет ни угон куки, ни знание самого механизма секюрити, ни даже угон БД с сервера (!) - ему нужно еще как-то поднапрячся, чтоб угнать акк. Хранение пароля в куке - типичный пример security through obscurity. Такая система "безопасна" ровно до тех пор, пока злоумышленник не узнает, что она хранит пароль в куке :)

[Вадим Некрасов]

@pi314 храним хеш пароля в куках или сессиях который на каждой странице
сверяется с хешем в бд? А еще зачем хранить токен в куках и сессиях и все время его сравнивать между собой? И еще же нужен какой-то идентификатор в бд, чтобы делать выборку из бд, на пример для комментирования.

[pi314]

@vadimnekrasov Да нет же!

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

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

Это нужно, чтоб отличить "правильный" запрос (с токеном, который мы сами только что выдали) от "левого". Если совпадает - ОК, значит, это не "левый" запрос. Тогда генерируем новое случайное число, для следующего запроса, и т.д. Если же токен в запросе не совпадает с текущим токеном в сессии - убиваем вессию и снова требуем ввод пароля.

Ну, а идентификатор в БД - это то же ID пользователя, или username... что угодно! Его при успешном логине (в самом начале) просто сохраняем в сессии (один раз) и дальше пользуемся им для выборки из БД и т.д.

[Вадим Некрасов]

@pi314 Спасибо большое! Нигде не мог найти внятного ответа по этому поводу.

Answer 2

[Сергей Протько]

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

Comments

[Вадим Некрасов]

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

Answer 3

[Максим]

А session_id вас чем не устраивает?

Comments

[Вадим Некрасов]

Я думал об этом, но если id сессии совпадет с id другого пользователя? Или это не возможно?