ПРИМЕЧАНИЕ: Оглядываясь назад, я вижу много недостающих деталей и крайних случаев, которые нужно идентифицировать. Я оставляю это в этой форме, потому что я думаю, что это полезно, чтобы дать смысл этого (даже если детали не совсем сформированы), чтобы вы могли видеть, для чего вы будете. Вам нужно будет проработать модель угрозы, чтобы правильно выстроить дела.
Что касается паролей, вы можете предотвратить совместное использование паролей, используя процесс аутентификации, который использует безопасное соединение (TSL и https :) и который на стороне клиента вычисляет хэш пароля, введенного пользователем, вместе с машиной и пользователем. учетная запись (идентификатор пользователя с вами и учетная запись пользователя на клиентском компьютере), связанные данные. Даже если пароль станет известен, функция хеширования не создаст правильный хэш на другом компьютере или учетной записи пользователя.
Существует интересная проблема, связанная с тем, как хэш (который вы принимаете - вы никогда не знаете выбранный пользователем пароль) устанавливается в первый раз для связи с используемым вами идентификатором пользователя. Вам понадобится что-то вроде уникального ключа, предоставляемого для подписки и предоставляемого посредством рукопожатия по электронной почте во время регистрации и первоначального выбора идентификатора пользователя (если он отличается от адреса электронной почты) и пароля.
Если вы используете куки-файлы, чтобы избежать повторного входа в систему, вам может потребоваться зашифрованная / хешированная информация в куки-файле, которая связывает его с машиной, а также с подпиской.
Теперь, сделав так много, у вас есть проблема людей, желающих иметь возможность работать с нескольких машин, а также нуждающихся в сбросе пароля пользователя, чтобы они могли выбрать новый вместо забытого / скомпрометированного. Поскольку это означает предоставление поддержки по телефону и другие способы повторной проверки подлинности пользователя, вы можете подумать, стоит ли это вам затрат и будут ли пользователи считать, что оно того стоит.
Что касается незаконного присвоения материалов, полученных с сайта, у вас возникла гораздо более сложная проблема. Шифрование не очень поможет, и вы часто хотите, чтобы пользователи хранили материалы для автономного использования, для справок при работе с материалом и т. Д. Что вы можете сделать, это идентифицировать материал как вашу собственность, а также идентифицировать материал как вашу собственность и как это предусмотрено для конкретного абонента таким образом, что трудно удалить все случаи. Это много работы на стороне сервера. В сочетании с очевидной демонстрацией недоверия к вашим подписчикам, вы можете пересмотреть и поработать над тем, чтобы иметь что-то более заслуживающее доверия и, скажем, предоставление чего-то ценного, что не отражается только на наличии контента. Вы уверены, что хотите это сделать?
ПРИМЕЧАНИЕ 2. Если вы проводите какое-то продвижение, например, работаете с помощью учебных программ и уроков, есть очевидные вещи, которые вы можете сделать, чтобы, если каким-то образом вошли несколько человек, если они добились какого-либо прогресса, они испортить вещи для кого-либо еще. Чем больше персонализации и прогресса, тем менее привлекательным является предоставление учетной записи кому-либо еще для использования. Это не препятствует сохранению материала, но любое широко распространенное повторное использование извлеченного контента должно решаться другими способами.