Рационально ли использование даты в качестве соли при хешировании данных?
Мне нужно запрашивать данные со стороннего web сервера, который доступен из интернет. Доступ к серверу есть, но с весьма урезанными правами. Для проверки, что запросы исходят от меня, вместе с данными посылаю хеш, сервер тоже хеширует данные и если хеши совпадают - возвращает информацию. Вопрос: на сколько рационально использовать при хешировании дату в качестве соли? Это повысит защиту системы или понизит? Есть ли другие простые решения для проверки клиента? (Сессии не предлагать, поскольку получаю контент file_get_contents(), soap реализовывать ради одного запроса тоже не хочется)
Запрос не вносит изменений в бд, он только получает данные, которые хорошо бы защитить от лишних глаз. Так что запрос можно дублировать сколько угодно раз. Дата конечно отличается, но погрешность как правило в секундах, так что соль в виде год/мес/дата/час у сервера и клиента как правило совпадают, получается соль сама меняется каждый час. Вопрос именно в том хорошо ли это...
Дата может быть не синхронна на серверах. Используйте в качестве соли обычный пароль, т.е. передавайте хеш от (все важные данные + пароль).
Правда это не защитит вас от того, что одно и тоже сообщение передаётся два раза, это вам надо разрешать на уровне логики. Т.е. не просто передавать "пополнить счёт клиента id на $100", а "пополнить счет пользователя id на $100, id платежа id_pay". А уже на принимающей стороне проверять, что такого платежа небыло.
Получается защищенная система: сгенерировать новое валидное сообщение без пароля нельзя, послать второй раз перехваченное тоже.
Либо можете защитить связь на уровне канала с помощью сертификатов.
Запрос не вносит изменений в бд, он только получает данные, которые хорошо бы защитить от лишних глаз. Так что запрос можно дублировать сколько угодно раз. Дата конечно отличается, но погрешность как правило в секундах, так что соль в виде год/мес/дата/час у сервера и клиента как правило совпадают, получается соль сама меняется каждый час. Вопрос именно в том хорошо ли это...
Что значит "хорошо ли это"? У машины есть колеса и она может ездить, хорошо ли это? Ели вам надо ехать, то да, если переплыть море то нет. Сформулируйте критерии, которым должна удовлетворять ваша система и постройте аутификацию на её базе.
Я так понимаю вам нужно:
-передать на сервер запрос
-сервер должен удостовериться, что данные пришли от того от кого надо
-если да, то вернуть данные
-данные надо скрыть от посторонних глаз
Т.е. решить две задачи:
- аутификацию клиента
- защитить от злоумышленника передаваемые данные
Теперь давайте рассматривать ваш метод с датой:
- есть некий секретный алгоритм, без знания которого нельзя получить данные, он и будет ключем аутификации. Для получения данных необходимо знание алгоритма (то что хэш берется от даты). Без знания этого алгоритма данные не получить.
- злоумышленник разгадав (или подсмотрев) алгоритм может невозбранно генерировать новые сообщения и получать данные.
- в случае если рассинхронизация даты составляет 1 минуту, то в конце каждого часа дата в виде год/мес/дата/час будет рассинхронизирована в течении одной минуты и ваше приложение не будет функционировать
Т.е. задача аутификации клиента худо бедно решена (не считая недоступности в конце каждого часа). Эту задачу я бы решил всетаки простым секретным ключом, которые знают клиент и сервер. Т.е. передавать хэш от (данные + ключ). Если ключ стал известен злоумышленнику, его можно просто сменить.
Теперь, что защиты данных. Тут рассмотрим два случая.
Первый - вы доверяете каналу между двумя серверами (т.е. злоумышленник не может читать этот канал и отправлять в него свои сообщения), допустим он зашифрован по SSL - тогда вам не надо делать вообще ничего, защита обеспечена каналом.
Второй - вы не доверяете каналу между двумя серверами (т.е. злоумышленник может читать и отправлять сообщения по этому каналу). Тогда:
- перехватив ваш запрос он может не расшифровывая его посылать его на сервер целый час и невозбранно получать данные. Если хэшируется только дата (т.е. в хэш не входят параметры запроса) то еще и менять параметры
- с другой стороны если он может читать канал связи ему вообще не надо перехватывать ваши запросы, а можно сразу перехватывать ответы
Получается, что в условиях незащищенного канала обеспечить безопасность данных нельзя никак и вам надо использовать шифрованный канал.
Перехватив запросы злоумышленник не получит алгоритма и сможет только их дублировать, тем самым получая одни и те же данные, что не приятно, но не смертельно. Получить полный доступ к данным он сможет разгадав алгоритм. Перехватывая мои запросы или генерируя свои. Перехватывая мои он сможет только их продублировать и анализировать хэши. Вот наличие даты в хэше затруднит анализ или упростит его? Погрешность в 1-2 минуты не критична, так как сервер в интернете и логично предположить что он не всегда доступен (обрыв канала, не оплата доступа, перезагрузка).
Наличие даты, как мне кажется, особо не влияет. Использование одной только даты опасно тем, что если у вас есть несколько инсталляций для разных клиентов, то один из них откроет код, посмотрит алгоритм, и спольет данные всех остальных.
У этого подхода одни минусы, и ни одного плюса. Если уж очень хочется, я бы:
- передавал вместе с запросом таймстамп (который включался бы в хеш)
- проверял что таймстамп лежит в заданном +-интервале (решается проблема недоступности в конце часа)
- подписывал секретным ключом (хэшем) все важные данные + таймстамп.
Простой
