Нет, то что я очевидно далеко не популярная фигура и что смысла нет "ломать" мои устройство далеко не показатель того что аппараты не ломаются. Вон, сколько случаев было когда нюдсы голливудских звёзд сливали в сеть, ломая Apple Cloud, или как он там называется.
Так что кому надо, смогут взломать кого надо, а для тех кто эти ключи хранит, и вовсе ломать ничего не надо - взял ключ да используй.
Теория заговора теорией, но именно с этим мы и живём, и если закрыть глаза, проблема не исчезнет.
В случае банковских карт платёжные системы применяют формирование номеров карт в соответствии со стандартом ISO/IEC 7812. Это один из международных стандартов, описывающих параметры идентификационных карт и применение таких карт для международного, межотраслевого и/или внутриотраслевого взаимообмена.
Сам стандарт можно прочитать здесь. Он небольшой, всего 12 листов неполного текста.
Формирование номеров по стандарту следующее:
Всегда первые 6 цифр номера - это идентификационный номер эмитента, далее от 4 до 12 цифр - номер лицевого счёта. Последняя цифра - контрольная согласно алгоритму Луна.
Также в номерах банков первая цифра означает тип платёжной системы. Например, 4 - VISA, 5 - MasterCard, 2 - МИР. Но согласно ГОСТ ISO/IEC 7812-1—2014, первая цифра должна означать область деятельности:
авиалинии;
авиалинии и другие, возможные в будущем, области деятельности;
путешествия и развлечения и банковское дело/финансовые услуги;
банковское дело/финансовые услуги;
банковское дело/финансовые услуги;
торговля и банковское дело/финансовые услуги;
нефтяная промышленность и другие, возможные в будущем, области деятельности;
здравоохранение, телекоммуникации и другие, возможные в будущем, области деятельности;
для присвоения национальными органами по стандартизации.
На деле же получаем что банки как бы договариваются друг с другом - авиалинии у себя, а то и не договариваются вовсе, т.к. у каждого своя стойка регистрации и т.д.
Кроме этого, Вы можете заглянуть в эту папку репозитория и посмотреть какие регулярки применяются для определения принадлежности номера той или иной платёжной системе.
Так-то оно так, да вот кто скажет что он сливает данные себе? Тот же Google Authenticator взял и обновил приложение, а при запуске оно взяло и слило все секреты в облако гугла. Типа удобство, но платить за это приходится наличием секретов в облаке, где Гугл может их использовать как захочет и никто кроме них не узнает об этом. То же самое и с биометрией - введут в браузере и вуаля - что и куда оно сливает, кто ж знает.
Так что все эти договорённости и условные стандарты - это лишь голословные заявления, по сути. Как ни крути, а контролированием и программированием людей корпорации давно занимаются. Почитайте историю того же Сноудена или любого другого сотрудника крупной корпорации. Конечно, бывшего сотрудника. Нынешние мало чего расскажут, т.к. им контракт напрямую запрещает это делать.
Технологии это и хорошо, и плохо одновременно. И если бы это всегда было хорошо, то вряд ли бы тоннами блокировались сайты по всему миру и вводилась бы та же цензура. А получение ключей, в том числе биометрических идентификаторов, вопрос времени. И также не стоит забывать про трояны, актуальные до сих пор. Случайно или специально зашли не туда или качнули не то - софт на устройстве и тырит всё, до чего сможет дотянуться. Вот и всё.
Даже у Telegram защиту секретного чата давно сломали. Дуров ещё в начале обещал, не помню точно, 50к зелени, что ли, тому кто прочтёт переписку из его секретного чата с братом. Один хакер смог даже получить тело сообщения, но расшифровать не смог. А спустя время силовики смогли прочитать секретные чаты некоторых людей - забирают телефон и читают. А подобные passkeys сервисы позволят им облегчить эту задачу - достаточно будет через суд обязать сервис выдать ключи биометрии и всё, вот она переписка в прямом эфире, так сказать. И никто не спалит, потому что читающий - владелец этого хэша. И не важно кто им воспользуется и для каких целей.
В этом случае как раз не важно - они получат код активации только по своему секрету, который в аутентификатор добавляется. А вот Гугл получит доступ ко всем сервисам, добавленным в это приложение. Также как и все, кто имеет власть над Гуглом.
С того, что хэш отпечатка пальца и является тем самым биометрическим идентификатором. Когда входим в телефон или ещё куда, камера снимает отпечаток хоть с пальца, хоть с лица, затем из полученной информации вычисляется хэш. Когда есть готовый хэш идентификатор, процесс его расчёта можно пропустить - берём значение и вперёд.
Работал с системой отпечатков пальцев. У нас в офисе в начале рабочего дня и в конце сотрудники должны были палец прикладывать к датчику. Так руководство следило кто во сколько пришёл и ушёл. При этом, можно было легко из базы взять идентификатор (для разработчиков, имеющих доступ к базе, конечно) и выполнить запрос к серверу, подписав его этим хэшем. Тот отпечаток был где-то 512 символов длиной. Точно не считал. Так что это очень легко.
И у Гугла будет часть биометрических данных, которые они смогут использовать где угодно, когда угодно и в каких угодно целях. На шаг ближе к цифровому концлагерю.
Тот же Гугл недавно на телефоне обновил приложение Google Authenticator, хранящее коды для 2FA. И теперь оно все эти коды сливает себе в облако. Зачем? А затем, что без этого у Гугла не было доступа к этим кодам, во всяком случае официально. А теперь есть. Официально. Нужно кому-то авторизоваться под кем-то чтобы что-то узнать - пожалуйста, вот 2FA код, а вот тут биометрический идентификатор. Пользуйтесь, на здоровье.
На техническом собесе такая задача не даст понять о человеке как специалисте абсолютно ничего. Кроме того, подобные калькуляторы нас в универе на паре по информатике учили писать и то лишь с целью понимания как происходит взаимодействие между числами. И выстраивали не только простейшие решения, а ещё и от пользователя просили нажать кнопку что он хочет сделать - сложить, вычесть, умножить или удалить, и, в соответствии с выбранными действиями, выполнить их. Самый обычный калькулятор ¯\_(ツ)_/¯
Статья больше рассчитана на разработчиков, для которых технический язык - родной. Мы же на Хабре, в конце концов. И первое предложение взято из Википедии и чуть упрощено. Оригинал выглядит следующим образом:
Алгоритм Лу́на (англ. Luhn algorithm) — алгоритм вычисления контрольной цифры номера пластиковой карты в соответствии со стандартом ISO/IEC 7812. Не является криптографическим средством, а предназначен в первую очередь для выявления ошибок, вызванных непреднамеренным искажением данных (например, при ручном вводе номера карты, при приёме данных о номере социального страхования по телефону). Позволяет лишь с некоторой степенью достоверности судить об отсутствии ошибок в блоке цифр, но не даёт возможности нахождения и исправления обнаруженной неточности.
Вдобавок, статья рассчитана не на объяснение истории появление алгоритма, а на его практическое использование с приведёнными примерами расчёта, а также описанием готового пакетного решения на языке PHP для упрощения генерации и валидации чисел.
К тому же, совсем необязательно при чтении поста знать о стандарте ISO/IEC 7812. Эта информация скорее не несёт особого смысла, а указано лишь в качестве связанности алгоритма Луна с ним. Для тех кому интересно что за стандарт, легко могут выделить строчку и загуглить его описание. А те, кому это не интересно, просто пропустят этот участок текста.
Так как алгоритм использует, по сути, простейшую математику, можно предположить что в любой системе счисления его будет возможно применить. Разница будет лишь во внешнем виде функции-обработчика.
Что касается текста, то в данном конкретном случае перед обработкой строка очищается от всех символов кроме чисел, а если нужно будет проверять именно буквенную строку, например, "foo-bar-baz", то я бы поступил следующим образом: получил бы для каждой буквы её порядковый номер в алфавите. Если номер больше 9, отнимаем 9 для получения единого числа. Для полученного числа рассчитываем контрольную цифру и на выходе будет готовая строка.
Например:
f o o b a r b a z
6 15 15 2 1 18 2 1 26
6 6 6 2 1 9 2 1 8 0 // добавляем для определения контрольной цифры
↓ ↓ ↓ ↓ ↓
12 6 12 2 2 9 4 1 16 0
↓ ↓ ↓
3 +6 +6 +2+2+9 +4+1+7 +0 = 40
Получаем контрольную цифру "0" так как полученная сумма делится на 10 без остатка. С учётом того, что цифра может быть от 0 до 9 включительно, в качестве "нуля" можно использовать 10-й символ алфавита - "j".
Таким образом, мы получим верную с точки зрения алгоритма Луна строку foo-bar-baz-j.
И самый лютый тип карты из всех - это Maestro - количество символов в её длине может быть от 12 до 19 включительно.
Не исключая криворукости тех, кто это придумал, такой выбор обусловлен, в том числе, наличием других платёжных систем, когда конечный номер карты должен быть уникальным среди всех банковских систем любой страны, по сути. Вот и придумывают изменение длины.
"алгоритм Луны" - не Луны, а Луна. Алгоритм разработал Ханс Лун.
У нас в проекте один чел так из редиски БД сделал. Причём не просто класть туда данные, а как кэш-репозиторий. То есть запрашиваем, например, массив данных из таблицы - в редиску пойдут все строки из этой таблицы, причём, в один ключ кэша один документ. При повторном запросе идём в кэш и поштучно получаем идентификаторы...
Но и отказ от многих современных методов, которые действительно позволяют значительно сократить время разработки, повысив читаемость кода, тоже плохо и зачастую переходит грань фанатизма. Типа "новое жрёт много памяти" (спойлер: экономия на спичках), или "да 512 метров памяти для пыха на проде это слишком много - 128 метров норм", или "да зачем юзать плагин для IDE с хоткеями и уем - можно же консольную команду написать", и т.д.
Фанатизм в разработке как палка о двух концах: с одной стороны как отказ от нового, так и много этого неоправданного "нового" способно "выстрелить в ногу", так сказать. Здесь действительно главное уметь держать грань разумного.
Прилетает одна задача "не работает сортировка. должна работать так", и тут же прилетает другая от другого человека тоже по сортировке, но условия иные.
Смотришь на две задачи и понимаешь, что визуально они дополняют друг друга, но когда приступаешь к корректировке кода, оказывается, что они друг другу очень сильно противоречат по условиям, и оба человека говорят что должно быть именно так, а продукт менеджер на их стороне.
При психических заболеваниях нейрочип будет стимулировать определенные участки мозга, которые связаны с регуляцией настроения
Или государство будет регулировать настроение общественности "программируя" таким образом людей на определённое поведение, а это будет 100%.
с его помощью можно будет общаться телепатически
Нет, с его помощью можно будет общаться с его помощью. Телепатия не предполагает использование каких-либо устройств в процессе передачи мыслей, образов и чувств другому мозгу или организму на расстоянии.
Нет, то что я очевидно далеко не популярная фигура и что смысла нет "ломать" мои устройство далеко не показатель того что аппараты не ломаются. Вон, сколько случаев было когда нюдсы голливудских звёзд сливали в сеть, ломая Apple Cloud, или как он там называется.
Так что кому надо, смогут взломать кого надо, а для тех кто эти ключи хранит, и вовсе ломать ничего не надо - взял ключ да используй.
Теория заговора теорией, но именно с этим мы и живём, и если закрыть глаза, проблема не исчезнет.
В случае банковских карт платёжные системы применяют формирование номеров карт в соответствии со стандартом ISO/IEC 7812. Это один из международных стандартов, описывающих параметры идентификационных карт и применение таких карт для международного, межотраслевого и/или внутриотраслевого взаимообмена.
Сам стандарт можно прочитать здесь. Он небольшой, всего 12 листов неполного текста.
Формирование номеров по стандарту следующее:
Всегда первые 6 цифр номера - это идентификационный номер эмитента, далее от 4 до 12 цифр - номер лицевого счёта. Последняя цифра - контрольная согласно алгоритму Луна.
Также в номерах банков первая цифра означает тип платёжной системы. Например, 4 - VISA, 5 - MasterCard, 2 - МИР. Но согласно ГОСТ ISO/IEC 7812-1—2014, первая цифра должна означать область деятельности:
авиалинии;
авиалинии и другие, возможные в будущем, области деятельности;
путешествия и развлечения и банковское дело/финансовые услуги;
банковское дело/финансовые услуги;
банковское дело/финансовые услуги;
торговля и банковское дело/финансовые услуги;
нефтяная промышленность и другие, возможные в будущем, области деятельности;
здравоохранение, телекоммуникации и другие, возможные в будущем, области деятельности;
для присвоения национальными органами по стандартизации.
На деле же получаем что банки как бы договариваются друг с другом - авиалинии у себя, а то и не договариваются вовсе, т.к. у каждого своя стойка регистрации и т.д.
Кроме этого, Вы можете заглянуть в эту папку репозитория и посмотреть какие регулярки применяются для определения принадлежности номера той или иной платёжной системе.
Так-то оно так, да вот кто скажет что он сливает данные себе? Тот же Google Authenticator взял и обновил приложение, а при запуске оно взяло и слило все секреты в облако гугла. Типа удобство, но платить за это приходится наличием секретов в облаке, где Гугл может их использовать как захочет и никто кроме них не узнает об этом. То же самое и с биометрией - введут в браузере и вуаля - что и куда оно сливает, кто ж знает.
Так что все эти договорённости и условные стандарты - это лишь голословные заявления, по сути. Как ни крути, а контролированием и программированием людей корпорации давно занимаются. Почитайте историю того же Сноудена или любого другого сотрудника крупной корпорации. Конечно, бывшего сотрудника. Нынешние мало чего расскажут, т.к. им контракт напрямую запрещает это делать.
Технологии это и хорошо, и плохо одновременно. И если бы это всегда было хорошо, то вряд ли бы тоннами блокировались сайты по всему миру и вводилась бы та же цензура. А получение ключей, в том числе биометрических идентификаторов, вопрос времени. И также не стоит забывать про трояны, актуальные до сих пор. Случайно или специально зашли не туда или качнули не то - софт на устройстве и тырит всё, до чего сможет дотянуться. Вот и всё.
Даже у Telegram защиту секретного чата давно сломали. Дуров ещё в начале обещал, не помню точно, 50к зелени, что ли, тому кто прочтёт переписку из его секретного чата с братом. Один хакер смог даже получить тело сообщения, но расшифровать не смог. А спустя время силовики смогли прочитать секретные чаты некоторых людей - забирают телефон и читают. А подобные passkeys сервисы позволят им облегчить эту задачу - достаточно будет через суд обязать сервис выдать ключи биометрии и всё, вот она переписка в прямом эфире, так сказать. И никто не спалит, потому что читающий - владелец этого хэша. И не важно кто им воспользуется и для каких целей.
В этом случае как раз не важно - они получат код активации только по своему секрету, который в аутентификатор добавляется. А вот Гугл получит доступ ко всем сервисам, добавленным в это приложение. Также как и все, кто имеет власть над Гуглом.
С того, что хэш отпечатка пальца и является тем самым биометрическим идентификатором. Когда входим в телефон или ещё куда, камера снимает отпечаток хоть с пальца, хоть с лица, затем из полученной информации вычисляется хэш. Когда есть готовый хэш идентификатор, процесс его расчёта можно пропустить - берём значение и вперёд.
Работал с системой отпечатков пальцев. У нас в офисе в начале рабочего дня и в конце сотрудники должны были палец прикладывать к датчику. Так руководство следило кто во сколько пришёл и ушёл. При этом, можно было легко из базы взять идентификатор (для разработчиков, имеющих доступ к базе, конечно) и выполнить запрос к серверу, подписав его этим хэшем. Тот отпечаток был где-то 512 символов длиной. Точно не считал. Так что это очень легко.
И у Гугла будет часть биометрических данных, которые они смогут использовать где угодно, когда угодно и в каких угодно целях. На шаг ближе к цифровому концлагерю.
Тот же Гугл недавно на телефоне обновил приложение Google Authenticator, хранящее коды для 2FA. И теперь оно все эти коды сливает себе в облако. Зачем? А затем, что без этого у Гугла не было доступа к этим кодам, во всяком случае официально. А теперь есть. Официально. Нужно кому-то авторизоваться под кем-то чтобы что-то узнать - пожалуйста, вот 2FA код, а вот тут биометрический идентификатор. Пользуйтесь, на здоровье.
На техническом собесе такая задача не даст понять о человеке как специалисте абсолютно ничего. Кроме того, подобные калькуляторы нас в универе на паре по информатике учили писать и то лишь с целью понимания как происходит взаимодействие между числами. И выстраивали не только простейшие решения, а ещё и от пользователя просили нажать кнопку что он хочет сделать - сложить, вычесть, умножить или удалить, и, в соответствии с выбранными действиями, выполнить их. Самый обычный калькулятор ¯\_(ツ)_/¯
Как скажете.
Статья больше рассчитана на разработчиков, для которых технический язык - родной. Мы же на Хабре, в конце концов. И первое предложение взято из Википедии и чуть упрощено. Оригинал выглядит следующим образом:
https://ru.wikipedia.org/wiki/Алгоритм_Луна
Вдобавок, статья рассчитана не на объяснение истории появление алгоритма, а на его практическое использование с приведёнными примерами расчёта, а также описанием готового пакетного решения на языке PHP для упрощения генерации и валидации чисел.
К тому же, совсем необязательно при чтении поста знать о стандарте ISO/IEC 7812. Эта информация скорее не несёт особого смысла, а указано лишь в качестве связанности алгоритма Луна с ним. Для тех кому интересно что за стандарт, легко могут выделить строчку и загуглить его описание. А те, кому это не интересно, просто пропустят этот участок текста.
Так как алгоритм использует, по сути, простейшую математику, можно предположить что в любой системе счисления его будет возможно применить. Разница будет лишь во внешнем виде функции-обработчика.
Что касается текста, то в данном конкретном случае перед обработкой строка очищается от всех символов кроме чисел, а если нужно будет проверять именно буквенную строку, например, "foo-bar-baz", то я бы поступил следующим образом: получил бы для каждой буквы её порядковый номер в алфавите. Если номер больше 9, отнимаем 9 для получения единого числа. Для полученного числа рассчитываем контрольную цифру и на выходе будет готовая строка.
Например:
Получаем контрольную цифру "0" так как полученная сумма делится на 10 без остатка. С учётом того, что цифра может быть от 0 до 9 включительно, в качестве "нуля" можно использовать 10-й символ алфавита - "j".
Таким образом, мы получим верную с точки зрения алгоритма Луна строку
foo-bar-baz-j.Можно, но это больше действий.
Например:
Или:
Одновременно нет. Сам алгоритм рассчитывает все цифры, а предложенный пакет отдельно проверяет длину строки: https://github.com/TheDragonCode/card-number/blob/main/src/Cards/Card.php#L20-L32
В ходе работы над проектом выяснил, что:
AmericanExpress имеет длину в 15 или 16 символов
HiperCard - 13, 16 или 19 символов
JCB и UnionPay - от 16 до 19
VISA - 13 или 16
VISA Electron - 16 или 17
И самый лютый тип карты из всех - это Maestro - количество символов в её длине может быть от 12 до 19 включительно.
Не исключая криворукости тех, кто это придумал, такой выбор обусловлен, в том числе, наличием других платёжных систем, когда конечный номер карты должен быть уникальным среди всех банковских систем любой страны, по сути. Вот и придумывают изменение длины.
"алгоритм Луны" - не Луны, а Луна. Алгоритм разработал Ханс Лун.
Было рассмотрено несколько вариантов этого предложения и каждый раз оно воспринималось двояко. Ваше выглядит лучше. Обновил статью, спасибо!
К сожалению, да. Но для личного роста очень даже помогает.
У нас в проекте один чел так из редиски БД сделал. Причём не просто класть туда данные, а как кэш-репозиторий. То есть запрашиваем, например, массив данных из таблицы - в редиску пойдут все строки из этой таблицы, причём, в один ключ кэша один документ. При повторном запросе идём в кэш и поштучно получаем идентификаторы...
Но и отказ от многих современных методов, которые действительно позволяют значительно сократить время разработки, повысив читаемость кода, тоже плохо и зачастую переходит грань фанатизма. Типа "новое жрёт много памяти" (спойлер: экономия на спичках), или "да 512 метров памяти для пыха на проде это слишком много - 128 метров норм", или "да зачем юзать плагин для IDE с хоткеями и уем - можно же консольную команду написать", и т.д.
Фанатизм в разработке как палка о двух концах: с одной стороны как отказ от нового, так и много этого неоправданного "нового" способно "выстрелить в ногу", так сказать. Здесь действительно главное уметь держать грань разумного.
В сфере разработки огромное количество паттернов и принципов, но предпочитаю руководствоваться всего одним:
Прилетает одна задача "не работает сортировка. должна работать так", и тут же прилетает другая от другого человека тоже по сортировке, но условия иные.
Смотришь на две задачи и понимаешь, что визуально они дополняют друг друга, но когда приступаешь к корректировке кода, оказывается, что они друг другу очень сильно противоречат по условиям, и оба человека говорят что должно быть именно так, а продукт менеджер на их стороне.
Или государство будет регулировать настроение общественности "программируя" таким образом людей на определённое поведение, а это будет 100%.
Нет, с его помощью можно будет общаться с его помощью. Телепатия не предполагает использование каких-либо устройств в процессе передачи мыслей, образов и чувств другому мозгу или организму на расстоянии.
Кто возьмёт прибор «Мысль» — обретает в жизни смысль!