|
|
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Может кто-нибудь подскажет, или скажет что я делаю совсем все не верно. Интересует любое мнение и советы. Вводные: Есть backend на django. Там же есть БД. Сервис представляет собой API для клиентских приложений, хранит информацию, добавляет, удаляет и т.д. Задача такая: Информацию хранимую в БД надо шифровать, чтобы она хранилась в зашифрованном виде. На данный момент реализовано это так: клиент генерирует ключ и сохраняет его. всю информацию клиент шифрует этим ключем и расшифровывает им же. AES256. Все вроде бы не плохо, но проблема в том, что сервер должен регулярно выполнять разные задачи (отправка уведомления по email, sms и прочую мелочь). Причем данные ему эти надо брать из БД. Но они зашифрованы и ключей на серваке нету. Варианты решения: 1) Хранить ключи шифрования на другом сервере в зашифрованном виде ассиметричным алгоритмом. Получится так, что данные на одном сервере, ключи на другом. В случае хака базы - она шифрованная, в случае хака сервера с ключами, нет базы. Этот вариант требует доп затрат на доп сервер и их интеграцию, что на данный момент наверное значительный минус 2) Сделать гибридную систему. То есть AES ключ на клиенте шифрует данные, также этот AES ключ шифруется публичным ключом с сервера и отправляется получается по безопасному каналу. Потом сохраняется в бд. В случае выполнения регулярных задач сервер с помощью приватного ключа сможет расшифровать AES ключ и потом расшифровать данные, соответственно выполнить задачи. Большой минус в том, что при наличии доступа к серверу получить приватный ключ и базу думаю будет очень легко. Ну и еще вопрос, но менее приоритетный: Если у пользователя несколько девайсов но один акк, возможно ли безопасно хранить его ключ и отдавать в случае логина со второго девайса? Любые другие методы также приветствуются. Здравая критика и дискуссия тоже. Возможно сумбурно, если будут вопросы я поясню. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 21:37 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544, СУБД с поддержкой шифрования не рассматриваете? Цель шифрования -- от кого и что шифруется? Довольно таки очевидно, если вы что-то шифруете от себя, то и не сможете с этим работать. А если хотите работать, то и шифрование бессмысленно. Т.е. задача поставлена противоречиво. Примерно как в недавней ветке, где человек хотел изменять уже подписанный электронной подписью документ, но чтобы подпись осталась валидна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 22:08 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
hVostt, спасибо большое, что откликнулись на мою тему. Я тоже уже подумываю над СУБД с поддержкой шифрования. Django может работать с PostgreSQL. Попробую посмотреть как это можно задействовать и можно ли. Дело в том, что сервис работает с личными данными пользователей. Эту информацию и хотелось бы хранить в зашифрованном виде, но с возможностью расшарить ее в нужный момент, определенной группе лиц (этих пользователей определяет сам пользователь-владелец данных). Соответственно любой несанкционированный доступ к этой информации критичен, кроме этих лиц (владелец, доверенные лица владельца). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 22:24 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544Дело в том, что сервис работает с личными данными пользователей. Эту информацию и хотелось бы хранить в зашифрованном виде, но с возможностью расшарить ее в нужный момент, определенной группе лиц (этих пользователей определяет сам пользователь-владелец данных). Соответственно любой несанкционированный доступ к этой информации критичен, кроме этих лиц (владелец, доверенные лица владельца). Пока сложно понять спектр решаемых задач. Если ключи будут храниться на сервере, как и само шифрование будет выполняться на сервере, то защита примерно такая же, как если бы сервер сам шифровал одним единственным ключом, который знает только он. Т.е. шифрованная СУБД :) Иначе всё должно шифроваться только на стороне клиента без участия сервера, а сервер будет принимать бессмысленный для него набор байт и хранить. Если информацию надо "расшарить" пользователям, но надо для каждого индивидуально зашифровать контект, или завести один единственный ключ на группу пользователей. Но тогда выход из группы любого потребует перевыпуск ключей и перешифрование. В общем. Пока мало что ясно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 22:54 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
hVostt, давайте на примере:)? Я Вася. Зарегистрировался на сервисе и создал свой аккаунт. Вася (Я) создаю заметку с текстом на клиенте, шифрую ее и сохраняю на сервере. (на сервере будет бессмысленный набор байт) Я могу загрузить эту заметку и расшифровать, откорректировать и заново сохранить (также в зашифрованном виде). У Васи (у меня) есть друг Петр. Я добавляю в свои друзья Петра (петр, номер_телефона, почта). Шифрую эту информацию и сохраняю на сервере (в шифрованном виде). Аналогично могу все сделать тоже самое что и с заметкой (получить и расшифровать, отредактировать и тд). Происходит событие на сервере (например настала полночь) и в связи с этим событием необходимо расшарить информацию Васи (его заметки) Петру, чтобы тот мог их просмотреть. Без ключа Васи сделать это невозможно.( Но очень хочется) Почему хочется хранить все в шифрованном виде: 1) Информация критичная и конфиденциальная 2) Даже через HTTPS не хочется ее гонять в открытом виде 3) У сервера есть админка и шарить все данные пользователей админу не хочется, а так админ видит некритичные вещи, а критичные для него бессмысленный набор байт 4) В случае получения доступа к серверу вся информация на нем зашифрована и толку от нее немного. Получается что да, я сам себя обманул и все зашифровал от самого же себя) Я думал про ассиметричный алгоритм, но в таком случае пользователь с публичным ключом, а сервер с приватным. Соответственно один раз зашифровав данные пользователь не сможет их расшифровать обратно (так как с сервера они будут приходить в шифрованном виде). Было еще такое решение: Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?) Тогда через HTTPS как надежный канал связи гонять информацию в открытом виде, а при сохранении в базу шифровать. Но опять же, ключи/ключ для дешифровки будет на сервере, что в случае несанкционированного доступа сводит все это на нет))) Кстати если что, то можно кидать тапки), тухлые яйца и еще что нить) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 23:17 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544, Суть ассиметричного шифрования -- защита ключей. Зашифровать можно открытым ключом, а расшифровать только закрытым. Больше ничего. Вы не можете "расшарить" информацию Петру. Для этого вам надо либо поделиться с ним своим закрытым ключом. Либо ВСЕ перешифровать и продублировать информацию для Петра. А если добавится ещё Лёлик и Болик, то ещё два раза всё повторить. HTTPS уже реализует необходимую защиту информацию от кражи при передаче по сети. Дополнительное шифрование, добавляет только геморроя, но не усиливает защиту. Но для предотвращения атаки man-in-a-middle, всё равно придётся кому-то доверять, третьему лицу. Суть в том, что если два пациента хотят общаться между собой совершенно секретно, абсолютно секретно, им нужно лично встретиться друг с другом и передать друг другу флешки с открытыми ключами. Зачем? Чтобы потом этими ключами обмениваться временными ключами для синхронного шифрования на каждую сессию. Но.. погодите-как, это же и есть HTTPS :) Зачем нужна СУБД с шифрованием? Чтобы не могли слить файлы БД и получить доступ к информации. Если приложение и СУБД разнесены по разным серверам, то это достаточно надёжный способ обеспечения защиты информации. Но как я и сказал, шифрование это когда все заранее договорились. Нельзя брать на борт Васю и давать ему какие-то персональные ключи для доступа к информации, с возможностью их отобрать. Берём на борт Васю, договариваемся заново, и всё с нуля. Но до сих пор конечная задача не ясна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 23:29 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?) Пока не определены конкретные задачи, что именно и от кого защищаем, при каких условиях и в каких сценариях конкретно, довольно сложно сказать даже приблизительно, есть ли в этом смысл :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 23:32 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
hVostt, Про ассиметричное шифрование понятно. Я так и предполагал, что оно не применимо здесь. По поводу задачи - давайте абстрагируемся. Просто примем, что она есть). По поводу расшарить мне виделось это так - мы высылаем Петру по SMS link и код авторизации. Петр заходит на веб страницу, вводит свой код и мы ему в респонсе высылаем расшифрованную информацию. Простите, что не пояснил сразу. HTTPS однозначно используем. СУБД и приложение на одном сервере и разнести их к сожалению навряд ли получится. Ваш последний пост меня честно говоря немного начинает печалить, в плане того, что кажется решить данную задачу похоже не представляется возможным(. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2018, 23:41 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
hVosttILIs544Оставить все шифрование на серверной части (но есть ли в этом смысл тогда вообще?) Пока не определены конкретные задачи, что именно и от кого защищаем, при каких условиях и в каких сценариях конкретно, довольно сложно сказать даже приблизительно, есть ли в этом смысл :) Ммм... Вася создает заметки на мобильном устройстве и сохраняет их на сервере. Также Вася создает записи доверенных лиц то есть контакты (я прошлом посте я назвал друзьями). Вася также сохраняет свои контакты на сервере, причем эти контакты могут не иметь аккаунта в этом приложении. При определенном событии на сервере, заметки Васи, должны быть показаны его контактам. (как я и писал, контактам приходит линк и код, они идут по линку через https и вводят код для авторизации и видят заметки Васи). Защищаем мы заметки Васи от любого несанкционированного доступа, т.е. на тот случай если: трафик Васи при создании заметок будет перехвачен администратор, который может смотреть админку тоже не должен видеть заметки Васи будет утянута база будет несанкционированный доступ к хостингу (тут вообще может что-нибудь помочь?:)) если база находится там же где и приложение то мне кажется последние 2 пункта связаны друг с другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 00:51 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544Защищаем мы заметки Васи от любого несанкционированного доступа, т.е. на тот случай если: трафик Васи при создании заметок будет перехвачен администратор, который может смотреть админку тоже не должен видеть заметки Васи будет утянута база будет несанкционированный доступ к хостингу (тут вообще может что-нибудь помочь?:)) Вот с этого нужно было начинать. Потому что это цель. А всё остальное - пустота. Если цель состоит только в шифровании заметок, то адреса контактов под такую цель не попадают и, соответственно, их можно хранить в открытом виде, ну и отправлять по ним всякую шифрованную дрянь, которую клиенты уж как-нибудь сами переварят. Если они сами не переваривают, то тогда у них один путь - доверять посреднику. Но посредник может создать для них туннель, по которому можно обеспечить взаимодействие между браузерами, например через https. При этом останется проблема обмена ключами между пользователями. Посредник может предложить им найти удобный способ (подсказать варианты). Например - качаете тулзу такую-то, она делает вам ключ, шлёте его через предпочитаемую почту своим друзьям, ставите полученные от друзей ключи в браузер и далее смело рубитесь в порно-игры через предлагаемый посредником туннель, ваш обнажённый торс посредник не увидит. Здесь опять встаёт проблема доверия, но уже скачанной тулзе и каналу передачи ключей. Но поскольку тулза и канал скорее всего не знают о назначении создаваемых/передаваемых байт, то про порно-игры могут и не догадаться. Ну а если догадаются - Васе с Петей придётся раскошелиться за ограничение публичности их занятий перед монитором писюка :) В общем - снимаете с себя ответственность за канал и тулзу, заявляя, что лучший способ передачи - из рук в руки. Ну а джанги там всякие и прочие поделия к теме вообще никакого отношения не имеют. Это лишь мусор, набрасывая который вы упорно не давали нам вас понять. Потому что если вы уж взялись за какую-то джангу, значит оно вам нравится и вы готовы приседать до упаду ради реализации правильного подхода на вами любимой джанге или ещё какой приблуде. Для нас от названия приблуды ничего не меняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 09:15 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
GDPR что-ли так сильно по голове ударил, не пойму? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 09:31 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
alex55555, Благодарю что откликнулись. В целом понятно. Вывод который я сделал - Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера. Тогда когда нужно будет отобразить Заметки Васи, Петя переходит по ссылке и ввод ключ, который он получил от Васи. И может расшифровать и посмотреть его Заметки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 10:38 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
skyANA, Нет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 10:39 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544alex55555, Благодарю что откликнулись. В целом понятно. Вывод который я сделал - Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера. Тогда когда нужно будет отобразить Заметки Васи, Петя переходит по ссылке и ввод ключ, который он получил от Васи. И может расшифровать и посмотреть его Заметки. Третий курс, основы защиты безопасности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 10:45 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
skyANA, к сожалению в то время, пока я не сталкивался с такими задачами, это было не интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 11:31 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
ILIs544Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера Все смешалось в доме Облонских... Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать. А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением. Нужно понимать, что "несанкционированный доступ" не равно "зашифрованные данные". Обычно используют саму СУБД с шифрованием на случай кражи файла с БД. Тогда информация бесполезна. А авторизацию доступа к данным осуществляет прикладной уровень. Защита от перехвата на транспорте - использование защищенных туннелей, SSL/SSH не суть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 11:52 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
Arm79ILIs544Чтобы от этого шифрования был какой либо смысл, пользователи Вася и Петя должны меняться ключами без участия сервера (по электронке, физически их друг другу передавать), главное без участия сервера Все смешалось в доме Облонских... Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать. А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением. Нужно понимать, что "несанкционированный доступ" не равно "зашифрованные данные". Обычно используют саму СУБД с шифрованием на случай кражи файла с БД. Тогда информация бесполезна. А авторизацию доступа к данным осуществляет прикладной уровень. Защита от перехвата на транспорте - использование защищенных туннелей, SSL/SSH не суть. В чем недостаток обмена ключами для симметричного шифрования? По крайней мере я пока хотел на этом остановится, по крайней мере для начала. Про несанкционированный доступ и зашифрованные данные я что-то путаю? СУБД с шифрованием это я тоже понял. Но как я понял, это поможет в случае кражи файла. А так как БД и веб приложение находится будут в одном месте, то получив доступ к аккаунту, который используется для хостинга, дальше уже можно крутить вертеть как угодно. Но от этого я так понимаю, можно спастись только если сервер находится в твоем здании, с нужными политиками безопасностью и т.д. А утащить бд без доступа к аккаунту, который используется для хостинга не уверен, что возможно. Про перехват на транспорте понятно. К этому нет вопросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 12:08 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
Arm79Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать. Так и должно быть. Как минимум автор озвучил такое ТЗ. Количество ключей так же не проблема - шифрует клиент (браузер, например). Arm79А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением. Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи. Arm79Обычно используют ... Вы ТЗ прочитайте, а что там и для чего "обычно используют" - это к маркетолухам, они вам и не такое споют. В общем - не нагоняйте жути, ваш ход гораздо страшнее :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 13:59 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
alex55555Arm79Использование асимметричных ключей приведет к тому, что вам придется ваши заметки шифровать тем количеством сертификатов, которое равно количеству ваших адресатов. При этом ранее созданные заметки для всех новых адресатов просто будут недоступны, если их не перешифровать. Так и должно быть. Как минимум автор озвучил такое ТЗ. Количество ключей так же не проблема - шифрует клиент (браузер, например). Не сможете подсказать как это реализовать в рамках моей задачи? Могу тупить. Но люди, которым надо отправить заметку могут и не быть зарегистрированными пользователями сервиса. Я могу не верно понимать, если что думаю пнете. Ассиметричное шифрование это если у сервера будет private ключ, и он будет выдавать public ключи для шифрования. Тогда пользователь сервиса шифрует свою заметку public ключом и отправляет через https на сервер. Сервер сохраняет. Когда наступает время показать заметку человеку из списка контактов, мы генерим для него link и одноразовый код и отправляем это по SMS на телефон. Переходя по ссылке он вводит код в форму, и отправляет запрос через https на сервер. Сервер private ключом расшифровывает заметку и через https отправляет ее доверенному контакту. Я хоть что-нибудь правильно понял? Или все не правильно :)? alex55555Arm79А ручной обмен паролями для симметричных шифров - я затрудняюсь назвать это хоть каким то решением. Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи. Вот это явный недостаток, потому что юзеру надо будет свои друзьям передать ключ, а ключ абракадабра, да плюс по пути передачи не известно кто еще его увидит и так далее. Но вариант легко реализуемый в данный момент и вроде как достаточно надеждный. Но это добавляет боли пользователю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 15:33 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
alex55555Так и должно быть. Как минимум автор озвучил такое ТЗ. Автор озвучил СВОЕ решение поставленной проблемы. Я считаю, что такое решение не годится никуда. alex55555Количество ключей так же не проблема - шифрует клиент (браузер, например). количество никак не связано с тем, кто шифрует alex55555Если юзер готов платить своим временем за свою безопасность - вы затрудняетесь обеспечить ему решение его задачи. это не решение, это мазохизм alex55555Arm79Обычно используют ... Вы ТЗ прочитайте, а что там и для чего "обычно используют" - это к маркетолухам, они вам и не такое споют. Надо полагать, вы читали это ТЗ? А не ограничились вольным пересказом ТС? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 21:25 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
Arm79, Ребят не меряйтесь знаниями) Если есть возможность и какое-то решение (я не думаю что то о чем я говорю это что-то сверхновое:)) то объяснить так сказать для самых маленьких). Я буду очень благодарен. Говорю же любая здравая дискуссия приветствуется. Решение с передачей ключа пришло в результате обсуждения как действительно достаточно надежное. Хоть и болезненное в плане user experience. Arm79, сможете попроще объяснить свою идею? Был бы благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 21:41 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
вариант: 1. шифруете заметку симметричным ключом с известным пользователю паролем. 2. если пользователь хочет дать доступ к своим заметкам определенному кругу друзей, то он с помощью сертификатов этих друзей шифрует свой пароль, получившийся массив данных крепит к своей заметке (отношение 1 ко многим) 3. любой пользователь может скачать и зашифрованную заметку, и зашифрованный кучей сертификатов пароль. Но если нет закрытого ключа от любого сертификата, расшифровать пароль не получится. И доступа к содержимому заметки также не получить Необходимо также заложиться на смену пароля у заметки (+ отмена прикрепленных шифрованных паролей), а также управление сертификатами и ведение списка отозванных сертификатов Кстати, пароль пользователя может быть случайным для каждой заметки, если вы защитите его приватным ключом самого пользователя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 21:51 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
на примере: Есть Вася, Петя и Саша. У каждого есть свой набор ключ-сертфиикат Вася создает заметку На созданную заметку генерируется GUID в качестве ключа гаммирования Заметка шифруется симметричным ключом (GUID-ом) Далее, Вася решает, что доступ к заметке должен иметь и Петя, и Саша. Он шифрует своим сертификатом и сертификатами Пети и Саши сгенерированный GUID Далее набор "Шифрованная заметка" и "Список доступа" (в общем случае таким списков много) выкладывается на сервер Саша скачивает заметку, получает все списки доступов и пытается своим приватным ключом расшифровать любой из них. Ему удается, и он получает расшиaрованный GUID. Применяя этот GUID в качестве ключа расшифровывает заметку. А вот произвольный Максим уже такого не сможет. Далее, Вася решил добавить Максима в список доступа. Перегенерировать ничего не нужно. Просто к заметке добавляем еще один список доступа (из одного человека). Удаление аналогично. При смене пароля заметки, все списки доступа должны перегенерироваться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 22:04 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
а вот смс-кой уже низзя это схема для зареганных пользователей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 22:06 |
|
||
|
Безопасность и шифрование данных
|
|||
|---|---|---|---|
|
#18+
Arm79, Сейчас я вникну и отвечу. Это отличное и удобное решение . Но, я могу ошибаться, у него есть кое-какое ограничение, а именно как в Вашем последнем посте. Если быстро попробую объяснить, но могу и ошибаться: В таком случае Петя должен еще до шаринга, поставить себе какое то клиентское приложение которое сгенерит ему приватный ключ и оставит у него, и публичный, который будет сохранен на сервере и ассоциирован с Петей. В этом случае, Вася как раз и возьмет публичный ключ Пети и проделает все о чем Вы говорите. Все сохранит на сервере и в нужный момент Петя с клиента откроет то расшаренную заметку, заюзает свой приватный ключ, расшифрует ключ симметричного шифрования и прочитает заметку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 22:21 |
|
||
|
|

start [/forum/topic.php?fid=33&fpage=5&tid=1547223]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
89ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 209ms |

| 0 / 0 |
