Личные данные пользователей

[Николай Степанченко]

Защитить от нас или любого другого постороннего-то мы сможем. Симметричное шифрование паролем пользователя дает доступ к данным только человеку, знающему пароль. Но сложность конечно это вносит. Дополнительно еще возникает вопрос с авторизацией через соц.сети. Либо использовать отдельный пароль для шифрования личных данных. Например как в платежных системах - отдельный платежный пароль. Как говорится "вопрос, конечно, интересный".

Собственно, господа, какие вы видите варианты исполнения? 

на мой взгляд, вариант с платежными системами очень не плох, но я не знаком с альтернативами, если таковые имеются, да и текущая система не самая удобная, на пример у web-money. 

два требования, которые на мой взгляд будут уместны:

1. надежность. 

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

каким бы сложным шифр не был, его можно взломать. это только вопрос времени и желания. 

2. это должно быть легко и удобно для пользователя. 

в противном случае, когда человек вобьет свой пароль 3-й раз за 10 минут, и поломает глаза на капче, он забьет и полезет в гугл, так как надоест.  

[Дмитрий Широков]

Хранить данные на компьютере пользователя и никогда не высылать нам.

http://www.linkexchanger.su/2011/729.html WebStorage из ящика HTML5 же!

[Дмитрий Широков]

Или высылать, но через SSL и никуда не сохранять (на сервере).

[bat...@gmail.com]

C WebStorage есть проблема: пользователь залогинится с другого браузера и ничего не увидит.

[Дмитрий Широков]

Да, но человеку нужен принтер для распечатывания этих документов -> скорей всего это будет сделано из дома / с работы, всего ~два браузера.

+ я бы вообще дал человеку возможность 

• не вводить данные и заполнить их руками потом на листе
  
• вводить и не сохранять нигде

[evg...@skbkontur.ru]

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

Мне кажется, что тут надо в первую очередь думать об удобстве (я уже писал про регистрацию как в твиттере или alco.kontur.ru, явно данные хранятся по важнее, чем у нас).

Еще скажу, что я в этих системах ничего не понимаю, поэтому спорить не буду, если моя идея не подходит, значит не подходит.

[Pavel Titov]

Насколько я понимаю, идет речь об автозаполнении последующих заявлений. Для этого необходимо хранить ФИО, серию и номер паспорта, адрес.
Я тоже придерживаюсь мнения, что подобную информацию нистоит нигде сохранять.

[Павел Макаров]

Вообще я опирался на следующий документ в юридической группе:
документ

[Николай Степанченко]

помнится, пару лет назад у моего коллеги подруга паспорт потеряла. 

и не подала заявление в полицию сразу. 

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

так что аккуратнее со своими паспортными данными, и уж тем более с чужими. 

[Николай Степанченко]

если ничего не путаю, то в первую очередь должны идти защищенные протоколы связи. 

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

и да, еще один нюанс-не использовать сервера на территории РФ. во избежание их изъятия, вместе с пользовательскими данными.

[Pavel Titov]

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

[Дмитрий Широков]

А не важно, есть у нас уничтожение пользовательских данных, или нет. Важно хранятся они у нас, или на компьютере самого пользователя.

[Николай Степанченко]

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

[Oleg Yasnev]

Опрос, да, не помешает. Но для опроса все равно нужно предоставить варианты решения... Их пока время есть и обсуждаем раз уж обсуждается, а то сегодня после вчерашнего "затишье" :)

Попробую порассуждать. Если совсем нигде не хранить данные, то это будет вносить некие неудобства. Паспортные данные - это не ФИО, которое помнишь наизусть, а перебивать из паспорта всякий раз удовольствие невысокое. Если хранить на клиенте (например, в мобильном приложении), то получается жесткая привязка либо к этому клиенту (браузер, телефон), тогда как у пользователя должна быть возможность использовать любой клиент без неудобств. Если говорить о синхронизации данных между клиентами, то тут уже задействуется сервер, да и вообще синхронизация тут явно ни к чему. В чем минусы для пользователя в хранении на сервере? Я пока вижу следующее: в открытом виде предоставлять данные, понятно, захочет не каждый. Шифрование, хоть и безопасно, вносит лишние сложности для юзера в связи с запоминанием пароля. Учитывая, что регулярно сайтом пользоваться вряд ли кто будет - пароль забудут однозначно. Восстановить пароль мы здесь не сможем, сможем только поменять, однако зашифрованные данные все равно будут бесполезны. Честно говоря, такое мне тоже не нравится. При таких раскладах лучше, действительно, и не хранить вовсе - не так уж часто один и тот же юзер будет заявы-то писать...

[Николай Степанченко]

есть у Близзардов полезная весч. аутентификатор называется. оставлю линк здесь. 

почитайте, мне кажется Вы более грамотно сможете определить целесообразность применения подобного решения, чем я. 

[Павел Макаров]

Если пользователь зарегистрирован, то шифровать можно и его паролем (проверить то по хешу сможем).
Если авторизация через соц-сети, то можно построить так: что нужно выбрать и/или написать ответы на 3 вопросы - они составят фразу и будут паролем.
Надо придумывать.

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

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

[bat...@gmail.com]

Это генератор одноразовых паролей для двухфакторной аутентификации. Такие во многих системах используются. Только они таки денег стоят и нужно время на получение + некоторые телодвижения для привязки такого аутентификатора к сервису (телодвижения со стороны пользователя).

А вообще мне кажется рано мы начали обсуждение технической реализации. До нее нужно определиться с правовой стороной. Да и до версии 2.0 хорошо бы 1.0 сделать :)

[Николай Степанченко]

еще немного информации о нем: он не использует интернет-соединение для работы, но только для периодических синхронизаций. как я понимаю, там используется алгоритм, на сервере и на клиенте, который генерирует одинаковую последовательность цифр с одинаковым интервалом времени. что-то по типу ГСЧ, только с графиком и системой. 

[Pavel Titov]

Стоит ещё рассмотреть юридическую сторону хранения персональных данных.
Тут стоит обратиться за помощью к юристам. То, что мне удалось нагуглить не слишком обнадеживает:

Согласно Федеральному закону о персональных данных:
Статья 9.3
Обязанность предоставить доказательство получения согласия субъекта персональных данных на обработку его персональных данных, а в случае обработки общедоступных персональных данных обязанность доказывания того, что обрабатываемые персональные данные являются общедоступными, возлагается на оператора.

Статья 9.4
В случаях, предусмотренных настоящим Федеральным законом, обработка персональных данных осуществляется только с согласия в письменной форме субъекта персональных данных. Письменное согласие субъекта персональных данных на обработку своих персональных данных должно включать в себя:.....

[Павел Макаров]

Я всегда думал, что достаточно галочки "Согласен".
А если пользователь больше не хочет - обращается с официальным письмом (хотя можно и попроще).
И ещё вопрос. Что если шифровать/расшифровывать данные на клиенте, т.е. в браузере?
А передавать и хранить на сервере уже зашифорванные.

[Pavel Titov]

Я вижу следующие преимущества и недостатки шифрования на стороне клиента:
+ Увереность, что сервер имеет доступ только к зашифрованным данным. Что не может не порадовать параноиков.
+ Относительная безопастность данных при использовании публичного Wifi.

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

Мне кажется, что если и стоит шифровать данные на клиенте, то как дополнительное средство для параноиков.

[Pavel Titov]

Под подбором ключа я имею ввиду не брутфорс, а как минимум словарь. В последнее время сайты ломают весьма активно и база в несколько миллионов логинов:паролей не проблема.

[Сергей]

Ребята, посмотрите как реализовано в РосЖКХ  -  http://www.roszkh.ru/
Думаю, их решение продумано с юридической точки зрения и ее технической реализации.

[Pavel Titov]

РосЖКХ автоматически не заполняет ФИО авторизированного пользователя, только его адрес с индексом. Но у них заявления проще, там указываются только ФИО, адрес, индекс и описание проблемы.
В нашем случае в заявлениях присутствует гораздо больше паспортных данных. И если свои ФИО пользователь врядли забудет, то серию и номер паспорта помнят не все.

[Павел Макаров]

А против блочных алгоритмов шифрования вроде ГОСТа и AESа точно взлом по словарю эффективен? Ведь 1 символ меняет весь блок.

[Pavel Titov]

Предположим есть словарь вида login:password, составленный на основе баз других сайтов (базы можно найти в паблике или купить).
И есть данные: login:hash(password):encode(data, password). Зная encode() я же могу написать функцию decode() и прогнать через decode(data_encoded, password) пароли своего словаря. Причем это будет offline атака.

[Павел Макаров]

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

[Николай Степанченко]

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

[Павел Макаров]

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

[Pavel Titov]

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

[Николай Степанченко]

понятно.. ну значит отпадает