Pull to refresh

Comments 53

Это такой намек на то, что в ближайшие часы будет обнаружена слитая база клиентов Timeweb?

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

Так, окей — вы ко всем базам относитесь как к утекшим. Что дальше? Ощущается, как будто нужно продолжение.

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

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

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

Утечка данных не вредит исходной базе данных, не нарушает работу её владельца.

Утечка данных вредит только людям, которые передали свои данные владельцу базы данных.

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

  2. Для емайлов брать надёжный хостинг, например протон

  3. Везде, где можно, юзать 2FA

  4. Иметь два телефона - финансы итд - один, котики - другой

  5. Скачиваться базу pwned, скажем, раз в неделю, и искать в ней своё.

  6. Записывать пароли ассоциативно (например, К*****н, который живет на крыше)

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

  8. Нигде не регистрироваться ради бонусов и промо-акций (в силу закона энтропии на дальнем горизонте выйдет дороже)

  9. Короче, разделять свой цифровой Титаник на отсеки, и подозрительно смотреть в оба вперёд насчёт айсбергов ;)

«Войны нельзя избежать, ее можно лишь отсрочить — к выгоде вашего противника.»
— Николо Макиавелли

Хотел было поинтересоваться, а не относятся ли эти слова к

Макиавелли - это уже попса для айтишников (просто интересное наблюдение).

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

Но это всё профилактика, а *с последствиями утечек* то как бороться?

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

Можно сменить паспорт, место жительства, телефон, имя с фамилией и даже пол. Главное биометрию не оставлять. Её сложнее сменить :)

  1. Я бы предложил для "временных" сервисов использовать одноразовую почту, а для постоянных 2-3 почты, но под каждую группу имхо бессмысленно, т.к. групп может быть очень много.

  2. К сожалению протон показал себя как не очень надёжный.
    https://dtf.ru/life/858403-protonmail-sdal-svoih-polzovateley-aktivistov-vlastyam-francii . При том что они позиционируют себя как сервис который не журналирует данные ip и прочую информацию, но как оказалось - очень даже.

  3. Согласен.

  4. Большой погоды не сделает, т.к. уникальных номеров (если это не номер которому больше 10 лет у одного владельца) нет, и все + - номера слиты, но не все могут иметь реальное соотношение: Номер - человек.

  5. К сожалению, данный совет во-первых, бесполезен, т.к. проще (и лучше, но тут решать каждому самостоятельно) раз в неделю/месяц менять пароли (вне зависимости от компрометации). А во-вторых, если нет платных подписок на форумы со слитой информацией, получить актуальную информацию практически невозможно. Различные ТГ каналы со сливами, обычно дают всякий шлак, большая часть которого итак в открытом доступе.

  6. Я бы предложил юзать программы по типу keepass, а не придумывать ассоциативные пароли (которые тоже при должном желании можно подобрать), а к паролям типа: x23ja%!=|=! ассоциации кроме как "хаос", не приходит.

  7. И да и нет. Это может быть полезно если это условно сервис какой-то одноразовой игры. А вот если это аккаунт от важного сервиса, даже банального steam аккаунта, ввод некорректных данных может помешать восстановлению в случае утери/краже, при общении с ТП.

  8. В целом согласен.

  9. Лучшая защита в интернете, отсутствие интернета. (что для айтишника почти невозможно).

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

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

Keepass опасен тем, что он - единственная точка отказа. Список plain text’ом с загадками на основе только Вам известных фактов в какой-то степени надежнее. Равно как старый шпионский приём - индекс страницы-строки-слова в некой книге на полке. В реальности большое количество непроизносимых символов в пароле не делает его более стойким относительно человекочитаемого, кроме очевидного списка банальностей. Пароль вида “в огороде бузина..» может быть порядково надежнее и порядково же проще к запоминанию.

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

А обычный человек от комфорта не откажется. К примеру, записаться к врачу через интернет, в десятки раз удобнее, чем сходить до поликлиники. (т.к. дозвонится это ещё тот челлендж). Хоть второй случай гораздо безопасней.

Я предлагаю вводить 100% ответственность за ущерб из-за утечки к «хранителю» чувствительных данных. Например, сходил я к стоматологу, а у него украли мою учетку и я понес из-за этого 1 млн потерь, так их списать со стоматолога. Или если угнали фотку снилс из госуслуг — то снять бабло с госуслуг.

Можно еще в момент передачи своих данных какому-то сервису выставлять цену штрафа в следствие их угона. Типа: «я вам даю свои емэйл, ФИО, фотку и номер паспорта, вот на них электронная печать, если они всплывут в даркнете — с вас 1 млн штрафа.»

Я так понимаю, в этом и есть определенная сложность: а как оценить свои потенциальные потери?

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

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

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

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

Здесь сложно посчитать потери. Т.к. далеко не все пытаются юзать данные для прямого мошенничества. Некоторые подкручивают рекламу, чтобы вам в нужный момент вылезла реклама зубной пасты например.
Не просить же процент от "упущенной" прибыли? :)

обычно утекает много данных -> списывать будут коллективно -> например на 100 пострадавших будет 100 млн возмещения (из вашего примера 1 млн потерь) -> значит проще бизнес закрыть-продать-обанкротить, чем заниматься такой выплатой

еще вариант, обработкой данных в бизнесе будут перекладывать на какое-то стороннее юр.лицо типа однодневки, которое будет "мальчиком для битья" в случае проблем, а основной бизнес/юрлицо будет работать и дальше

возможно, поскольку все-таки это риски ущерба, то надо мыслить в сторону страхования - страховать риск утечки. по аналогии с ОСАГО/КАСКО и в анкете на согласие обработки персональных данных указывать кто страхует ответственность бизнеса, и если нет страховщика, то вы вправе выбрать другой бизнес, который все-таки застраховал свою ответственность.

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

как вариант
всяко лучше чем полный бардак и халатность сейчас
Можно еще в момент передачи своих данных какому-то сервису выставлять цену штрафа в следствие их угона. Типа: «я вам даю свои емэйл, ФИО, фотку и номер паспорта, вот на них электронная печать, если они всплывут в даркнете — с вас 1 млн штрафа.»

Тогда надо еще запретить сервису отказываться от сотрудничества если сумма выше 666 рублей. Иначе это дыра.


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


Либо когда контора считает что им должны данные должны предоставить потому что закон такой (регистрация ру-доменов).

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

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

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

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

Только по паспорту и например только в отделении.

Проблемы сразу:


  • как быть если паспорта нет в данный момент(переформление например, или это не гражданин РФ, или просто утеря — тогда справку дают — ее брать?)
  • как быть если паспорт меняется (при утере или там по возрасту) — в обязательном порядке требовать от клиента обновить данные везде где был старый паспорт выдан?
  • как быть если нужно удаленно работать?(я имею ввиду как модель Тинькова так и фичу с удаленным открытием счетов через ЕБС) — как минимум нужен доверенный способ для удаленной проверки тоже и при этом учитывать в каких условиях это реально будет работать и как защищать доступ к этой системе.

x23ja%!=|=! ассоциации кроме как "хаос", не приходит.

x23 япошка процентов самолётик

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

4) основная проблема телефонов - нешифрованный SS7 и вероятность угона номера. Не спасут рекомендации.

5) параноя. жить страшно. остальные пункты - тоже самое.

Спасибо за 5 и 7, надо будет осмыслить.

В реальности утечка данных конкурирует с параллельно возможным процессом — потерей данных. И в реальности, со временем чаще всего реализуется именно потеря/уничтожение/стирание данных, а система переходит в стабильное состояние «данные отсутствуют».

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

Из того, что какое-то событие имеет ненулевой шанс произойти вовсе не означает, что надо действовать так, как будто это событие уже произошло. Можно к нему быть готовым, это да, но действовать будто оно уже случилось, как-то не правильно. Все люди когда-нибудь умрут причем вероятность оного события 100%, но это вовсе не означает, что всем срочно пора в крематории или самозакапываться в землю.

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

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

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

Это вы список утечек.

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

Да там много чего есть.

рассматриваете только как пользователь

что делать сервисам, чтобы их БД, даже утекши, не несли чувствительных данных? или невозможно было использовать на стороне?

на стороне компании даже если данные будут разнесены по базам данных, разным сервисам есть возможность собирать и "компилировать" новую бд с сопоставленными данными

Тем не менее, если разнести разные части данных по разным базам и разграничить доступ - то получится резко сократить вероятность этой «компиляции». См. кейс Яндекса, где дамп одной базы содержал все данные.

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

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

Вариантов много, все это давно известно и работает. Надо просто не забивать на это.

А в текущей реальности, когда нет ни нормальных штрафов, ни репутационных рисков (в России, по крайней мере), всем наплевать. Вот сбер например до начала войны пытался строить компанию мирового уровня, думал о репутации (какая она ни была) - и сбер крепко усвоил урок, полученный после слива данных. Безопасность такие чистки устроила, так инфраструктуру затрахала, что пыль стояла. Так должно быть везде. И, желательно, заранее.

спасибо за ваш комментарий, почитал про DPAN

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

какие инструменты использовать, чтобы разработчикам было прозрачно подключить их к их сервисам и приложениям, чтобы эту безопасность можно было включить быстро, дешево и сердито? какие-то обертки над библиотеками по доступу к данным?

вариантов много и каждый может придумывать свои костыли. вот в плане авторизации сделали oAuth для логина в веб-сервисы, и стало очень удобно, ваши пользователи авторизуются через любой сервис Google/VK/другой сервис oauth-провайдер. и безопасно, т.к. вы по сути не занимаетесь авторизацией

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

интересуют стандарты/книги/блоги/статьи

как пример, snyk.io интегрируется в процесс CI/CD просто, внедряешь и регулярно сканируешь свой код и зависимости на уязвимости - поддерживать проект актуальным достаточно дешево

Я инфраструктурный инженер/менеджер, к data governance отношения мало имею, потому не могу ответить на Ваш вопрос.

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

Но кроме статей - есть же банальная логика. Вы, конечно, правы - вопрос цены. Тот же Яндекс - пока штраф за утечку 60к, а рынок монополизирован, им выгоднее держать все данные в одной базе. Так же проще жить, дешевле писать. Атмосфера всеобщего доверия и большого стартапа, опять же. Знаю про это из первых рук.

> А вы что думаете?

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

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

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

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

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

Как быть с буквенными номерами?
Как быть с ситуацией когда с этого номеру идут коды двухфакторной авторизации НЕ Российских сервисов (их то сложно заставить отдельно регистрироватся). Вообще прибить двухфакторку по смс для не-российских контор?

Как быть с буквенными номерами?

Речь про всякие 900 и VTB? Так вроде как это для смс, звонки поступают с вполне привычных цифровых номеров. Другого не встречал как-то.

Как быть с ситуацией когда с этого номеру идут коды двухфакторной
авторизации НЕ Российских сервисов (их то сложно заставить отдельно
регистрироватся). Вообще прибить двухфакторку по смс для не-российских
контор?

Не очень понимаю суть вопроса. Есть номер, он у ОПССа как-то значится в базе, вот и показывать.

Я принципиально не понимаю зачем делать тайну из информации о том кто собственник номера. Что телефона, что автомобиля.

Речь про всякие 900 и VTB? Так вроде как это для смс,

Речь всякие Info (с которых двухфакторка например Амазона )


звонки поступают с вполне привычных цифровых номеров. Другого не встречал как-то.

А почему разговор только про звонки? Мне вот не сосовсем очевидно


Даже при звонках — есть же услуги вроде "Скрытый номер" и обход сокрытия + есть возможность подмены номера на уровне оператора (другое дело что например те же Zadarma/Novofon проверяют что пользователь номером владеет + в некоторых случаях вообще нельзя подмену… видимо операторы могут проверять подменные номера на корректность).
Ну и можно сделать проверку универсальной — в США вот сделали ж STIR/SHAKEN


Я принципиально не понимаю зачем делать тайну из информации о том кто собственник номера. Что телефона, что автомобиля.

Почему так не сделали сразу — подозреваю что просто изначально не думали что надо, почему сейчас не сделать нечто вроде вроде #WhoCalls/Ктозвонит! но брать данные сразу с опсосов? видимо потому что:


  • владелец номера!=пользователи(дети например или родственники) — будет путаница
  • корпоративные номера — сейчас даже в базах операторов то порядок только наводят (мне как владельцу корпаккаунта приходят требования чтобы владельцы симок сами через госуслуги подтвердили при том что у оператора уже их паспортные данные есть)
  • как быть если номера выделяются динамически? есть такая штука как calltracking — https://zen.yandex.ru/t/calltracking yandex.ru/support/direct/efficiency/turbo-pages-calltracking.html — идея в том что в объявлении на сайте показывается номер, увидевший на него звонит а у получателя сразу высвечивыется на каком именно сайте какое именно объявление и когда было показано, возможно — и кому. Но надо много номеров и зарегистрированы они на провайдера услуги хотя пользователь звонит (и попадает) заказчику услуги. Ладно это на исходящие от пользователя звонки что не так важно. Но кто тут владелец?
  • бывают и ситуации вида — есть человек оператор-калл-центра (который вообще не видит номером кому звонит — их программа выбирает, дозванивается, говорит 'наш звонок очень важен для вас, подождите), есть контора на которую этот человек работает (но не факт что знает — может только скрипты знает), контора по просьбе которой звонок, оператор IP-телефонии, оператор-владелец пула адресов. При этом могут еще и предствлятся "интересно". Ну там — платежной системой виза и мастеркард и вам бонус — карта рассрочки, если согласится — вам позвонят из совкомбанка, или предложения открыть счет в надежном банке (опять же если согласится — вам перезвонят с ВТБ при этом если уточнить — скажут что партнер передал). Кого тут показывать как владельца? Какую то неизвестную организацию — партнера? фио-человека-оператора? заказчика?(а толку — он меняется)
  • или там — звонят и говорят что у нас информация для ФИО, и хотят чтобы им подтвердили что я это ФИО, ответ "Василиса Премудрая" может устроить а может и нет. Реально могут кредит предлагать или наоборот коллекторы. Особенно смешно если ты НЕ ФИО но по телефону этому не верят.
  • ...

Это я все к тому что могут быть есть (и все кроме первого и последнего пунктов — опциональны):


  • оператор-владелец пула номерной емкости
  • оператор-обслуживающий номер (в случае MNP это разные операторы)
  • оператор предоставляющий услугу какую то на базе IP-телефонии
  • организация получающая услугу
  • абонент(а возможно просто человек оператор)

При этом возможны случаи когда либо звонящий либо тот кому звонят не очень то хотели чтобы можно было сразу понять кто это (не принимая звонок). Либо это "кто-то" нельзя нормально и осмысленно прописать и обновлять.


Поэтому максимум что имеем — системы вроде #WhoCalls — база номеров составлена как по список публично засвеченных номеров так и по отчетам пользователей (если 100500 пользователей говорят что с этого номера идет спам и реклама и это контора Рога-и-Копыта то таки будет показываться (а у многих пользователей сразу сбрасыватся) что это Рога-и-Копыта даже если вот этот номер честно куплен ООО Аквалабеан после того как РиК отказались абонентку платить за него).

Мне кажется мы просто о разном.

Я не говорю что оператор должен дать мне однозначную информацию о звонящем.

Я говорю, что лично я, хотел бы чтобы оператор не скрывал ту информацию которую знает сам.

Условно говоря, есть номер который значится на "ООО Рога и копыта", если я увижу такую информацию это фактически ничего не скажет мне о звонящем, но так как с данным ООО меня ничего не связывает я спокойно проигнорирую данный звонок.

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

Прямо сейчас когда на андроиде звонилка сообщает что звонок с условно "билайн/самарская область" сильно облегчает жизнь, ибо нет там у меня контаков и быть не может.

Таким образом если бы была известна информация которая есть у оператора то первичная фильтрация сильно бы облегчилась.

Утгчню - в США только собираются внедрить stir/shaken. Пока, в общем случае, спуфинг Caller ID при звонке по sip из какой-нибудь Индии - норма. И всё равно, это костыль, потому что номера не являются уникальными идентификаторами, ни в мировом масштабе, ни даже внутри страны, потому требование сопоставления Caller ID с данными звонящего однозначного решения не имеет.

А чего не упомянули слитую базу "Паспорт" МВД Беларуси? или тут только то, что подтвердили владельцы и то что потом появилось в открытом доступе?

тут то что нашел за 2 часа поверхностного поиска
не было целью найти ВСЁ, хотел найти достаточно чтоб доказать (себе), что всё сливается

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

Уж что-что, а самолёт вовсе не «работает и забыл». Да и с мостами все не так просто.

Несут.
За ПО самолета например. Но там совсем другие цены. И совсем другие требования по окружению.


Если пользователь на компьютер хз что ставит да еще и система при обновляется в лучшем случае с формального согласия пользователя — никто в своем уме не будет брать ответственность за работу ПО на меняющийся платформе.

В одном фантастическом произведении оплата производилась биометрическим поцелуем. потому что перед этим утекла база биометрии пальцев :)

ЗЫ: Полностью поддерживаю автора.

С 1996 по 2011 я работал/являлся (о, три буквы Я в одном слове)) ИП - индивидуальным предпринимателем. Работал с юр лицами, но в большинстве с гражданами. За эти годы были выписаны тысячи договоров, накладных, счетов-фактур и прочих бумаг с указанием моих фио, инн, даты рождения, данных паспорта, домашнего адреса, телефонов. Розданы десятки, а может сотни копий паспорта, инн, постановки на налоговый учет. Пока живой)) В 2012 сменил номер мобильного. Не, не в целях абстрактной безопасности, а ибо достали старые клиенты и новые желающие.

Sign up to leave a comment.