CVV2 (англ. card verification value 2) — трёхзначный код проверки подлинности карты платёжной системы Visa. Другие платёжные системы имеют схожие технологии, к примеру аналогичный защитный код для карт MasterCard носит название card validation code 2 (CVC2), защитный код для платежной системы НСПК МИР получил название card verification parameter 2 (CVP2). Наносится на полосе для подписи держателя после номера карты либо после последних 4 цифр номера карты способом индент-печати.
Цифра 2 в названии кода вызвана тем, что есть и «первый» защитный код, используемый для верификации в транзакциях с физическим использованием карты. CVV/CVC-код записывается на магнитную полосу.
Если говорить про отпечатки пальцев, то цена подобного считывателя российского производителя — примерно два-три десятка тысяч рублей (то, что я нашёл сейчас в сети). Несколько дороже, чем считыватель карт. Но на самом деле, ограничения обычно в другом. Во-первых, не уверен, что биометрия допускается как единственный фактор (точно не знаю). Во-вторых (реальная техническая проблема) — поиск по базе отпечатков намного более трудоёмкий, чем поиск по номеру карты. Каждое считывание пальца (или руки) даёт уникальную свёртку, которую надо сопоставить с образцами. Причём не по точному совпадению, а по некоторому порогу «близости». И такие алгоритмы — это совсем не O(logN).
Если пропусков в системе 100 — всё быстро. А если десять тысяч, то реальное время просто не достижимо даже на мощных контроллерах. А если ставить по мощному серверу на каждую дверь, то такой СКУД становится просто золотым.
Поэтому, биометрия всегда является вторым фактором к карте или пинкоду (по крайней мере, из нашей практики). Сначала считываем первый фактор, а потом уже просто «сверяем» отпечаток с данными в пропуске 1-к-1.
p.s.: ну и заводить биометрические пропуска — это не пластиковые карточки по паспорту выдавать. Обычно биометрию используют на объектах повышенного уровня ответственности, типа объектов транспортной безопасности (аэропорты и пр.).
Кстати, отличная идея!
Если предположить использование такой схемы в каком-нибудь рабочем офисе, то главное тогда привязать ключ к конкретному телефону (например, к фиксированному серийнику или типа того), чтобы нельзя было его легко скопировать. Дело даже не в безопасности, а в том, что СКУД часто используется для учёта рабочего времени. И возможность копирования тогда позволяет «попросить Васю отметиться за меня». Хотя «авторизация по смартфону» и такой «обман», наверное, плохо коррелируют.
Каждой задаче — своё решение. Забивать гвозди микроскопом можно. Но для этого есть молоток. Так и тут — для простого объекта, риски проникновения на который не так высоки, подойдёт уровень «массовых дешёвых СКУД». Для аэропорта или атомной станции — нет. И в данном случае задача стоит на уровне «массового дешёвого СКУД». А предложенное решение даёт преимущество: не надо заводить отдельную пластиковую карту (как в остальных «дешёвых СКУД»).
Согласен. Безопасность — это всегда поиск грани между ценностью защищаемого объекта и стоимостью взлома. Кстати, с определённого момента всё вообще упирается в человеческий фактор. И с обычными mifare картами проще отобрать эту карту у сотрудника в тёмной подворотне. Об этом хорошо писал Брюс Шнайер в книге «Секреты и ложь. Безопасность данных в цифровом мире». Как-то так:
В 1994 году французский хакер по имени Антоний Зборальски позвонил в вашингтонский офис ФБР и представился представителем этой организации, работающим в американском посольстве в Париже. Он убедил собеседника на другом конце провода, и тот объяснил ему, как подключиться к системе телеконференции ФБР. Его звонки за последующие семь месяцев стоили ФБР 250 000 долларов.
Когда в 2000 году Кевин Митник (наверное, самый известный хакер в мире) давал показания в Конгрессе США, он говорил о манипулировании людьми: «Нападения этого рода были столь успешны, что мне редко приходилось обращаться к техническим средствам. Компании способны истратить миллионы долларов на технические средства защиты, но все это будет напрасно, если можно позвонить по телефону и убедить кого-нибудь сделать на компьютере нечто, что ослабляет защиту или открывает доступ к интересующей информации».
На объектах, где контроллеров более одного — каждый контроллер хранит копию базы данных. И они синхронизируют все изменения между собой в реальном времени. А потому, если какой-то контроллер (или его карта) и выйдет из строя, можно восстановить базу с другого контроллера в сети. В реальности, конечно, кроме контроллеров есть ещё и «серверные» узлы, где хранятся данные.
С контроллера БОРЕЙ можно выгрузить базу данных пропусков, владельцев и пр. в виде бинарного файла. В случае данного объекта, где предполагаю, пропуска выдаются не так часто, наверное, проще всего периодически выгружать базу (например, за раз в неделю) через HTTP API и сохранять её в облако.
Вообще, наши потребители почти не сталкиваются с выходом SD-карт из строя. Мы контролируем нагрузку на SD-карту и используем Industrial SD карты со SMARTом — можно следить за износом карты. Чаще карты воруют монтажники просто пропадают на этапе пусконаладки объекта :D
В целом, согласен с тем, что использование платежных инструментов для доступа — антипаттерн. Но если это решение, с которым согласны обе стороны (владелец объекта и посетитель) — то почему бы и нет. Если же это объект, доступ куда может получить посетитель «со стороны» (например, через процедуру оформления разового пропуска в терминале самообслуживания), то склонять такого посетителя к использованию банковской карты — точно не вариант.
Вы затронули больную тему с кучей «бонусных» карт всех возможных магазинов. Видел, что некоторое распространение получили мобильные приложения, которые позволяют вносить штрихкоды с таких карт, после чего предъявлять их в магазинах с телефона. В принципе, можно решать задачу доступа аналогичным образом, подключая к контроллеру оптический считыватель штрихкодов, QR-кодов и пр. Вполне рабочее решение. Особенно для разового доступа. И можно не ждать появления «правильной» технологии.
Конечно, для постоянного доступа главное, чтобы код не «сфотографировал» злоумышленник с экрана телефона. Но если есть такой доступ к телефону, думаю, у владельца телефона будут другие проблемы. Впрочем, можно пофантазировать с тем, чтобы код выдавался на телефон по геолокации при входе сотрудника в офис или что-то подобное.
«Веб-интерфейс» не исключает возможности «централизованной» работы в системах безопасности. Если узлы системы знают друг про друга, «шарят» общую шину событий и общие данные, то неважно — с какого из узлов получать доступ к интерфейсу.
Естественно, есть класс задач, в которых необходимы desktop-приложения (сложное видео / аудио, 3d, и пр.). Тут у «HTML5» технологий ещё не всё отлично.
Вы правы в том, что чем проще информационная система — тем проще обеспечить её информационную безопасность.
Если говорить про физическую безопасность объекта, то никто не будет вашу защёлку «хакать» — злоумышленник просто перелезет через забор / разобъёт окно / приставит нож к горлу и заставит открыть ворота самостоятельно. Даже в современных «шпионских» фильмах (кроме откровенно пародийных) никто ничего не «хакает». Человеческий и другие факторы оказываются более «дешёвым» вариантом.
Если говорить про ботнет — у злоумышленника должен быть либо удалённый, либо физический доступ к средствам обеспечения безопасности. Выведите IP-средства безопасности и рабочие места в отдельную сеть / закрытый сегмент, ограничьте физический доступ и ботнет вам не страшен.
Подавляющее большинство СКУД на российском и мировом рынке работают в специализированных сетях (RS-485, RS-232, Modbus, Lonworks), что и создаёт иллюзию их защищённости. Действительно, нельзя просто так взять и подключиться к таким сетям с ноутбука. Но по факту — внутренние протоколы в таких сетях вообще почти не защищены. И «хакнуть» систему, врезавшись в сеть RS-485, гораздо проще, чем IP-систему. При наличии физического доступа. Если его нет — см. предыдущий абзац. Кстати, такие системы всё равно подключают к ПК, и тут уже ПК становится уязвимым звеном — вирусы, ботнеты и прочие радости жизни.
Фишка в том, что большая часть продукции на рынке создана десятки лет назад на очень древней элементной базе. На таких аппаратных ресурсах обеспечить защиту информации в принципе нормально невозможно — XOR, шифроблокноты, что-то очень простое. А современные IP-устройства уже гораздо более производительны (за те же деньги или меньше). И тут можно использовать все криптонаработки человечества. На каждом узле системы Nginx / HTTPS, только TLS / DTLS, обязательно клиентские и серверные сертификаты — и решение по безопасности не будет ничем отличаться от сайтов банков.
Таким образом, богатая функциональность современных IP-систем безопасности никак не связана с защищенностью таких систем.
Именно такие контроллеры наша компания и производит. Кстати, уже довольно давно. И производительности ARM в ~400 мегагерц (одноядерного), 64мб оперативной памяти вполне достаточно для того, чтобы контроллеры могли выполнять свои функции, обнаруживать другие такие контроллеры в сети, кооперироваться с ними, шарить и автоматически синхронизировать единую базу данных пропусков (объёмом до 100000шт) и пр., поддерживать JSON API и SOAP API (Onvif), а также предоставлять «облачный» веб-интерфейс для настройки и управления получившейся системой СКУД и охранной сигнализации. И всё это будет работать без выделенного сервера на ПК. (Естественно, в новых решениях производительность «железа» ещё выше)
По Lock-Free (и далее Wait-Free) синхронизации могу порекомендовать книгу Concurrent and Distributed Computing in Java (Vijay K. Garg), в частности, главу 5 — Wait-Free Synchronization. Несмотря на наличие Java в названии, книга в основном посвящена теории, алгоритмам и их анализу.
Эта книга была настольной при подготовке к экзамену по параллельному программированию. Не уверен, есть ли более полезная книга по обозначенной теме.
Поправьте меня, если я ошибаюсь, но в соответствии с первоисточником причин создания шрифта две:
Первая
Используя данный шрифт как временную «линейку», на уровне системы или приложения можно запретить подменять желаемый шрифт до полного его рендеринга системным;
Вторая
Исходя из предыдущей реализации, используя Adobe Blank можно определить когда Webfont действительно загружен, что по своему роду является хаком ограничений в CSS.
А вот это:
Включение Adobe Blank как data URI в CSS файле.
Декларация font-family: SomeWebFont, “Adobe Blank”; для некоторых DOM элементов, которые содержат текст и не должны иметь нулевую ширину. Например который позиционирован абсолютно, за пределами экрана.
Проверить ширину DOM элемента: если он равен 0 — SomeWebFont еще не загружен, если больше — загружен.
есть способ реализации для «второй причины».
Ибо как написано в первоисточнике — «About the second purpose, the actual usage is as follows». И далее перечислены три шага (а не два) — включение как data URI в CSS, декларация в font-family, проверка ширины DOM.
Не вижу смысла писать в личку, так как ошибка на 2/3 текста новости.
Действительно, по моим наблюдениям многие разработчики обходят JavaScript стороной. Я вижу несколько причин. Во-первых, для многих смена парадигмы после языков вроде C++ или Java дается нелегко. Во-вторых, JavaScript настолько простой и в то же время гибкий, что для написания серьезных приложений на нем надо быть хорошим разработчиком — уметь проектировать, понимать теорию (замыкания, прототипы и пр.), выбирать парадигму разработки в зависимости от задач. Язык здесь не поможет, не накладывает ограничений. (Грубо говоря, это как уметь писать код без отладчика) Наконец, в головах многих разработчиков не на «передовой» технологий JavaScript — это что-то несерьезное, что-то «для веб-формочек».
А жаль, потому как JavaScript потрясающе развивает голову, заставляет мыслить на другом уровне. Да и спрос есть, а кадров мало. Смотрите сколько вакансий. А настоящего JS-ниндзя не найти, проверено на опыте в последние две недели.
TypeScript — очень интересная штука судя по обзорам. Но надо пробовать его на серьезных проектах, а не на небольших примерах. Будет ли там такой же красивый JS-код на выходе? Лично для меня большой минус — привязка к платформе. Как только появятся кроссплатформенные инструменты и плагины для того же Eclipse, можно будет пробовать в рабочем процессе. Или, может быть, уже что-то есть?
Планировал опубликовать статью 7го вечером. Если бы сделал это раньше, то девушки на работе в теории могли ее прочитать — это бы испортило весь сюрприз. Но после публикации в песочницу статья ожидала модерации все выходные. Поэтому она появилась на сайте только сегодня.
Таким образом, CVV или CVC — зависит от платёжной системы.
Если пропусков в системе 100 — всё быстро. А если десять тысяч, то реальное время просто не достижимо даже на мощных контроллерах. А если ставить по мощному серверу на каждую дверь, то такой СКУД становится просто золотым.
Поэтому, биометрия всегда является вторым фактором к карте или пинкоду (по крайней мере, из нашей практики). Сначала считываем первый фактор, а потом уже просто «сверяем» отпечаток с данными в пропуске 1-к-1.
p.s.: ну и заводить биометрические пропуска — это не пластиковые карточки по паспорту выдавать. Обычно биометрию используют на объектах повышенного уровня ответственности, типа объектов транспортной безопасности (аэропорты и пр.).
Если предположить использование такой схемы в каком-нибудь рабочем офисе, то главное тогда привязать ключ к конкретному телефону (например, к фиксированному серийнику или типа того), чтобы нельзя было его легко скопировать. Дело даже не в безопасности, а в том, что СКУД часто используется для учёта рабочего времени. И возможность копирования тогда позволяет «попросить Васю отметиться за меня». Хотя «авторизация по смартфону» и такой «обман», наверное, плохо коррелируют.
С контроллера БОРЕЙ можно выгрузить базу данных пропусков, владельцев и пр. в виде бинарного файла. В случае данного объекта, где предполагаю, пропуска выдаются не так часто, наверное, проще всего периодически выгружать базу (например, за раз в неделю) через HTTP API и сохранять её в облако.
Вообще, наши потребители почти не сталкиваются с выходом SD-карт из строя. Мы контролируем нагрузку на SD-карту и используем Industrial SD карты со SMARTом — можно следить за износом карты. Чаще карты
воруют монтажникипросто пропадают на этапе пусконаладки объекта :DВы затронули больную тему с кучей «бонусных» карт всех возможных магазинов. Видел, что некоторое распространение получили мобильные приложения, которые позволяют вносить штрихкоды с таких карт, после чего предъявлять их в магазинах с телефона. В принципе, можно решать задачу доступа аналогичным образом, подключая к контроллеру оптический считыватель штрихкодов, QR-кодов и пр. Вполне рабочее решение. Особенно для разового доступа. И можно не ждать появления «правильной» технологии.
Конечно, для постоянного доступа главное, чтобы код не «сфотографировал» злоумышленник с экрана телефона. Но если есть такой доступ к телефону, думаю, у владельца телефона будут другие проблемы. Впрочем, можно пофантазировать с тем, чтобы код выдавался на телефон по геолокации при входе сотрудника в офис или что-то подобное.
Естественно, есть класс задач, в которых необходимы desktop-приложения (сложное видео / аудио, 3d, и пр.). Тут у «HTML5» технологий ещё не всё отлично.
Если говорить про физическую безопасность объекта, то никто не будет вашу защёлку «хакать» — злоумышленник просто перелезет через забор / разобъёт окно / приставит нож к горлу и заставит открыть ворота самостоятельно. Даже в современных «шпионских» фильмах (кроме откровенно пародийных) никто ничего не «хакает». Человеческий и другие факторы оказываются более «дешёвым» вариантом.
Если говорить про ботнет — у злоумышленника должен быть либо удалённый, либо физический доступ к средствам обеспечения безопасности. Выведите IP-средства безопасности и рабочие места в отдельную сеть / закрытый сегмент, ограничьте физический доступ и ботнет вам не страшен.
Подавляющее большинство СКУД на российском и мировом рынке работают в специализированных сетях (RS-485, RS-232, Modbus, Lonworks), что и создаёт иллюзию их защищённости. Действительно, нельзя просто так взять и подключиться к таким сетям с ноутбука. Но по факту — внутренние протоколы в таких сетях вообще почти не защищены. И «хакнуть» систему, врезавшись в сеть RS-485, гораздо проще, чем IP-систему. При наличии физического доступа. Если его нет — см. предыдущий абзац. Кстати, такие системы всё равно подключают к ПК, и тут уже ПК становится уязвимым звеном — вирусы, ботнеты и прочие радости жизни.
Фишка в том, что большая часть продукции на рынке создана десятки лет назад на очень древней элементной базе. На таких аппаратных ресурсах обеспечить защиту информации в принципе нормально невозможно — XOR, шифроблокноты, что-то очень простое. А современные IP-устройства уже гораздо более производительны (за те же деньги или меньше). И тут можно использовать все криптонаработки человечества. На каждом узле системы Nginx / HTTPS, только TLS / DTLS, обязательно клиентские и серверные сертификаты — и решение по безопасности не будет ничем отличаться от сайтов банков.
Таким образом, богатая функциональность современных IP-систем безопасности никак не связана с защищенностью таких систем.
Эта книга была настольной при подготовке к экзамену по параллельному программированию. Не уверен, есть ли более полезная книга по обозначенной теме.
Первая
Вторая
А вот это:
есть способ реализации для «второй причины».
Ибо как написано в первоисточнике — «About the second purpose, the actual usage is as follows». И далее перечислены три шага (а не два) — включение как data URI в CSS, декларация в font-family, проверка ширины DOM.
Не вижу смысла писать в личку, так как ошибка на 2/3 текста новости.
А жаль, потому как JavaScript потрясающе развивает голову, заставляет мыслить на другом уровне. Да и спрос есть, а кадров мало. Смотрите сколько вакансий. А настоящего JS-ниндзя не найти, проверено на опыте в последние две недели.
TypeScript — очень интересная штука судя по обзорам. Но надо пробовать его на серьезных проектах, а не на небольших примерах. Будет ли там такой же красивый JS-код на выходе? Лично для меня большой минус — привязка к платформе. Как только появятся кроссплатформенные инструменты и плагины для того же Eclipse, можно будет пробовать в рабочем процессе. Или, может быть, уже что-то есть?