В целом структура правильная.
Читайте про нормализацию отношений в БД.
Защитить с гарантией 100% нереально даже с аппаратными ключами. Каждый дополнительный уровень защиты лишь уменьшает вероятность взлома, но не сводит ее к 0.
При взломе сервера можно заставить принимать любые фейковые аппаратные ключи.
От влома клиента можно что-то придумывать:
Можете высылать динамический пароль в смс или еще как-то. Банки используют, видимо их такой уровень защиты устраивает.
Использовать, не знаю как называется, таблички с цифрами, которые надо вводить по определенному алгоритму (типа как grid аутентификация у LassPass)
Что поламают? Сервер не будет принимать запросы с левых IP.
Не выставляйте сервер вообще в инет. Используйте VPN, например
Если вы не в состоянии защитить серверную часть то ничего не поделаешь. Клиентскую сломать могут, да. Но серверная должна это определить.
Если б такая защита существовала, уже не было бы давно пиратского софта..
Нет, возможно, она права :)
Отзывать/менять ключ в случае компрометации.
Имея на руках и клиент и сервер, с ключами и алгоритмами работы... Никак вобщем-то не защитишь.
Привязвайте к IP..
Так не бывает :) Кавычки?
Направление верное. Что не так - нужно вникать. frame name='buffer' создан? Смотрите консоль ошибок броузера..
По какому протоколу? https?
Не совсем ясно: нужно защитить только канал передачи данных? Или что? От кого?
Защита сервера от взлома это совершенно другая задача, очень косвенно имеющая отношение к вашему ПО
Я имею ввиду, что с момента отправки данных (нажатие на кнопку) до момента фактического изменения данных на сервере (обработки запроса) пройдет некоторое время.
jquery Slider
