Как лучше хранить "секретную" инфу в базе
А вопрос был в том, как удобнее всего шифровать инфу. Пока есть всего два решения: каждый пользователь имеет публик ключ на сервере и приватный ключ у себя на компе. Используем ассиметричное шифрованиесервер имеет два ключа, используем симметричное шифрование
Для начала двумя ключами никто сами данные не шифрует, поскольку это неэффективно (очень долго) да и не нужно. Двумя ключами шифруют ключи для эффективных (симметричных) алгоритмов. А два ключа используют для совершенно других целей. Поэтому первый подход с асимметричным шифрованием фактически использует два ключа для двух разных целей: аутентификацию и шифрование. Это не запрещено конечно, но если вы понимаете, что творите. А вы видимо не понимаете, поэтому я с самомго начала и потом несколько раз повторял: где здесь аутентификация, где авторизация, и где шифрование. Ну чтобы было более понятно: пара <public key, private key> аналогична паре <user name, passowrd>. Если вы вводите асимметричное шифрование, то неявно вводите просттранство юзеров - каждый открытый ключ это один юзер. Например, в биткойне столько юзеров, сколько было сгенерировано открытых ключей (очень много), и каждый может зарегить нового юзера путем генерации пары ключей (и выполним транзакцию, чтобы этот открытый ключ попал в блок-чейн). Так что использовать асимметричное шифрование это изначально не очень хорошая идея.
А теперь главное: почему асиметричное шифрование "удобнее" в данном случае, и какую проблему мы решаем?
Есть еще варианты?
Пока проблема не сформулирована, то нет и решения. Если предположить что "вопрос был в том, как удобнее всего шифровать инфу", то берите любой алгоритм шифрования и делайте. Возьмите zip и шифруйте все файлы. Если хотете поделиться, то закиньте на открытый сервер, дайте линк кому надо вместе с ключем шифрования и усе. Ну или на стике передавайте.
Для начала двумя ключами никто сами данные не шифрует
Два ключа нужны только для того что бы ключ не знал один человек, а всё остальное это уже домыслы
поскольку это неэффективно (очень долго)
А есть ссылка на исследования хотя бы после 2000 года, потому как по ощущениям это гораздо меньше секунды.
Поэтому первый подход с асимметричным шифрованием фактически использует два ключа для двух разных целей: аутентификацию и шифрование.
вот ту есть готовый код, покажите часть для аутентификации пож.
https://www.infoworld.com/article/3683911/how-to-use-symme...
Если вы вводите асимметричное шифрование, то неявно вводите пространство юзеров
только в том случае если пара ключей принадлежит одному и только одному пользователю.
так что использовать асимметричное шифрование это изначально не очень хорошая идея
Спросите того кто это предложил. И вам скажут, что это очень хорошая идея для того что хотелось.
Если бы я хотел хранить исключительно личную информацию, то пожалуй так бы и поступил.
и какую проблему мы решаем?
ладно, можно и повторить.
Есть некие данные, которые генерит / получает сотрудник предприятия. И это не большой объем данных.
Этими данным можно поделится с другими сотрудниками твоей команды или может еще с кем-то.
Либо просто с одним каким-то сотрудником.
При этом никаких админов для данной проги, потому как задолбались они уже. Данные должны хранится на сервере в зашифрованном виде. При этом ни из кого у сотрудников не должно быть официального доступа ко всем незашифрованным данным, либо просто пути для дешифрации (типа знания ключа)
Ну вот как то так вкратце.
Возьмите zip и шифруйте все файлы.
нет никаких файлов, есть строка с атрибутами которая вводится вручную/копируется на веб сайте.
то закиньте на открытый сервер
неудобно, потому как получателю нужно еще передать ключ и он должен с ним проделать какие то операции.
Ну или на стике передавайте.
Очень многие находятся в разных частях земного шарика.
Есть некие данные, которые генерит / получает сотрудник предприятия. И это не большой объем данных.Этими данным можно поделится с другими сотрудниками твоей команды или может еще с кем-то.Либо просто с одним каким-то сотрудником.При этом никаких админов для данной проги, потому как задолбались они уже. Данные должны хранится на сервере в зашифрованном виде. При этом ни из кого у сотрудников не должно быть официального доступа ко всем незашифрованным данным, либо просто пути для дешифрации (типа знания ключа)
Обычная удаленная (общая) файловая система решает проблему. Все файлы шифруются на диске битлокером или чем-то подобным. Доступ разграничивается через атрибуты файла: сделайте файл/папку доступной для чтения/записи для пользователя/группе. Ну или SharePoint еще удобнее. Ну и думаю еще море разный подобных решений существует для совместного использования документов. Почему не подходит?
Обычная удаленная (общая) файловая система решает проблему
нифига не решает, как нужно
Все файлы
нет никаких файлов как и документов. Есть скажем, строка с атрибутами: имя, описание и пр.
еще море разный подобных решений
Да пробовали тоже много. Основная проблема - кто то должен это все администрировать.
Да и нужен веб - открыл сайт и усё.
нифига не решает, как нужно
Почему? Что не нравится?
Пользователь генерит данные в виде строки с атрибутами и сохраняет в файле "Строка с атрибутами 1.txt". Предоставляет доступ пользователю 3 и 4, ну или группе. Они могут теперь его читать.
нет никаких файлов как и документов. Есть скажем, строка с атрибутами: имя, описание и пр.
А строка с атрибутами не может в файле хранится? Это требование такое?
Мне это напоминает разборки с бухгалтерами по поводу требований к системе:
- Мы работаем так: берем документ из папки в нижнем ящике тумбочки, заполняем верхнее поле, и кладем в верхний ящик в шкафу
- Ну хорошо, будете открывать файл из этой директории, заполнять поле, и сохранять в другой директории
- Нет, так не пойдет, мы принципиально не работаем с файлами и директориями и работать никогда не будем. Мы работаем с ящиками и шкафами, и не собираем менять наш подход.
- Ну хорошо, а если мы в базе данных будем хранить документы как записи.
- Ни в коем случае. Делайте как хотите, но никаких файлов, директорий или баз данных с записями. И чтобы там еще печать чернильная была обязательно от нашего шефа, но он в другом здании, поэтому надо относить документ, обязательно, поскольку он любит, чтобы к нему лично приходили.
Такой разговор это кстати не очень далеко от реальности работников бухгалетрий (if you know what I mean :) Это я по поводу что "нет никаких файлов". Ну используйте вместо файлов "строка с атрибутами" или URI - что это меняет? Мы храним где-то данные, и они доступны кому надо по ссылке. Проблема решена. Или я чего-то упустил?
Почему? Что не нравится?
Честно говоря, не вижу смысла в проведении опросов и написания отчета почему хочется отказаться от подобной системы.
Если интересно, просто напишите шаги который должен сделать админ/пользователь для описанных мною шагов.
Не забыть еще, что есть ограничения на длину пути к файлу и доступ к расшаренному каталогу возможен только через VPN.
И предлагаю более реальный пример - вот есть контора по разработке ПО, приходит туда заказчик и говорит - хочу веб приложение на С шарпе и что бы данные были в базе.
Контора в ответ - ничего подобного, вам нужно десктоп приложение, а данные должны быть на сетевом диске. И вообще, все нормальные пацаны пишут веб приложения на ангуляре/ноде..../.. никаких С шарпов.
Реакцию заказчика нужно ещё описывать?
А строка с атрибутами не может в файле хранится? Это требование такое?
ну давайте расскажите какие шаги нужны для показа ентого в таблице и присобачивания поиска, при том что нужны не все файлы из каталога.
Или я чего-то упустил?
всё что я написал до того.
А то спрашиваю какой авиакомпанией лучше полететь на майорку
------
Но при этом ты требуешь чтобы авиакомпания обеспечила перелет без самолета и производить взлет не из аэропорта...
а мне говорят
-----
Да, тебе говорят, что можно взлететь с автобана... но не говорят что это будет большой боинг...
Интересовал всего то удобный способ шифрования информации в базе
------
Ну тебе назвали несколько вариантов.
В обратку получили требования измененные до сферического коня в вакууме - информации не должно быть, ничего дополнительного нигде не должно хранится, доступно должно быть не всем но ограничено нечем тем кто решил ограничить.
Когда тебя просят поименовать сущности, то выслушивать приходится что-то вида вот тут имеем несколько разных но различать не надо а надо делать различия... Определись хоть с чем нибудь - тогда можно будет смотреть что с чем делать.
В обратку получили требования измененные до сферического коня в вакууме
Явное преувеличение.
Все что нужно пользователю - попасть на сайт, всё остальное лишнее - это вроде само собой разумеется.
Когда тебя просят поименовать сущности
не имею понятия что под этим подразумевается. Давай список - сделаем имена.
Определись хоть с чем нибудь
Не вижу никаких проблем, что еще непонятно?
