Разговоры о "безопасности"
 

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

Вот я войду ВКонтакт, пропишу твой ник в командной строке и залезу в игру под твоим аккаунтом.
А у тебя там шмота куплено за реал на 1000 баксов.
А я его на свистульку выменяю.

....есть какой смысл ?

Ник <> id сессии. И защита с грануляцией в сутки -- это довольно смешно. :)

Там не такая схема. Секретный ключ там через флешвар никуда не передается

непонятные манипуляции с id сессии, если неприятель его узнал, то неужели он не сможет так же сформировать запрос как и вы во флеше? - сможет, смысл в том чтобы он не узнал id этой сессии

Вообще, это похоже на Керберос, рассказанный 30 раз по цепочке в режиме "глухого телефона". Т.е. защита токена временем -- идея правильная, но делается не так. :)

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

Для того, чтобы это работало, нужен еще компонент, который бы добавлялся к строке из которой получается контрольная сумма. Который бы не присылался вместе с флешварс, желательно, вообще, чтобы вводился пользователем. Тогда эти операции могут иметь смысл. Т.е. для шифрования необходимо чтобы:
- не было алгоритма позволяющего за короткое время получить исходные данные.
- зная алгоритм шифрования, но не зная всех частей, нельзя подделать результат.
Т.о. на сервере должны знать какую-то информацию, например, MD5(пароль пользователя* + идентификатор сессии). -> Клиенту присылается идентификатор сессии в каждом запросе новый -> клиент собирает из идентификатора и пароля пользователя новый хеш и отправляет на сервер -> сервер знает какой из пароля и только что высланного идентификатора сессии должен получится хеш, и его и ждет. Т.о. человек наблюдающий за общением между клиентом и сервером никогда не видит пароль (т.как в открытом виде он никогда не присылается). И, соответственно, не может подделать запрос.
* Под паролем не обязательно подразумевается непосредсвенно пароль, даже, скорее всего из других соображений безопасности лучше хранить не пароль, а опять же хеш пароля или что-то похожее, но смысла это не меняет.
Ну и даты тут ни к чему. Даже, еще хуже, если пользователь пошлет запрос в без пяти секунд полночь, а прийдет этот запрос на следующий день (а то и год), то получится вообще кнофузно.