Первое, что нужно сделать, это отделить пароль пользователя от этого.Вы должны будете расшифровать и повторно зашифровать все их файлы.Это может быть связано с другими способами, такими как использование этой системы только новыми файлами.Но это зависит от конкретного случая использования, например, как долго вы сохраняете их файлы, какой оборот у них и т. Д.
В любом случае это способ сделать это:
- Зашифруйте файлы, которые они отправляют, используя сгенерированный вами пароль.
- Сохраните этот пароль в другом файле, который мы сейчас назовем
key.txt.Зашифруйте этот файл с помощью пароля пользователя. - Когда пользователь входит в систему (если он не хранится), берите свой пароль, расшифровывайте
key.txt и получите сгенерированный пароль. - Теперь выможете сохранить этот сгенерированный пароль в любом месте, не затрагивая учетную запись пользователя.
- То, что они видят (опыт конечного пользователя), будет выглядеть так, как будто они всегда загружают файл, вводят свой пароль и получают файл.Они никогда не узнают, что ты это сделал, что хорошо для них.
Так что проблема первая решена.
Теперь, где мы должны хранить это?
Вы можете просто сохранить его на сервере в БД.Это зависит от того, насколько конфиденциальны данные и насколько защищен ваш сервер.В конечном итоге вы несете ответственность за безопасность чужих данных, по крайней мере, таким образом вы можете контролировать их.
Составьте таблицу с этими полями
user_id | ip | password | last_access
Когда пользователь отправляется на скачивание файла,проверьте их время последнего доступа и IP-адрес, чтобы сделать пароль недействительным и заставить его обновить его.Это очень легко установить и полностью под вашим контролем.Если вы сохраните ключ шифрования, он всегда будет иметь некоторый уровень уязвимости, по крайней мере, таким образом, все это под вашим контролем.
Даже если вы не хотите хранить его в своей БД, самый большой недостаток здесьесли кто-то завладеет этой таблицей, но если они это сделают и вы сохраните важные данные, у вас, вероятно, уже будет много проблем.
По крайней мере, используйте первую часть, поскольку это решает большую проблему, связывая ее сфактический пароль учетной записи.Даже если хакер получает пароль файла от клиента (украденные файлы cookie и т. Д.), Потому что он отдельный, он не позволит им войти на ваш сайт, как пароль учетной записи.Я предполагаю, что здесь, пользователь должен войти в систему, чтобы даже получить часть загрузки.Использование одного и того же пароля для обоих дает им доступ как к средствам получения этих данных, так и к способу их загрузки.
Для ясности, это аргумент, который нужно сделать для хранения их на стороне клиента.,Тогда, если ваш сайт будет взломан, у вас будет меньше шансов получить пароль, поскольку он (в зависимости от того, как вы это делаете) существует только в памяти как на клиенте, так и на сервере и т. Д. Это возлагает на них ответственность.
АСИММЕТРИЧЕСКОЕ ШИФРОВАНИЕ
Вы также можете использовать асимметричное шифрование.В настоящее время похоже, что вы используете AES, что нормально, но это блочный шифр Symmetric Key.По сути, существуют три распространенные формы «шифрования» (на местном языке):
Хеширование (которое на самом деле не является шифрованием) - md5, sha1, sha256 - этиявляются одним из способов, не могут быть декодированы.Они имеют фиксированную длину и всегда шифруют одно и то же.Обычно это видно по контрольной сумме файла (для проверки содержимого файла), блок-цепочке, паролям или чему-либо еще, где нужно сравнить два «зашифрованных» значения.
Симметричный - AES, 3DES, Blowfish, Twofish - все, что вам нужно для шифрования и дешифрования.Один и тот же ключ может сделать оба.Как правило, они каждый раз зашифровывают одну и ту же вещь в разные значения из-за IV.
Асимметричный - SSL, DSA, RSA, PGP, используемый в кошельках криптовалюты, TLS и т. Д. С ними у вас есть 2 ключа, открытый и закрытый.Ключи не могут расшифровать свои зашифрованные данные, может только другой ключ.Так что с этим, если у вас есть один ключ на сервере, а у клиента есть другой.Вы можете зашифровать их файлы, используя свой ключ (расшифровывается только по их ключу), и вам не нужно слишком беспокоиться о том, что кто-то получит ваш ключ, поскольку это не позволит им расшифровать файлы.Вы можете дать один ключ клиенту, который может использовать этот ключ для расшифровки своих данных, которые вы зашифровали (даже без вашего ключа).Они также зашифровывают разные «вещи» каждый раз, когда вы их используете.
Таким образом, вы можете видеть, что асимметричная форма имеет несколько преимуществ для использования в двух (или более) партийных системах.Преимущество также в том, что вам не нужен их ключ для шифрования файла.Все, что вам нужно, это ваша часть пары.Так, например, если вы генерируете для них данные и не хотите их шифровать, а потом хотите, чтобы они расшифровали их в той же системе, вы можете сделать это без проблем.Это, вероятно, исключает какой-либо шаг, поскольку вам нужно будет спросить их или отслеживать их Symmetric в любое время, когда вы хотите что-то зашифровать.Здесь вам просто нужна ваша часть пары ключей.
Это действительно не намного сложнее реализовать (на сервере), просто сложнее понять, что он делает.Вот почему я решил добавить это, без этих знаний (которые вы можете знать или не знать) трудно использовать эти термины, и они имеют смысл.Единственный реальный недостаток для вас (если вы так его называете), если вы используете асимметричное шифрование, это если клиент потеряет свой ключ, у вас не будет возможности расшифровать файл.Поэтому я хотел бы убедиться, что они знают, чтобы поддержать их в безопасном месте.Это та же проблема, что и в новостях, когда речь заходит о потере криптовалютного кошелька, который зашифрован асимметрично
Как я уже говорил, большая часть моих знаний связана с шифрованием и обработкой данных на сервере.Поэтому я не уверен, как связать это с «опытом клиента».Например, я знаю, как использовать ключи RSA для пароля без входа в систему по SSH и т. Д. Что-то вроде того же, но не совсем.
Надеюсь, это поможет!