powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Безопасность и шифрование данных
47 сообщений из 47, показаны все 2 страниц
Безопасность и шифрование данных
    #39660975
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте.

Может кто-нибудь подскажет, или скажет что я делаю совсем все не верно. Интересует любое мнение и советы.

Вводные:
Есть backend на django. Там же есть БД. Сервис представляет собой API для клиентских приложений, хранит информацию, добавляет, удаляет и т.д.
Задача такая:
Информацию хранимую в БД надо шифровать, чтобы она хранилась в зашифрованном виде.

На данный момент реализовано это так:
клиент генерирует ключ и сохраняет его. всю информацию клиент шифрует этим ключем и расшифровывает им же. AES256.

Все вроде бы не плохо, но проблема в том, что сервер должен регулярно выполнять разные задачи (отправка уведомления по email, sms и прочую мелочь). Причем данные ему эти надо брать из БД. Но они зашифрованы и ключей на серваке нету.


Варианты решения:
1) Хранить ключи шифрования на другом сервере в зашифрованном виде ассиметричным алгоритмом. Получится так, что данные на одном сервере, ключи на другом. В случае хака базы - она шифрованная, в случае хака сервера с ключами, нет базы. Этот вариант требует доп затрат на доп сервер и их интеграцию, что на данный момент наверное значительный минус

2) Сделать гибридную систему. То есть AES ключ на клиенте шифрует данные, также этот AES ключ шифруется публичным ключом с сервера и отправляется получается по безопасному каналу. Потом сохраняется в бд. В случае выполнения регулярных задач сервер с помощью приватного ключа сможет расшифровать AES ключ и потом расшифровать данные, соответственно выполнить задачи. Большой минус в том, что при наличии доступа к серверу получить приватный ключ и базу думаю будет очень легко.

Ну и еще вопрос, но менее приоритетный:
Если у пользователя несколько девайсов но один акк, возможно ли безопасно хранить его ключ и отдавать в случае логина со второго девайса?


Любые другие методы также приветствуются. Здравая критика и дискуссия тоже. Возможно сумбурно, если будут вопросы я поясню.
Спасибо.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660983
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544,

СУБД с поддержкой шифрования не рассматриваете?

Цель шифрования -- от кого и что шифруется?

Довольно таки очевидно, если вы что-то шифруете от себя, то и не сможете с этим работать. А если хотите работать, то и шифрование бессмысленно.

Т.е. задача поставлена противоречиво.

Примерно как в недавней ветке, где человек хотел изменять уже подписанный электронной подписью документ, но чтобы подпись осталась валидна.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660984
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hVostt, спасибо большое, что откликнулись на мою тему.

Я тоже уже подумываю над СУБД с поддержкой шифрования. Django может работать с PostgreSQL. Попробую посмотреть как это можно задействовать и можно ли.

Дело в том, что сервис работает с личными данными пользователей. Эту информацию и хотелось бы хранить в зашифрованном виде, но с возможностью расшарить ее в нужный момент, определенной группе лиц (этих пользователей определяет сам пользователь-владелец данных). Соответственно любой несанкционированный доступ к этой информации критичен, кроме этих лиц (владелец, доверенные лица владельца).
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660989
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Дело в том, что сервис работает с личными данными пользователей. Эту информацию и хотелось бы хранить в зашифрованном виде, но с возможностью расшарить ее в нужный момент, определенной группе лиц (этих пользователей определяет сам пользователь-владелец данных). Соответственно любой несанкционированный доступ к этой информации критичен, кроме этих лиц (владелец, доверенные лица владельца).

Пока сложно понять спектр решаемых задач. Если ключи будут храниться на сервере, как и само шифрование будет выполняться на сервере, то защита примерно такая же, как если бы сервер сам шифровал одним единственным ключом, который знает только он. Т.е. шифрованная СУБД :)

Иначе всё должно шифроваться только на стороне клиента без участия сервера, а сервер будет принимать бессмысленный для него набор байт и хранить. Если информацию надо "расшарить" пользователям, но надо для каждого индивидуально зашифровать контект, или завести один единственный ключ на группу пользователей. Но тогда выход из группы любого потребует перевыпуск ключей и перешифрование.

В общем. Пока мало что ясно :)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660992
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hVostt,

давайте на примере:)?

Я Вася.
Зарегистрировался на сервисе и создал свой аккаунт.
Вася (Я) создаю заметку с текстом на клиенте, шифрую ее и сохраняю на сервере. (на сервере будет бессмысленный набор байт)
Я могу загрузить эту заметку и расшифровать, откорректировать и заново сохранить (также в зашифрованном виде).

У Васи (у меня) есть друг Петр. Я добавляю в свои друзья Петра (петр, номер_телефона, почта).
Шифрую эту информацию и сохраняю на сервере (в шифрованном виде). Аналогично могу все сделать тоже самое что и с заметкой (получить и расшифровать, отредактировать и тд).

Происходит событие на сервере (например настала полночь) и в связи с этим событием необходимо расшарить информацию Васи (его заметки) Петру, чтобы тот мог их просмотреть. Без ключа Васи сделать это невозможно.( Но очень хочется)

Почему хочется хранить все в шифрованном виде:
1) Информация критичная и конфиденциальная
2) Даже через HTTPS не хочется ее гонять в открытом виде
3) У сервера есть админка и шарить все данные пользователей админу не хочется, а так админ видит некритичные вещи, а критичные для него бессмысленный набор байт
4) В случае получения доступа к серверу вся информация на нем зашифрована и толку от нее немного.

Получается что да, я сам себя обманул и все зашифровал от самого же себя)


Я думал про ассиметричный алгоритм, но в таком случае пользователь с публичным ключом, а сервер с приватным. Соответственно один раз зашифровав данные пользователь не сможет их расшифровать обратно (так как с сервера они будут приходить в шифрованном виде).


Было еще такое решение:
Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?)
Тогда через HTTPS как надежный канал связи гонять информацию в открытом виде, а при сохранении в базу шифровать. Но опять же, ключи/ключ для дешифровки будет на сервере, что в случае несанкционированного доступа сводит все это на нет)))


Кстати если что, то можно кидать тапки), тухлые яйца и еще что нить)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660996
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544,

Суть ассиметричного шифрования -- защита ключей. Зашифровать можно открытым ключом, а расшифровать только закрытым. Больше ничего.

Вы не можете "расшарить" информацию Петру. Для этого вам надо либо поделиться с ним своим закрытым ключом. Либо ВСЕ перешифровать и продублировать информацию для Петра. А если добавится ещё Лёлик и Болик, то ещё два раза всё повторить.

HTTPS уже реализует необходимую защиту информацию от кражи при передаче по сети. Дополнительное шифрование, добавляет только геморроя, но не усиливает защиту. Но для предотвращения атаки man-in-a-middle, всё равно придётся кому-то доверять, третьему лицу.

Суть в том, что если два пациента хотят общаться между собой совершенно секретно, абсолютно секретно, им нужно лично встретиться друг с другом и передать друг другу флешки с открытыми ключами. Зачем? Чтобы потом этими ключами обмениваться временными ключами для синхронного шифрования на каждую сессию. Но.. погодите-как, это же и есть HTTPS :)

Зачем нужна СУБД с шифрованием? Чтобы не могли слить файлы БД и получить доступ к информации. Если приложение и СУБД разнесены по разным серверам, то это достаточно надёжный способ обеспечения защиты информации.

Но как я и сказал, шифрование это когда все заранее договорились. Нельзя брать на борт Васю и давать ему какие-то персональные ключи для доступа к информации, с возможностью их отобрать. Берём на борт Васю, договариваемся заново, и всё с нуля.

Но до сих пор конечная задача не ясна.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39660997
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?)

Пока не определены конкретные задачи, что именно и от кого защищаем, при каких условиях и в каких сценариях конкретно, довольно сложно сказать даже приблизительно, есть ли в этом смысл :)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661000
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hVostt,

Про ассиметричное шифрование понятно. Я так и предполагал, что оно не применимо здесь.

По поводу задачи - давайте абстрагируемся. Просто примем, что она есть).

По поводу расшарить мне виделось это так - мы высылаем Петру по SMS link и код авторизации. Петр заходит на веб страницу, вводит свой код и мы ему в респонсе высылаем расшифрованную информацию. Простите, что не пояснил сразу.

HTTPS однозначно используем.

СУБД и приложение на одном сервере и разнести их к сожалению навряд ли получится.

Ваш последний пост меня честно говоря немного начинает печалить, в плане того, что кажется решить данную задачу похоже не представляется возможным(.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661006
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hVosttILIs544Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?)

Пока не определены конкретные задачи, что именно и от кого защищаем, при каких условиях и в каких сценариях конкретно, довольно сложно сказать даже приблизительно, есть ли в этом смысл :)

Ммм... Вася создает заметки на мобильном устройстве и сохраняет их на сервере.
Также Вася создает записи доверенных лиц то есть контакты (я прошлом посте я назвал друзьями). Вася также сохраняет свои контакты на сервере, причем эти контакты могут не иметь аккаунта в этом приложении.

При определенном событии на сервере, заметки Васи, должны быть показаны его контактам. (как я и писал, контактам приходит линк и код, они идут по линку через https и вводят код для авторизации и видят заметки Васи).

Защищаем мы заметки Васи от любого несанкционированного доступа, т.е. на тот случай если:
трафик Васи при создании заметок будет перехвачен
администратор, который может смотреть админку тоже не должен видеть заметки Васи
будет утянута база
будет несанкционированный доступ к хостингу (тут вообще может что-нибудь помочь?:))

если база находится там же где и приложение то мне кажется последние 2 пункта связаны друг с другом.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661072
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Защищаем мы заметки Васи от любого несанкционированного доступа, т.е. на тот случай если:
трафик Васи при создании заметок будет перехвачен
администратор, который может смотреть админку тоже не должен видеть заметки Васи
будет утянута база
будет несанкционированный доступ к хостингу (тут вообще может что-нибудь помочь?:))

Вот с этого нужно было начинать. Потому что это цель. А всё остальное - пустота.

Если цель состоит только в шифровании заметок, то адреса контактов под такую цель не попадают и, соответственно, их можно хранить в открытом виде, ну и отправлять по ним всякую шифрованную дрянь, которую клиенты уж как-нибудь сами переварят. Если они сами не переваривают, то тогда у них один путь - доверять посреднику. Но посредник может создать для них туннель, по которому можно обеспечить взаимодействие между браузерами, например через https. При этом останется проблема обмена ключами между пользователями. Посредник может предложить им найти удобный способ (подсказать варианты). Например - качаете тулзу такую-то, она делает вам ключ, шлёте его через предпочитаемую почту своим друзьям, ставите полученные от друзей ключи в браузер и далее смело рубитесь в порно-игры через предлагаемый посредником туннель, ваш обнажённый торс посредник не увидит. Здесь опять встаёт проблема доверия, но уже скачанной тулзе и каналу передачи ключей. Но поскольку тулза и канал скорее всего не знают о назначении создаваемых/передаваемых байт, то про порно-игры могут и не догадаться. Ну а если догадаются - Васе с Петей придётся раскошелиться за ограничение публичности их занятий перед монитором писюка :) В общем - снимаете с себя ответственность за канал и тулзу, заявляя, что лучший способ передачи - из рук в руки.

Ну а джанги там всякие и прочие поделия к теме вообще никакого отношения не имеют. Это лишь мусор, набрасывая который вы упорно не давали нам вас понять. Потому что если вы уж взялись за какую-то джангу, значит оно вам нравится и вы готовы приседать до упаду ради реализации правильного подхода на вами любимой джанге или ещё какой приблуде. Для нас от названия приблуды ничего не меняется.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661087
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GDPR что-ли так сильно по голове ударил, не пойму?
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661126
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alex55555,

Благодарю что откликнулись.

В целом понятно.
Вывод который я сделал -
Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера.

Тогда когда нужно будет отобразить Заметки Васи, Петя переходит по ссылке и ввод ключ, который он получил от Васи. И может расшифровать и посмотреть его Заметки.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661128
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
skyANA,

Нет :)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661133
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544alex55555,

Благодарю что откликнулись.

В целом понятно.
Вывод который я сделал -
Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера.

Тогда когда нужно будет отобразить Заметки Васи, Петя переходит по ссылке и ввод ключ, который он получил от Васи. И может расшифровать и посмотреть его Заметки.
Третий курс, основы защиты безопасности
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661174
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
skyANA,

к сожалению в то время, пока я не сталкивался с такими задачами, это было не интересно.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661190
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера
Все смешалось в доме Облонских...

Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать.

А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением.

Нужно понимать, что "несанкционированный доступ" не равно "зашифрованные данные".

Обычно используют саму СУБД с шифрованием на случай кражи файла с БД. Тогда информация бесполезна.
А авторизацию доступа к данным осуществляет прикладной уровень.

Защита от перехвата на транспорте - использование защищенных туннелей, SSL/SSH не суть.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661200
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arm79ILIs544Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера
Все смешалось в доме Облонских...

Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать.

А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением.

Нужно понимать, что "несанкционированный доступ" не равно "зашифрованные данные".

Обычно используют саму СУБД с шифрованием на случай кражи файла с БД. Тогда информация бесполезна.
А авторизацию доступа к данным осуществляет прикладной уровень.

Защита от перехвата на транспорте - использование защищенных туннелей, SSL/SSH не суть.

В чем недостаток обмена ключами для симметричного шифрования? По крайней мере я пока хотел на этом остановится, по крайней мере для начала.

Про несанкционированный доступ и зашифрованные данные я что-то путаю?

СУБД с шифрованием это я тоже понял. Но как я понял, это поможет в случае кражи файла. А так как БД и веб приложение находится будут в одном месте, то получив доступ к аккаунту, который используется для хостинга, дальше уже можно крутить вертеть как угодно. Но от этого я так понимаю, можно спастись только если сервер находится в твоем здании, с нужными политиками безопасностью и т.д. А утащить бд без доступа к аккаунту, который используется для хостинга не уверен, что возможно.

Про перехват на транспорте понятно. К этому нет вопросов.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661263
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать.
Так и должно быть. Как минимум автор озвучил такое ТЗ.

Количество ключей так же не проблема - шифрует клиент (браузер, например).
Arm79А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением.
Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи.
Arm79Обычно используют ...
Вы ТЗ прочитайте, а что там и для чего "обычно используют" - это к маркетолухам, они вам и не такое споют.

В общем - не нагоняйте жути, ваш ход гораздо страшнее :)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661341
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alex55555Arm79Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать.
Так и должно быть. Как минимум автор озвучил такое ТЗ.


Количество ключей так же не проблема - шифрует клиент (браузер, например).

Не сможете подсказать как это реализовать в рамках моей задачи?
Могу тупить. Но люди, которым надо отправить заметку могут и не быть зарегистрированными пользователями сервиса.

Я могу не верно понимать, если что думаю пнете.
Ассиметричное шифрование это если у сервера будет private ключ, и он будет выдавать public ключи для шифрования. Тогда пользователь сервиса шифрует свою заметку public ключом и отправляет через https на сервер. Сервер сохраняет. Когда наступает время показать заметку человеку из списка контактов, мы генерим для него link и одноразовый код и отправляем это по SMS на телефон. Переходя по ссылке он вводит код в форму, и отправляет запрос через https на сервер. Сервер private ключом расшифровывает заметку и через https отправляет ее доверенному контакту.

Я хоть что-нибудь правильно понял? Или все не правильно :)?

alex55555Arm79А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением.
Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи.

Вот это явный недостаток, потому что юзеру надо будет свои друзьям передать ключ, а ключ абракадабра, да плюс по пути передачи не известно кто еще его увидит и так далее. Но вариант легко реализуемый в данный момент и вроде как достаточно надеждный. Но это добавляет боли пользователю.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661466
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555Так и должно быть. Как минимум автор озвучил такое ТЗ.
Автор озвучил СВОЕ решение поставленной проблемы. Я считаю, что такое решение не годится никуда.
alex55555Количество ключей так же не проблема - шифрует клиент (браузер, например).
количество никак не связано с тем, кто шифрует
alex55555Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи.
это не решение, это мазохизм

alex55555Arm79Обычно используют ...
Вы ТЗ прочитайте, а что там и для чего "обычно используют" - это к маркетолухам, они вам и не такое споют.
Надо полагать, вы читали это ТЗ? А не ограничились вольным пересказом ТС?
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661467
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arm79,

Ребят не меряйтесь знаниями)

Если есть возможность и какое-то решение (я не думаю что то о чем я говорю это что-то сверхновое:)) то объяснить так сказать для самых маленьких). Я буду очень благодарен. Говорю же любая здравая дискуссия приветствуется.

Решение с передачей ключа пришло в результате обсуждения как действительно достаточно надежное. Хоть и болезненное в плане user experience.

Arm79, сможете попроще объяснить свою идею? Был бы благодарен.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661468
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вариант:
1. шифруете заметку симметричным ключом с известным пользователю паролем.
2. если пользователь хочет дать доступ к своим заметкам определенному кругу друзей, то он с помощью сертификатов этих друзей шифрует свой пароль, получившийся массив данных крепит к своей заметке (отношение 1 ко многим)
3. любой пользователь может скачать и зашифрованную заметку, и зашифрованный кучей сертификатов пароль. Но если нет закрытого ключа от любого сертификата, расшифровать пароль не получится. И доступа к содержимому заметки также не получить

Необходимо также заложиться на смену пароля у заметки (+ отмена прикрепленных шифрованных паролей), а также управление сертификатами и ведение списка отозванных сертификатов

Кстати, пароль пользователя может быть случайным для каждой заметки, если вы защитите его приватным ключом самого пользователя
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661470
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
на примере:

Есть Вася, Петя и Саша. У каждого есть свой набор ключ-сертфиикат

Вася создает заметку
На созданную заметку генерируется GUID в качестве ключа гаммирования
Заметка шифруется симметричным ключом (GUID-ом)

Далее, Вася решает, что доступ к заметке должен иметь и Петя, и Саша.
Он шифрует своим сертификатом и сертификатами Пети и Саши сгенерированный GUID
Далее набор "Шифрованная заметка" и "Список доступа" (в общем случае таким списков много) выкладывается на сервер

Саша скачивает заметку, получает все списки доступов и пытается своим приватным ключом расшифровать любой из них. Ему удается, и он получает расшиaрованный GUID. Применяя этот GUID в качестве ключа расшифровывает заметку.

А вот произвольный Максим уже такого не сможет.

Далее, Вася решил добавить Максима в список доступа. Перегенерировать ничего не нужно. Просто к заметке добавляем еще один список доступа (из одного человека). Удаление аналогично.

При смене пароля заметки, все списки доступа должны перегенерироваться.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661471
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а вот смс-кой уже низзя
это схема для зареганных пользователей
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661473
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arm79,

Сейчас я вникну и отвечу.

Это отличное и удобное решение . Но, я могу ошибаться, у него есть кое-какое ограничение, а именно как в Вашем последнем посте.

Если быстро попробую объяснить, но могу и ошибаться:

В таком случае Петя должен еще до шаринга, поставить себе какое то клиентское приложение которое сгенерит ему приватный ключ и оставит у него, и публичный, который будет сохранен на сервере и ассоциирован с Петей.

В этом случае, Вася как раз и возьмет публичный ключ Пети и проделает все о чем Вы говорите. Все сохранит на сервере и в нужный момент Петя с клиента откроет то расшаренную заметку, заюзает свой приватный ключ, расшифрует ключ симметричного шифрования и прочитает заметку.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661474
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544,

Да, именно так. Для того, чтобы предоставить шаринг Пете, он должен быть зарегистрирован и иметь сертификат. Но на момент шифрования Пети может не быть. Как только появится, то Вася может ДОПОЛНИТЕЛЬНО для Пети расшарить свою заметку. И для ранее расшаренных Саше и Максиму это будет незаметно.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661475
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arm79,

Понял. Спасибо Вам огромное.
Получается гибридная система шифрования. Мои задачи, вроде как решает.
Еще обмозгую сегодня. Но реально звучит годно, и практически без боли.

Главное ничего не упустить)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661478
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm792. если пользователь хочет дать доступ к своим заметкам определенному кругу друзей, то он с помощью сертификатов этих друзей шифрует свой пароль, получившийся массив данных крепит к своей заметке (отношение 1 ко многим)
И вот оно в самом соку - друзьям всё же рекомендуется самим найти способ обменяться сертификатами. Этак неявно, неброско, но обязательно. Но вроде кто-то был против?
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661479
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если ставится задача закрыть данные от всех, включая посредников, то "так обычно делают" ни разу не работает.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661480
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alex55555Arm792. если пользователь хочет дать доступ к своим заметкам определенному кругу друзей, то он с помощью сертификатов этих друзей шифрует свой пароль, получившийся массив данных крепит к своей заметке (отношение 1 ко многим)
И вот оно в самом соку - друзьям всё же рекомендуется самим найти способ обменяться сертификатами. Этак неявно, неброско, но обязательно. Но вроде кто-то был против?

Но тут мы открытыми ключами меняемся. Их можно гонять без проблем.

Опять же в целях здравой дискуссии этот вариант удобнее и тоже достаточно защищённый.
Опять же если ив ничего не упускаем:)
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661483
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555И вот оно в самом соку - друзьям всё же рекомендуется самим найти способ обменяться сертификатами. Этак неявно, неброско, но обязательно. Но вроде кто-то был против?
Конечно же нет. Вы, по моему, совершенно не даете себе труда понимать написанный текст.

Я позволю себе процитировать очевидное:
ILIs544Петя должен еще до шаринга, поставить себе какое то клиентское приложение которое сгенерит ему приватный ключ и оставит у него, и публичный, который будет сохранен на сервере и ассоциирован с Петей.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661497
Lessyp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm791. шифруете заметку симметричным ключом с известным пользователю паролем.
2. если пользователь хочет дать доступ к своим заметкам определенному кругу друзей, то он с помощью сертификатов этих друзей шифрует свой пароль, получившийся массив данных крепит к своей заметке (отношение 1 ко многим)
3. любой пользователь может скачать и зашифрованную заметку, и зашифрованный кучей сертификатов пароль. Но если нет закрытого ключа от любого сертификата, расшифровать пароль не получится. И доступа к содержимому заметки также не получить

Необходимо также заложиться на смену пароля у заметки (+ отмена прикрепленных шифрованных паролей), а также управление сертификатами и ведение списка отозванных сертификатов

Шифрование данных и авторизация доступа к ним это разные вещи, не надо из смешивать.

К примеру у SQL Server есть и возможность шифровать данные с помощью клиентских сертификатов, что позволяет хранить зашифрованные данные в самой базе (даже админ не может их прочитать если не имеет доступа к сертификату). Запись/чтение должен осуществлять application server, который и обладает этим доступом. А авторизация, кто может что читать и куда писать - реализуется любыми стандартными методами. Это также позволит осуществлять нормальную бэкап/ротацию ключей шифрования.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661522
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Но тут мы открытыми ключами меняемся. Их можно гонять без проблем.
В случае наличия посредника возникает проблема man in the middle.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661523
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Я позволю себе процитировать очевидное
В цитате предлагается безоглядно довериться посреднику. Если это часть плана автора темы - ну тогда ему помощь не нужна.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661534
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Lessyp,

как я понял в предложенном подходе по сути происходит тоже самое - шифруем данные на клиенте и храним их в шифрованном виде в базе. в остальном я вроде тоже понял что вы имеете ввиду
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661535
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alex55555ILIs544Но тут мы открытыми ключами меняемся. Их можно гонять без проблем.
В случае наличия посредника возникает проблема man in the middle.

Как я понял эта проблема возникает при любом HTTPS соединении.
Решается она вроде через платные сертификаты и бюро сертификации, удостоверяющий что сервер это сервер.

Поправьте пожалуйста если я не прав.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661537
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
шифруем данные на клиенте и храним их в шифрованном виде в базеА как потом с этими "шифрами" работать ?
Как искать , фильтровать ?

Что надо сделать чтобы сработало
WHERE name like 'Иванов%' ?
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661541
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
L_argoшифруем данные на клиенте и храним их в шифрованном виде в базеА как потом с этими "шифрами" работать ?
Как искать , фильтровать ?

Что надо сделать чтобы сработало
WHERE name like 'Иванов%' ?

Никак. Но мне это не нужно, так как количество заметок у пользователя ограничено.
А показать их юзеру я могу, так как owner у заметок открыт и еще часть общих не критичных полей тоже.

Да фильтрация по шифрованным поялм работать в таком случае не будет, и полнотекстовые функции тоже. Но это не требуется.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661568
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544Решается она вроде через платные сертификаты и бюро сертификации, удостоверяющий что сервер это сервер.
Решается она через наличие способов, гарантирующих отсутствие вмешательства посредника. Только так. Если вы обладаете возможностью перехватить и данные и сертификаты до их обмена пользователями - всё, вы можете расшифровать данные.

Поэтому вы должны гарантировать, что вы не увидите сертификаты первым. То есть юзеры должны сами их как-то без вас обменять.

В общем рисуйте на бумажке длинную цепочку (то есть подробно) всех действий хотя бы двух юзеров и вас, как посредника, ну и думайте, в каком месте вы можете перехватить, подменить, исказить и т.д.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661574
ILIs544
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alex55555ILIs544Решается она вроде через платные сертификаты и бюро сертификации, удостоверяющий что сервер это сервер.
Решается она через наличие способов, гарантирующих отсутствие вмешательства посредника. Только так. Если вы обладаете возможностью перехватить и данные и сертификаты до их обмена пользователями - всё, вы можете расшифровать данные.

Поэтому вы должны гарантировать, что вы не увидите сертификаты первым. То есть юзеры должны сами их как-то без вас обменять.

В общем рисуйте на бумажке длинную цепочку (то есть подробно) всех действий хотя бы двух юзеров и вас, как посредника, ну и думайте, в каком месте вы можете перехватить, подменить, исказить и т.д.

предположу что при любом обращении к серверу
мы снова приходим к тому, что ключами (даже публичными) клиенты должны обменятся без участия сервера в идеальной ситуации

блин но https же существует как то :) и достаточно популярен. я так понимаю, что используя https мы так или иначе доверяемся, вы мне уже говорили вроде про это (кстати огромный плюс за ваш слог).
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661589
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544предположу что при любом обращении к серверу
мы снова приходим к тому, что ключами (даже публичными) клиенты должны обменятся без участия сервера в идеальной ситуации

блин но https же существует как то :) и достаточно популярен. я так понимаю, что используя https мы так или иначе доверяемся, вы мне уже говорили вроде про это (кстати огромный плюс за ваш слог).Открытые ключи (в составе сертификата) сначала должны появиться у юзеров. А потом ими можно кидаться в кого угодно. Но если ключи к юзерам попадут от вас - вы имеет возможность всех обмануть.

HTTPS работает лишь потому, что сертификаты корневых удостоверяющих центров идут в комплекте с браузером (setup.exe). То есть если бы ФСБ всех сагитировало качать браузер FireFox с известных ФСБ адресов, то лёгким движением руки ФСБ-шного админа можно было бы подменять корневые сертификаты, удостоверяющие интересные ФСБ сайты. Но тогда бы все остальные сайты, использующие тот же корневой сертификат, перестали бы работать по https с данным браузером. Так что даже ФСБ будет нелегко нагнуть весь мир и весь набор производителей браузеров на их условия, а в результате вы имеете возможность прятать от товарища майора ваши контакты с ИГИЛ и прочими запрещёнными в РФ организациями.

Но суть примера в том, что пользователи https получают сертификаты независимо от ФСБ, владельцев сайтов и прочих заинтересованных в чужих данных контор и всяческих хакеров.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661591
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ. Вы там реально безопасный чат пишете поди? В смысле не знаю, как точно оно устроено во всяких телеграмах, но судя по их громким заявкам в рекламе в их софте должно быть что-то аналогичное. А вот если аналогичного нет - все громкие заявки есть чистая туфта. Но если есть, то пользователи уже имеют все возможности ваших "заметок" в виде распространённых мессенджеров.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661598
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555Arm79Я позволю себе процитировать очевидное
В цитате предлагается безоглядно довериться посреднику. Если это часть плана автора темы - ну тогда ему помощь не нужна.
Если посредник - известный центр сертификации, почему бы и нет?
Собственно, наличие доверия к тому или иному посреднику - это ключевое требование PKI, ничего плохого в этом не вижу.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661599
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555Решается она через наличие способов, гарантирующих отсутствие вмешательства посредника. Только так. Если вы обладаете возможностью перехватить и данные и сертификаты до их обмена пользователями - всё, вы можете расшифровать данные.
Вообще мысль, что можно перехватить "сертификат" звучит нелепо. Очевидно, имелось ввиду что-то другое, просто неудачный оборот.

Сертификат - это открытый ключ пользователя, подписанный ЭЦП посредника.

Его в принципе нельзя перехватить, так как это открытые данные. И наличие сертификата позволяет только ЗАШИФРОВАТЬ в адрес пользователя данные. А расшифровать, к счастью, имея только сертификат, уже нельзя никак.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661612
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Вообще мысль, что можно перехватить "сертификат" звучит нелепо. Очевидно, имелось ввиду что-то другое, просто неудачный оборот.
Да, имелось в виду - подменить. Но подменить можно лишь до момента, пока юзер не получил сертификат от того, с кем хочет общаться. А потом уже нужно на компьютер юзера лезть, хачить и там подменять, что несколько сложнее, особенно при большом количестве юзеров.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661613
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79А расшифровать, к счастью, имея только сертификат, уже нельзя никак.
Квантовые компьютеры уже летят к вам.
...
Рейтинг: 0 / 0
Безопасность и шифрование данных
    #39661631
Lessyp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ILIs544как я понял в предложенном подходе по сути происходит тоже самое - шифруем данные на клиенте и храним их в шифрованном виде в базе. в остальном я вроде тоже понял что вы имеете ввиду
нет, шифруем данные на application server'e, только он обладает доступом к сертификатам. На клиента идут чистые данные, он вообще не знает что что-то где-то шифруется и доступ отслеживается.
...
Рейтинг: 0 / 0
47 сообщений из 47, показаны все 2 страниц
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Безопасность и шифрование данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]