All posts by Bozho

Как наистина да получим електронна идентификация

Post Syndicated from Bozho original https://blog.bozho.net/blog/3659

Национална схема за електронна идентификация още няма, по ред причини, както съм описал тук. Но в даден момент следващата или по-следващата година все ще стане – изпълнителят ще изгради нещо по заданието, ще достави и лични карти, те ще имат чип и на чипа ще се записва удостоверение за електронна идентичност.

Само че когато това стане, няма автоматично да имаме лесно и удобно средство за електронна идентификация и електронното управление да тръгне по мед и масло. Това е едно от трудните неща в електронното управление – че като пуснеш поръчката, след две години не режеш лента, а хората не могат да видят ползите веднага. А в допълнение, някои грешки в изпълнението могат да значат пълен провал, а не просто нужда от закърпване.

Затова тези дни се замислих и реших да обобщя нещата, с които трябва да се внимава при изпълнението, за да не получим накрая едни безполезни пластики и всичко да трябва да започне отначало. Да, има детайлно техническо задание, но проблемите по-долу не са функция само на техническата реализация.

Четенето на личната карта – чипът трябва да може да бъде прочетен, иначе картата е безполезна. Би трябвало чиповете да позволяват контактен и безконтактен достъп – контактен, за използване на всички налични четци на електронни подписи тип „карта“ (които мисля са все по-малко), и безконтактен. Контактното четене е доста неудобно (макар в Естония да е било успешно благодарение на добра кампания за разпространяване на четци, сега сме в друга технологична „ера“) и поради това трябва да се обърне внимание на безконтактното като най-масовия начин за използване на картата. В Правилника за прилагане на Закона за електронната идентификация бяхме включили текстове, които да предвиждат идентификация чрез безконтактно четене на телефон, докато потребителят заявява услуга на компютър (или на телефона, разбира се).

Трябва изпълнителят да реализира този процес удобно, със стандартни приложения за различните мобилни операционни системи, така че процесът да бъде: 1. натискане на бутон „идентифицирай се“ при заявяване на услуга 2. Излизане на съобщение на телефона за очаквана идентификация 3. допиране на картата и написване на PIN (може и в обратен ред, за по-голямо удобство) 4. Успешна идентификация. Трябва да се обърне внимание и на сигурността на безконтакното четене. Към 2016 стандартите по темата не бяха масово възприети, така че изпълнителят и възложителят трябва да преценят кой е най-актуалният начин.

Персонализиране на други носители – електронната идентификация не е само „чип в личната карта“. Всъщност чипът в личната карта е само една от много възможности. Трябва в рамките на издаването на удостоверение за електронна идентичност да се даде опция за записването му (заедно с частния ключ) на смартфон или на друга карта. Записването на частен ключ на телефон към 2016 г. не беше сигурно (имаше известни атаки), но 4 години по-късно вече е. И в нормативната уредба, и в заданието е заложена възможност за издаване на eID чрез вече съществуващо eID. Т.е. може с еднократно използване на личната карта да се създаде нов частен ключ и удостоверение на телефона и всяка следваща идентификация да не изисква докосване на картата и писане на PIN (а използване на сензора за пръстов отпечатък). Тези опции са заложени и напълно възможни, но трябва и възложителят, и изпълнителят да съблюдават те да се случат по този начин.

Електронно подписване – между електронна идентификация и електронен подпис има съществена разлика (едното е „да си покажеш личната карта“, другото е „да се подпишеш“). Много услуги изискват подпис за заявяване (или за попълване на някоя декларация), което би направило електронната идентификация почти безполезна, с изключение на някои справочни услуги. Именно затова е ключов чл. 22, ал. 5 от Закона за електронното управление, изрично позволяващ заявяването на услуги от физически лица да се допустимо с неквалифициран електронен подпис (а с усъвършенстван). На практика това значи, че всяка съществуваща и бъдеща услуга трябва да може да бъде подписвана със същите криптографски ключове (или производни на тях), използвани за електронната идентификация.

Това би представлявало усъвършенстван електронен подпис и няма да се налага освен личната карта да имате и квалифициран електронен подпис (още повече, че преди 2 години законодателят махна опцията личните карти да поддържат електронни подписи, не е много ясно защо, освен може би заради техническите изисквания към чиповете). Европейската Комисия изрично посочва, че държавите членки определят с какъв вид подпис могат да се ползват административни услуги, та ние се възползвахме от тази опция. Има и още една опция, но тя е по-трудна – да се променят всички закони, наредби, правилници, заповеди и вътрешни правила и навсякъде да се посочи, че не се изисква подпис за електронно заявяване. Но това е непрактично и крие рискове.

Дори картата (и приложението на смартфона) да могат да слагат криптографски подпис, това няма да е достатъчно. Съществуващи услуги, използващи различни средства за подписване, ще трябва да бъдат интегрирани. Може да се наложи дори разработване на специален драйвер, който настоящите аплети и приложения за подписване да заредят, за да бъде опакован криптографския подпис от смарткартата в електронен подпис по смисъла на законодателството. Тези процеси трябва да бъдат разписани и изтествани.

Интеграция на системи – в рамките на проекта трябва да бъдат изготвени компоненти за лесна интеграция на системи. Никоя система няма по подразбиране да поддържа електронната идентификация и трябва бързо да могат да се надградят. Т.нар. SDK, примерен код на различни езици и стандартни приложения за различни операционни системи (десктоп и мобилни) са част от техническото задание, но на тях трябва да бъде обърнато особено внимание – в противен случай ще имаме в джоба си нещо, което не можем да използваме никъде.

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

Не на последно място, трябва да бъде реализирана идентификация на юридически лица чрез връзка в реално време с Търговския регистър (и РЮЛНЦ, и Булстат), за да се избегнат проблемите, които произтичат от настоящото решение с КЕП. Това предполага надграждане на системи и понякога промяна на процеси.

Цялостна архитектура на федерираната идентификация – националната схема за електронна идентификация е само една от няколко опции. Вече има частни схеми за идентификация, отдавна има всевъзможни ПИК-ове, които макар и от ниско ниво, минават за идентификация по Регламент 910/2014. Има и необходимост да се поддържат електронните идентификации на всички държави членки. Трябва максимално бързо да бъде разписана архитектура на федерирана идентификация, която да позволява на гражданите да ползват всяка услуга с подходящо за целта средство. Първо, с надграждането на административния регистър (което също трябваше да е станало отдавна) трябва да се добавят нивата на осигуреност на идентификацията, която дадена услуга изисква. След това трябва да има т.нар. eIDAS възел, който да позволява интеграция с европейските схеми.

Трябва да бъде подготвена архитектура и на местно ниво – как частни схеми и/или частни центрове за електронна идентификация да си общуват с националната схема. Къде в картинката стои и настоящата система за е-автентикация на ДАЕУ, която от временно решение се превръща във все по-устойчиво такова. За щастие всички тези системи „говорят“ (и трябва да говорят според нормативните изисквания) на един „език“ – протоколът SAML 2.0. Но кой кого извиква, с какви параметри, кой какви регистри държи и какво позволява; как се извършва подписване при схеми, които не са националната (напр. чрез съхраняване на SAML 2.0 assertions) и не на последно място – как да бъде осъвременена нормативната уредба с всичко това. Сложни въпроси, които трябва да намерят отговор в следващите 6 месеца, за да не се окажем в батак, в който всичко е толкова фрагментирано, че много малко хора да могат да ползват услугите, които искат със средството за идентификация, което имат.

Може би стана прекалено техническо, но дяволът е в детайлите. Ако объркаме някой от тези детайли, рискуваме да продължим да трупаме изоставане в електронното управление, а закъснялата електронна идентификация да не донесе позитивните резултати, с каквито очаквания е натоварена.

Материалът Как наистина да получим електронна идентификация е публикуван за пръв път на БЛОГодаря.

Creating a CentOS Startup Screen

Post Syndicated from Bozho original https://techblog.bozho.net/creating-a-centos-startup-screen/

When distributing bundled software, you have multiple options, but if we exclude fancy newcomers like Docker and Kubernetes, you’re left with the following options: an installer (for Windows), a package (rpm or deb) for the corresponding distro, tarball with a setup shell script that creates the necessary configurations, and a virtual machine (or virtual appliance).

All of these options are applicable in different scenarios, but distributing a ready-to-deploy virtual machine image is considered standard for enterprise software. Your machine has all the dependencies it needs (because it might not be permitted to connect to the interenet), and it just has to be fired up.

But typically you’d want some initial configuration or at least have the ability to show the users how to connect to your (typically web-based) application. And so creating a startup screen is what many companies choose to do. Below is a simple way to do that on CentOS, which is my distro of preference. (There are other resources on the topic, e.g. this one, but it relies on /etc/inittab which is deprecated in CentOS 8).

useradd startup -m
yum -y install dialog

sed -i -- "s/-o '-p -- \\u' --noclear/--autologin startup --noclear/g" /usr/lib/systemd/system/[email protected]

chmod +x /install/startup.sh
echo "exec /install/startup.sh" >> /home/startup/.bashrc

systemctl daemon-reload

With the code above you are creating a startup user and auto-logging that user in before the regular login prompt. Replacing the Exec like in the [email protected] is doing exactly that.

Then the script adds the invocation of a startup bash script to the .bashrc which gets run when the user is logged in. What this script does is entirely up to you, below is a simple demo using the dialog command (that we just installed above):

#!/bin/sh
# Based on https://askubuntu.com/questions/1705/how-can-i-create-a-select-menu-in-a-shell-script

HEIGHT=15
WIDTH=70
CHOICE_HEIGHT=4
BACKTITLE="Your Company"
TITLE="Your Product setp"
BIND_IP=`ifconfig | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p'`
INFO="Welcome to MyProduct.\n\n\nWeb access URL: https://$BIND_IP\n\n\n\nFor more information visit https://docs.example.com"

CHOICE=$(dialog --clear \
                --backtitle "$BACKTITLE" \
                --title "$TITLE" \
                --msgbox "$INFO" \
                $HEIGHT $WIDTH \
                2>&1 >/dev/tty)

clear
echo 'Enter password for user "root":'
su root

This dialog shows just some basic information, but you can extend it to allow users making choices and input some parameters. More importantly, it gets the current IP address and shows it to the user. That’s not something they can’t do themselves in other ways, but it’s friendlier to show it like that. And you can’t hard-code that, because in each installation it will have a different IP (even if not using DHCP, you should let the user set the static IP that they’ve assigned rather than forcing one on them). At the end of the script it switches to the root user.

Security has to be considered here – your startup user should not be allowed to do anything meaningful in the system, because it is automatically logged in without password. According to this answer exec sort-of solves that problem (e.g. when you mistype the root password, you are back to the startup.sh script rather than to the console).

I agree that’s a rare use-case but I thought I’d share this “arcane” knowledge.

The post Creating a CentOS Startup Screen appeared first on Bozho's tech blog.

Let’s Kill Security Questions

Post Syndicated from Bozho original https://techblog.bozho.net/lets-kill-security-questions/

Let’s kill security questions

Security questions still exist. They are less dominant now, but we haven’t yet condemned them as an industry hard enough so that they stop being added to authentication flows.

But they are bad. They are like passwords, but more easily guessable, because you have a password hint. And while there are opinions that they might be okay in certain scenarios, they have so many pitfalls that in practice we should just not consider them an option.

What are those pitfalls? Social engineering. Almost any security question’s answer is guessable by doing research on the target person online. We share more about our lives and don’t even realize how that affects us security-wise. Many security questions have a limited set of possible answers that can be enumerated with a brute force attack (e.g. what are the most common pet names; what are the most common last names in a given country for a given period of time, in order to guess someone’s mother’s maiden name; what are the high schools in the area where the person lives, and so on). So when someone wants to takeover your account, if all they have to do is open your Facebook profile or try 20-30 options, you have no protection.

But what are they for in the first place? Account recovery. You have forgotten your password and the system asks you some details about you to allow you to reset your password. We already have largely solved the problem of account recovery – send a reset password link to the email of the user. If the system itself is an email service, or in a couple of other scenarios, you can use a phone number, where a one-time password is sent for recovery purposes (or a secondary email, for email providers).

So we have the account recovery problem largely solved, why are security questions still around? Inertia, I guess. And the five monkeys experiment. There is no good reason to have a security question if you can have recovery email or phone. And you can safely consider that to be true (ok, maybe there are edge cases).

There are certain types of account recovery measures that resemble security questions and can be implemented as an additional layer, on top of a phone or email recovery. For more important services (e.g. your Facebook account or your main email), it may not be safe to consider just owning the phone or just having access to the associated email to be enough. Phones get stolen, emails get “broken into”. That’s why a security-like set of questions may serve as additional protection. For example – guessing recent activity. Facebook does that sometimes by asking you about your activity on the site or about your friends. This is not perfect, as it can be monitored by the malicious actor, but is an option. For your email, you can be asked what are the most recent emails that you’ve sent, and be presented with options to choose from, with some made up examples. These things are hard to implement because of geographic and language differences, but “guess your recent activity among these choices”, e.g. dynamically defined security questions, may be an acceptable additional step for account recovery.

But fixed security questions – no. Let’s kill those. I’m not the first to argue against security questions, but we need to be reminded that certain bad security practices should be left in the past.

Authentication is changing. We are desperately trying to get rid of the password itself (and still failing to do so), but before we manage to do so, we should first get rid of the “bad password in disguise”, the security question.

The post Let’s Kill Security Questions appeared first on Bozho's tech blog.

Дигитализацията на публичния сектор с европейски средства става все по-труднa

Post Syndicated from Bozho original https://blog.bozho.net/blog/3653

В рамките на националния план за възстановяване и устойчивост дигитализацията на публичния сектор е слабо и откъслечно застъпена. Коментирахме темата с Христо Иванов, Иво Мирчев и Боян Юруков миналата седмица, но ми се ще да развия темата.

Първо, защо трябва дигитализацията на публичния сектор да бъде приоритетна инвестиция – защото тя е отключващ фактор. Намалява административната тежест, съответно прави бизнес климата по-благоприятен, а инвестициите – по-вероятни. В същото време намалява риска от корупция и увеличава прозрачността в управлението. Прави публичните системи по-ефективни, така че по-малко средства да „изтичат“. Всяка една система би спестила много пари и време и би повишила качеството си, ако процесите и услугите ѝ са дигитални. Това се превежда сравнително бързо, макар и индиректно, в по-добър живот.

Обаче има проблем ЕС да финансира електронното управление (което не е синоним на „дигитализация на публичния сектор“, но е близо). И проблемът е, че е малко вероятно ЕС да финансира отново нещата, които е финансирал вече няколко пъти.

След присъединяването ни към ЕС, има два програмни периода. В първия (2007-2013) програмата за електронно управление е „Административен капацитет“, а във втория (2014-2020) – „Добро управление“. В рамките на тези оперативни програми са предвидени около милиард лева, като немалка част от тях са похарчени (макар реално усвоените по ОПДУ да са около 1/3 в последната година, в която може да се кандидатства за проекти, то остават три години за довършване на проекти и тяхното изплащане).

В рамките на тези два програмни периоди трябваше да сме направили много неща. Обаче не сме. Отчели сме ги проформа, или сме ги изградили системи, които не се използват, или са се използвали, но са изоставени. Или не сме направили неща, които сме обещали, че ще направим. И проблемът е в това, че ЕК няма основание да ни даде трети път пари за същото.

Но нека вляза в конкретика:

  • Електронизация на общински услуги – по ОПАК се изсипаха сума ти пари за това, а по ОПДУ трябваше да се развият и внедрят хоризонтални услуги в общините. И на места има услуги, които дори се ползват от време на време, но като цяло положението е зле.
  • Електронна идентификация – по ОПАК има пилотен проект, след това по ОПДУ се предвиден реален проект за национална схема. Той все още не е стартирал, но поне има шанс да стане до края на следващата година. Все още обаче електронна идентификация няма, камо ли пък услуги да са интегрирани с нея.
  • Регистрова реформа – електронизиране на регистри, отпадане на излишни регистри, използване на информационни системи и „свързване“ на регистри. По това има поне нещо направено, но твърде скъпо и твърде неефективно. На практика регистрите не предоставят интерфейси за машинна комуникация и много често са просто грозни интерфейси върху таблица в базата данни. Неслучайно има стратегически документ „Концепция за регистрова реформа“ за периода 2019-2023. Само че в двата програмни периода електронизацията на регистри трябваше да се е случила (да, реформата не е равно само на електронизация, но да не влизам в скучни подробности). Ключови регистри, като Национална база данни „Население“, например, трябваше да бъдат наградени или изградени наново, но не са.
  • Електронно здравеопазване – първото нещо, което ще видим след толкова години „мъки“ е след месец когато най-накрая надявам се да имаме електронна рецепта. Да, НЗОК има система, но и тя е доста ръчно-крачна и остаряла, а неща като „Единен здравен запис“ съществуват само в контекста на плащанията „по каса“, и дори там са непълни и некоректни. Малко цинично погледнато – „добре“ че дойде корона кризата, че МЗ поне малко да се задейства, макар и все още да предстои да видим резултат.
  • Електронно правосъдие – и в двата програмни периода има проекти и дори цяла ос за правосъдие. Системата за електронно правосъдие се въвежда тази година, с променлив успех, но все още не позволява реално електронно правосъдие – съдилища изискват подаване на заявления на хартия, за да можеш да ползваш системата, например.
  • Реинженеринг на процеси, функционални анализи и други анализи – такива „на килограм“ има, особено по ОПАК. Стоят по чекмеджета (или на нечий компютър в добрия случай). И остаряват по-бързо, отколкото някой може да се възползва от малкото полезна информация, която са открили.
  • Обучение на администрацията – администрацията трябва да може да управлява процеса по въвеждане на електронното управление. Нищо подобно не се случва (с малки изключения), и то е отчасти защото след два програмни периода администрацията все още не знае какво е електронно управление (пак, с изключения, разбира се).

Дори с нещата, които все пак са изградени, няма политика за поддръжка и устойчивост. До скоро нямаше отделен ИТ бюджет и след изтичането на гаранционната поддръжка нещата оставаха във въздуха. От няколко години (след измененията в ЗЕУ, в които участвах), в бюджетната процедура всяка година е включено и „перо“ за информационни технологии, така че администрацията да започне да мисли как да продължи да ползва системите си. Образно казано, Европа дава пари да си направим основен ремонт на апартамента, но не и дава пари за месечните сметки за ток, вода и телефон или за текущи ремонти и трябва да ги планираме от нашия бюджет.

Та от Европейския съюз сме взели вече пари за тези неща. По два пъти за повечето от тях. И затова е трудно те да влязат за трети път в документ, с който искаме пари от Европа. Защото там с право ще кажат „е стига толкова, де, нали вече го правихте това“.

Ако бяхме направили нещата дотук, щяхме да можем да поискаме пари за следващите стъпки. За отворени интерфейси и дори изграждане на частни услуги на база на публичната инфраструктура; за трансгранична електронна идентификация, така че граждани на целия ЕС да могат да ползват е-услуги у нас (и съответно български граждани в Европа); за проактивни услуги, като автоматично кандидатстване за детска градина, автоматично получаване на помощи при определени условия и др; за групиране на услуги като епизоди от живота и събития от бизнеса, така че „отваряне на магазин“ да бъде една услуга за бизнеса, а не десет, с различни институции, например (за това има пари по „Добро управление“, между другото, но мисля, че нещата са на нулата); за неща като естонското електронно гражданство, с което да привличаме чужди инвестиции; за провеждане на политики, базирани на данни и дори използване на изкуствен интелект за подпомагане на вземането на решения и извършването на оценка на въздействието на законодателството; за електронно гласуване (за което също има пари по Добро управление, но и там има само един анализ и едно техническо задание); за преминаване от киберсигурност (която нямаме) към киберустойчивост.

Само че всички неща от предния абзац няма върху какво да стъпят. Нещата, които сме „отчели“, ги няма на практика (или ги има в много малка степен и са разпокъсани).

И това прави задачата толкова трудна. Единственото решение е политическо – някой да убеди Европейската комисия, че този път наистина ще на правим нещата, които 13 години сме отчитали, че правим. Не си представям как управляващите правят такава заявка. Възможно и да „мине“, пак. Но трябва планът да е добре структуриран, обоснован и с известна доза самопризнания за неуспехите досега. Трябва да заложи визия, цели, проекти, индикатори и срокове, които да имат смисъл, а да не са колекция от нечии хрумвания. В противен случай продължаваме с мокрите печати, докато човечеството не колонизира други планети. А може би и след това.

Материалът Дигитализацията на публичния сектор с европейски средства става все по-труднa е публикуван за пръв път на БЛОГодаря.

My Advice To Developers About Working With Databases: Make It Secure

Post Syndicated from Bozho original https://techblog.bozho.net/my-advice-to-developers-about-working-with-databases-make-it-secure/

Last month Ben Brumm asked me for the one advice I’d like to give to developers that are working with databases (in reality – almost all of us). He published mine as well as many others’ answers here, but I’d like to share it with my readers as well.

If I had to give developers working with databases one advice, it would be: make it secure. Every other thing you’ll figure in time – how to structure your tables, how to use ORM, how to optimize queries, how to use indexes, how to do multitenancy. But security may not be on the list of requirements and it may be too late when the need becomes obvious.

So I’d focus on several things:

  • Prevent SQL injections – make sure you use an ORM or prepared statements rather than building queries with string concatenation. Otherwise a malicious actor can inject anything in your queries and turn them into a DROP DATABASE query, or worse – one that exfiltrates all the data.
  • Support encryption in transit – this often has to be supported by the application’s driver configuration, e.g. by trusting a particular server certificate. Unencrypted communication, even within the same datacenter, is a significant risk and that’s why databases support encryption in transit. (You should also think about encryption at rest, but that’s more of an Ops task)
  • Have an audit log at the application level – “who did what” is a very important question from a security and compliance point of view. And no native database functionality can consistently answer the question “who” – it’s the application that manages users. So build an audit trail layer that records who did what changes to what entities/tables.
  • Consider record-level encryption for sensitive data – a database can be dumped in full by those who have access (or gain access maliciously). This is how data breaches happen. Sensitive data (like health data, payment data, or even API keys, secrets or tokens) benefits from being encrypted with an application-managed key, so that access to the database alone doesn’t reveal that data. Another option, often used for credit cards, is tokenization, which shifts the encryption responsibility to the tokenization providers. Managing the keys is hard, but even a basic approach is better than nothing.

Security is often viewed as an “operations” responsibility, and this has lead to a lot of tools that try to solve the above problem without touching the application – web application firewalls, heuristics for database access monitoring, trying to extract the current user, etc. But the application is the right place for many of these protections (although certainly not the only place), and as developers we need to be aware of the risks and best practices.

The post My Advice To Developers About Working With Databases: Make It Secure appeared first on Bozho's tech blog.

Вярно с електронно подписания оригинал

Post Syndicated from Bozho original https://blog.bozho.net/blog/3647

Много хора споделят тази снимка: „Вярно с електронно подписания оригинал“.

Тя е символ на електронното ни управление – на парче, неработещо на много места и пълно с абсурдни „закърпвания“. Но нека обясня.

Когато един електронен документ е подписан електронно, подписът му се проверява автоматично от софтуера за отваряне на документа – подписът гарантира (криптографски), че документът не е променян след като е подписан, както и кой в авторът. Има и държавна онлайн услуга за валидация.

Когато такъв документ се разпечата, обаче, всички тези гаранции изчезват (с което преди 11 години втрещих едни адвокати). Той става хартиен документ с лесна за манипулиране картинка на подпис. Това види до нуждата разпечатващият да удостовери (със саморъчен подпис и този текст), че разпечатаното не е изменяно. И така поставено изглежда съвсем логично.

Обаче… правилните подходи са други:

  • Не се разпечатва. Вече има задължение всички администрации да ползват електронни документи и във вътрешния си оборот, и в комуникация с други администрации. И това е технически възможно и работи. Няма причина да се разпечатва. Разбира се, на малко места е отпаднала хартията, защото какво пише в нормативната уредба и какво става на практика са различни неща.
  • На документа се посочват данни, с които оригиналният документ може да бъде изтеглен. Това предполага авторът да има онлайн система, където да се разполагат документите с адекватен контрол на достъпа. Електронното свидетелство за съдимост е такъв пример – има уеб адрес и код за проверка на оригинала. Тук трябва да се внимава, за да не може злонамерени хора да свалят цялата база с документи, налучквайки идентификаторите им.

И двата подхода (които не са взаимно изключващи се) предполагат архивиране на електронните документи. Това е процес съвършено различен от пълненето на мазета с папки с хартиени документи. За това има наредба и издадени на нейна база правила за архивиране. Нужни са неща като регулярна подмяна на дискове, резервни центрове (в рамките на държавния облак) и др. И някой да знае и спазва тези правила.

Ще продължава да има хипотези на разпечатване на е-документи, но те не трябва да бъдат в администрацията. Може в някоя фирма така да предпочитат или да са нужни за пред друга държава, където не ги приемат електронно. Но това са изключения.

Когато нямаш електронен документооборот (въпреки, че имаш техническата възможност за това), когато изискваш хартии при проверки, когато мисленето и на ръководителите, и на администрацията под тях и най-вече – на политическите ръководства, е хартиено, ще имаме това – разпечатване на е-документи. И „вярно с електронно подписания оригинал“ ще е съвсем логична практика, на която само някакви „фейсбук хейтъри“ са смеят.

Материалът Вярно с електронно подписания оригинал е публикуван за пръв път на БЛОГодаря.

COVID-19 и личната отговорност

Post Syndicated from Bozho original https://blog.bozho.net/blog/3644

Като гледаме данните, нещата с COVID-19 вече са извън контрол. Вече сме на нивата, на които Италия затвори всичко на 8-ми март, но положителен резултат имаше след няколко седмици.

Тук заведенията са пълни, училищата са отворени, а някои болници вече изнемогват; лекари напускат. Много е вероятно само след 10 дни да сме в ситуацията на Чехия (където учебната година започва на 1-ви септември).

На този фон правителството не прави нищо. То не се ползва с доверие, което да му позволи да наложи мерки, а въвеждането на непопулярни мерки толкова скоро преди изборите изисква смелост, каквато не мисля, че управляващите имат, колкото и да въртяха рефрена, че е нужно да са на власт заради кризата.

Българските власти не контролират спазването на ограниченията, не тестват достатъчно, не проследяват адекватно контакти на болни. Не въвеждат онлайн обучение поне за тези над 16г, както други държави.

На този фон, това, което имаме, е личната отговорност и личния пример.

Да носим маски, да ограничим контактите си, ходенето по заведения.

От днес ограничих ходенето в офиса (досега можеше, ако на някого му писне вкъщи, да дойде. Сега може само по изключение, напр. „нямам ток“). С голямо съжаление отказах покана за сватба на добър приятел. По улицата съм с маска. Скоро ще канселирам и бизнес пътуване през ноември (макар самолетите в крайна сметка да са доста безопасни)

Не всеки може да си позволи да си наложи ограничения и затова е важно тези, които можем, да го направим. Важно е и проактивно да докладваме контактите си, ако сме болни, дори да не ни питат (защото често не питат).

Дали такава реакция не е прекалена? Не мисля. Но дори да е, попада в категорията „управление на риска“.

Това може да продължи цяла зима и трябва да се подготвим психически. От сега.

Материалът COVID-19 и личната отговорност е публикуван за пръв път на БЛОГодаря.

Discovering an OSSEC/Wazuh Encryption Issue

Post Syndicated from Bozho original https://techblog.bozho.net/discovering-an-ossec-wazuh-encryption-issue/

I’m trying to get the Wazuh agent (a fork of OSSEC, one of the most popular open source security tools, used for intrusion detection) to talk to our custom backend (namely, our LogSentinel SIEM Collector) to allow us to reuse the powerful Wazuh/OSSEC functionalities for customers that want to install an agent on each endpoint rather than just one collector that “agentlessly” reaches out to multiple sources.

But even though there’s a good documentation on the message format and encryption, I couldn’t get to successfully decrypt the messages. (I’ll refer to both Wazuh and OSSEC, as the functionality is almost identical in both, with the distinction that Wazuh added AES support in addition to blowfish)

That lead me to a two-day investigation on possible reasons. The first side-discovery was the undocumented OpenSSL auto-padding of keys and IVs described in my previous article. Then it lead me to actually writing C code (an copying the relevant Wazuh/OSSEC pieces) in order to debug the issue. With Wazuh/OSSEC I was generating one ciphertext and with Java and openssl CLI – a different one.

I made sure the key, key size, IV and mode (CBC) are identical. That they are equally padded and that OpenSSL’s EVP API is correctly used. All of that was confirmed and yet there was a mismatch, and therefore I could not decrypt the Wazuh/OSSEC message on the other end.

After discovering the 0-padding, I also discovered a mistake in the documentation, which used a static IV of FEDCA9876543210 rather than the one found in the code, where the 0 preceded 9 – FEDCA0987654321. But that didn’t fix the issue either, only got me one step closer.

A side-note here on IVs – Wazuh/OSSEC is using a static IV, which is a bad practice. The issue is reported 5 years ago, but is minor, because they are using some additional randomness per message that remediates the use of a static IV; it’s just not idiomatic to do it that way and may have unexpected side-effects.

So, after debugging the C code, I got to a simple code that could be used to reproduce the issue and asked a question on Stackoverflow. 5 minutes after posting the question I found another, related question that had the answer – using hex strings like that in C doesn’t work. Instead, they should be encoded: char *iv = (char *)"\xFE\xDC\xBA\x09\x87\x65\x43\x21\x00\x00\x00\x00\x00\x00\x00\x00";. So, the value is not the bytes corresponding to the hex string, but the ASCII codes of each character in the hex string. I validated that in the receiving Java end with this code:

This has an implication on the documentation, as well as on the whole scheme as well. Because the Wazuh/OSSEC AES key is: MD5(password) + MD5(MD5(agentName) + MD5(agentID)){0, 15}, the 2nd part is practically discarded, because the MD5(password) is 32 characters (= 32 ASCII codes/bytes), which is the length of the AES key. This makes the key derived from a significantly smaller pool of options – the permutations of 16 bytes, rather than of 256 bytes.

I raised an issue with Wazuh. Although this can be seen as a vulnerability (due to the reduced key space), it’s rather minor from security point of view, and as communication is mostly happening within the corporate network, I don’t think it has to be privately reported and fixed immediately.

Yet, I made a recommendation for introducing an additional configuration option to allow to transition to the updated protocol without causing backward compatibility issues. In fact, I’d go further and recommend using TLS/DTLS rather than a home-grown, AES-based scheme. Mutual authentication can be achieved through TLS mutual authentication rather than through a shared secret.

It’s satisfying to discover issues in popular software, especially when they are not written in your “native” programming language. And as a rule of thumb – encodings often cause problems, so we should be extra careful with them.

The post Discovering an OSSEC/Wazuh Encryption Issue appeared first on Bozho's tech blog.

OpenSSL Key and IV Padding

Post Syndicated from Bozho original https://techblog.bozho.net/openssl-key-and-iv-padding/

OpenSSL is an omnipresent tool when it comes to encryption. While in Java we are used to the native Java implementations of cryptographic primitives, most other languages rely on OpenSSL.

Yesterday I was investigating the encryption used by one open source tool written in C, and two things looked strange: they were using a 192 bit key for AES 256, and they were using a 64-bit IV (initialization vector) instead of the required 128 bits (in fact, it was even a 56-bit IV).

But somehow, magically, OpenSSL didn’t complain the way my Java implementation did, and encryption worked. So, I figured, OpenSSL is doing some padding of the key and IV. But what? Is it prepending zeroes, is it appending zeroes, is it doing PKCS padding or ISO/IEC 7816-4 padding, or any of the other alternatives. I had to know if I wanted to make my Java counterpart supply the correct key and IV.

It was straightforward to test with the following commands:

# First generate the ciphertext by encrypting input.dat which contains "testtesttesttesttesttest"
$ openssl enc -aes-256-cbc -nosalt -e -a -A -in input.dat -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321' -out input-test.enc

# Then test decryption with the same key and IV
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
testtesttesttesttesttest

# Then test decryption with different paddings
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA9876543210'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c760' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76000' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '07c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
bad decrypt

So, OpenSSL is padding keys and IVs with zeroes until they meet the expected size. Note that if -aes-192-cbc is used instead of -aes-256-cbc, decryption will fail, because OpenSSL will pad it with fewer zeroes and so the key will be different.

Not an unexpected behavaior, but I’d prefer it to report incorrect key sizes rather than “do magic”, especially when it’s not easy to find exactly what magic it’s doing. I couldn’t find it documented, and the comments to this SO question hint in the same direction. In fact, for plaintext padding, OpenSSL uses PKCS padding (which is documented), so it’s extra confusing that it’s using zero-padding here.

In any case, follow the advice from the stackoverflow answer and don’t rely on this padding – always provide the key and IV in the right size.

The post OpenSSL Key and IV Padding appeared first on Bozho's tech blog.

Как да разкараме печатите от медицинските изследвания за прием в ясла

Post Syndicated from Bozho original https://blog.bozho.net/blog/3634

Наскоро трябваше да приемат Оги в ясла. Съответно трябваше да набавим един куп документи – два здравни картона, бележка от лекар и четири изследвания. Няма да коментирам факта, че все още имаме „здравен картон“ (че и два, даже), а не „единен здравен запис“, или смисъла от това да отидеш при лекар, който да ти напише хвърчащо листче, че детето ти не е контактувало с болни.

Ще коментирам обаче изследванията, и по-точно – удостоверяването на тяхната автентичност. Направихме всички изследвания, разпечатахме резултата от сайта на лабораторията, и ги занесохме заедно с другите документи. Само че – проблем. Трябвало да имат печати. Жена ми се разходи до лабораторията, сложиха ѝ един печат, обаче и това не беше достатъчно – трябвало да има втори, правоъгълен печат. Не можело да го приемат без него. Винаги бил така. А правоъгълният печат го имало само в централата на лабораторията – в другия край на града.

Попитах кой и защо го изисква – оказа се РЗИ (Столичната регионална здравна инспекция). Проведох около 15 разговора с 5-6 различни хора в РЗИ, изчетох приложимата нормативна уредба (Наредба 26, Наредба 3, и общо взето заключих три неща:

  • Това не е работа на никого. Може би на инспекторите.
  • Няма нормативно основание за изискване на печати
  • Могат да глобят яслата, ако няма печати, защото „разбира се, че ще ви върнат, като нямате печат“

Накрая се разходих до другия край на града, за да ми „набият“ правоъгълен печат. Но това не би трябвало да остава така – в ситуация на пандемия да обикаляме лаборатории и болници, увеличавайки риска от заразяване, без абсолютно никаква разумна причина за това.

Така че предприех следните мерки:

  • Писмо до Министерство на здравеопазването с предложения за нормативно уреждане на автентичността на медицински изследвания
  • Писмо до РЗИ да прекратят незаконосъобразните си практики
  • Писмо до Столична община, да установи ясни изисквания към детските ясли относно реквизитите на документи, които изискват

Целта е да има законосъобразни правила, директорите на яслите и инспекторите на РЗИ да знаят какви са правилата, а не да си ги измислят на място или да правят „както винаги са правили“, без да има нормативно основание за това.

Писмата до РЗИ и Столична община са скучни, но ще приложа писмото до Министерство на образованието, защото там са реалните предложения за промяна. Както сподели един от хората в РЗИ, съществува проблем с фалшиви изследвания, и „декларациите не работят“ (на моето предложение да спазват административнопроцесуалния кодекс и да приемат декларация за истинност на изследванията):

Чл. 43. Административният орган не може да откаже приемане на писмена декларация, с която се установяват факти и обстоятелства, за които специален закон не предвижда доказване по определен начин или с определени средства. [..]

Писмото до министъра изисква единствено нормативни изменения – с изключение на ал. 3, т. 3, останалите варианти са налице и в момента. Използването на електронни печати е по принцип правилния подход в дългосрочен план, но изисква надграждане на системи.

Уважаеми г-н Министър,

Във връзка с неписано правило Столичната РЗИ да изисква два различни печата върху изследвания за приемане на деца (по реда на чл. 20 от Наредба 26 от 18.11.2008 за устройството на дейността на детските ясли и детските кухни и здравните изисквания към тях), и отчитайки:
1. Голямото неудобство за родители в това да бъдат куриери на администрацията и в 21-ви век да обикалят за различни видове печати, особено в контекста на пандемия.
2. Риска от предоставяне на фалшиви изследвания
3. Факта, че повечето лаборатории имат онлайн системи за предоставяне на резултатите от изследвания
4. Усилията за въвеждане на електронно здравеопазване

бих искал да предложа следното изменение на Наредба 26:

В чл. 20 се създават нови алинеи 3-5:
(3) Автентичността на изследванията по ал. 1, т.3-5 се удостоверява от лабораторията, извършила изследването, по един от следните начини:
1. чрез възможност за проверка с телефонно обаждане на база на уникален идентификатор на изследването. Телефон за контакт и номер на изследването трябва да са посочени в документа с резултатите.
2. чрез предоставяне от страна на родителите на данни за достъп до онлайн система за проверка на резултата
3. чрез електронен печат на лабораторията върху електронен документ с резултатите, по смисъла на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета от 23 юли 2014 г. относно електронната идентификация и удостоверителните услуги при електронни трансакции на вътрешния пазар и за отмяна на Директива 1999/93/ЕО (ОВ, L 257/73 от 28 август 2014 г.)
3.
(4) Резултатите от изследванията по ал. 1, т.3-5 се приемат на хартиен носител и по електронен път, на адрес на електронна поща или чрез системата за сигурно електронно връчване по смисъла на § 1, т. 31 от допълнителните разпоредби на Закона за електронното управление.
(5) Резултатите от изследванията по ал. 1, т.3-5 се съхраняват за срок от 12 месеца, след което се унищожават.

Съхранението на данни за достъп (потребителско име и парола) е по принцип рисково, но в случая то е идентично на съхраняването на самите изследвания, като в същото време предоставя възможност за проверка на автентичността на данните.

Би следвало да се обмисли вариант и за по-обща уредба на въпроса с автентичността на медицински изследвания, когато те се изискват по силата на нормативен акт за осъществяване на дадено право.

С уважение,
Божидар Божанов

В по-общ смисъл, за цялата драма с печатите преди време бях подготвил изменение на Административнопроцесуалния кодекс, с която да се забрани изискването на печати:

„§ 1а. (1) Във връзка с административното обслужване на гражданите и юридическите лица административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги не могат да изискват полагане на печат върху документ на хартиен носител за удостоверяване на авторството.
(2) Авторството на документ по ал. 1 се удостоверява от неговия издател чрез саморъчен подпис. Документът съдържа информация за имената на лицето, което го е издало, качеството и длъжността, в които действа, както и основанието на неговата представителна власт.
(3) Органите, лицата и организациите по ал. 1 не могат да отказват приемане на документ от граждани и юридически поради липса на поставен печат.
(4) За неизпълнение на задълженията по ал. 1 и 3 на отговорните длъжностни лица се налага административнонаказателна санкция по чл. 305 от Административнопроцесуалния кодекс.“

(Следват изменения на двайсетина закона, които в момента изискват печат под някаква форма, които ще ви спестя, – такъв законопроект Демократична България ще може да внесе в парламента след няколко месеца.)

Защо се занимавам с нещо толкова дребно? Нали вече записахме детето, повече едва ли ще имаме тоя проблем?

Защото това е чудесен пример защо няма електронно управление. На теория има, на практика някой някъде иска печат от някой друг и няма правен аргумент, който да го убеди в обратното. Затова трябва наредба по наредба, член по член, административен орган по административен орган да се налага електронната реалност. И защото е важно да променяме мисленето на всички нива – и на политическо ниво, и в администрацията, а и в съгражданите си, които с години са обикаляли за печати, защото „как така без печат“.

Материалът Как да разкараме печатите от медицинските изследвания за прием в ясла е публикуван за пръв път на БЛОГодаря.

ElasticSearch Multitenancy With Routing

Post Syndicated from Bozho original https://techblog.bozho.net/elasticsearch-multitenancy-with-routing/

Elasticsearch is great, but optimizing it for high load is always tricky. This won’t be yet another “Tips and tricks for optimizing Elasticsearch” article – there are many great ones out there. I’m going to focus on one narrow use-case – multitenant systems, i.e. those that support multiple customers/users (tenants).

You can build a multitenant search engine in three different ways:

  • Cluster per tenant – this is the hardest to manage and requires a lot of devops automation. Depending on the types of customers it may be worth it to completely isolate them, but that’s rarely the case
  • Index per tenant – this can be fine initially, and requires little additional coding (you just parameterize the “index” parameter in the URL of the queries), but it’s likely to cause problems as the customer base grows. Also, supporting consistent mappings and settings across indexes may be trickier than it sounds (e.g. some may reject an update and others may not depending on what’s indexed). Moving data to colder indexes also becomes more complex.
  • Tenant-based routing – this means you put everything in one cluster but you configure your search routing to be tenant-specific, which allows you to logically isolate data within a single index.

The last one seems to be the preferred option in general. What is routing? The Elasticsearch blog has a good overview and documentation. The idea lies in the way Elasticsearch handles indexing and searching – it splits data into shards (each shard is a separate Lucene index and can be replicated on more than one node). A shard is a logical grouping within a single Elasticsearch node. When no custom routing is used, and an index request comes, the ID is used to determine which shard is going to be used to store the data. However, during search, Elasticsearch doesn’t know which shards have the data, so it has ask multiple shards and gather the results. Related to that, there’s the newly introduced adaptive replica selection, where the proper shard replica is selected intelligently, rather than using round-robin.

Custom routing allows you to specify a routing value when indexing a document and then a search can be directed only to the shard that has the same routing value. For example, at LogSentinel when we index a log entry, we use the data source id (applicationId) for routing. So each application (data source) that generates logs has a separate identifier which allows us to query only that data source’s shard. That way, even though we may have a thousand clients with a hundred data sources each, a query will be precisely targeted to where the data for that particular customer’s data source lies.

This is key for horizontally scaling multitenant applications. When there’s terabytes of data and billions of documents, many shards will be needed (in order to avoid large and heavy shards that cause performance issues). Finding data in this haystack requires the ability to know where to look.

Note that you can (and probably should) make routing required in these cases – each indexed document must be required to have a routing key, otherwise an implementation oversight may lead to a slow index.

Using custom routing you are practically turning one large Elasticsearch cluster into smaller sections, logically separated based on meaningful identifiers. In our case, it is not a userId/customerId, but one level deeper – there are multiple shards per customer, but depending on the use-case, it can be one shard per customer, using the userId/customerId. Using more than one shard per customer may complicate things a little – for example having too many shards per customer may require searches that span too many shards, but that’s not necessarily worse than not using routing.

There are some caveats – the isolation of customer data has to be handled in the application layer (whereas for the first two approaches data is segregated operationally). If there’s an application bug or lack of proper access checks, one user can query data from other users’ shards by specifying their routing key. It’s the role of the application in front of Elasticsearch to only allow queries with routing keys belonging to the currently authenticated user.

There are cases when the first two approaches to multitenancy are viable (e.g. a few very large customers), but in general the routing approach is the most scalable one.

The post ElasticSearch Multitenancy With Routing appeared first on Bozho's tech blog.

Is It Really Two-Factor Authentication?

Post Syndicated from Bozho original https://techblog.bozho.net/is-it-really-two-factor-authentication/

Terminology-wise, there is a clear distinction between two-factor authentication (multi-factor authentication) and two-step verification (authentication), as this article explains. 2FA/MFA is authentication using more than one factors, i.e. “something you know” (password), “something you have” (token, card) and “something you are” (biometrics). Two-step verification is basically using two passwords – one permanent and another one that is short-lived and one-time.

At least that’s the theory. In practice it’s more complicated to say which authentication methods belongs to which category (“something you X”). Let me illustrate that with a few emamples:

  • An OTP hardware token is considered “something you have”. But it uses a shared symmetric secret with the server so that both can generate the same code at the same time (if using TOTP), or the same sequence. This means the secret is effectively “something you know”, because someone may steal it from the server, even though the hardware token is protected. Unless, of course, the server stores the shared secret in an HSM and does the OTP comparison on the HSM itself (some support that). And there’s still a theoretical possibility for the keys to leak prior to being stored on hardware. So is a hardware token “something you have” or “something you know”? For practical purposes it can be considered “something you have”
  • Smartphone OTP is often not considered as secure as a hardware token, but it should be, due to the secure storage of modern phones. The secret is shared once during enrollment (usually with on-screen scanning), so it should be “something you have” as much as a hardware token
  • SMS is not considered secure and often given as an example for 2-step verification, because it’s just another password. While that’s true, this is because of a particular SS7 vulnerability (allowing the interception of mobile communication). If mobile communication standards were secure, the SIM card would be tied to the number and only the SIM card holder would be able to receive the message, making it “something you have”. But with the known vulnerabilities, it is “something you know”, and that something is actually the phone number.
  • Fingerprint scanners represent “something you are”. And in most devices they are built in a way that the scanner authenticates to the phone (being cryptographically bound to the CPU) while transmitting the fingerprint data, so you can’t just intercept the bytes transferred and then replay them. That’s the theory; it’s not publicly documented how it’s implemented. But if it were not so, then “something you are” is “something you have” – a sequence of bytes representing your fingerprint scan, and that can leak. This is precisely why biometric identification should only be done locally, on the phone, without any server interaction – you can’t make sure the server is receiving sensor-scanned data or captured and replayed data. That said, biometric factors are tied to the proper implementation of the authenticating smartphone application – if your, say, banking application needs a fingerprint scan to run, a malicious actor should not be able to bypass that by stealing shared credentials (userIDs, secrets) and do API calls to your service. So to the server there’s no “something you are”. It’s always “something that the client-side application has verified that you are, if implemented properly”
  • A digital signature (via a smartcard or yubikey or even a smartphone with secure hardware storage for private keys) is “something you have” – it works by signing one-time challenges, sent by the server and verifying that the signature has been created by the private key associated with the previously enrolled public key. Knowing the public key gives you nothing, because of how public-key cryptography works. There’s no shared secret and no intermediary whose data flow can be intercepted. A private key is still “something you know”, but by putting it in hardware it becomes “something you have”, i.e. a true second factor. Of course, until someone finds out that the random generation of primes used for generating the private key has been broken and you can derive the private key form the public key (as happened recently with one vendor).

There isn’t an obvious boundary between theoretical and practical. “Something you are” and “something you have” can eventually be turned into “something you know” (or “something someone stores”). Some theoretical attacks can become very practical overnight.

I’d suggest we stick to calling everything “two-factor authentication”, because it’s more important to have mass understanding of the usefulness of the technique than to nitpick on the terminology. 2FA does not solve phishing, unfortunately, but it solves leaked credentials, which is good enough and everyone should have some form of it. Even SMS is better than nothing (obviously, for high-profile systems, digital signatures is the way to go).

The post Is It Really Two-Factor Authentication? appeared first on Bozho's tech blog.

Хронология на липсващата електронна идентификация

Post Syndicated from Bozho original https://blog.bozho.net/blog/3627

Електронна идентификация (по-конкретно националната схема за електронна идентификация), която е и кокошката, и яйцето на електронното управление, все още я няма. Ето кратка хронология:

  1. В края на 2016 г. е готово всичко – има закон, правилник, осигурено европейско финансиране, техническа спецификация и документация по ЗОП (Закона за обществените поръчки).
  2. Процедурата е пусната… и спряна в края на лятото на 2017 г (в следствие на няколко фалшиви обжалвания пред КЗК от фирми, чиято дейност няма нищо общо с поръчката).
  3. Август 2018 (1г по-късно) електронната идентификация е пусната като част от голямата поръчка за личните карти.
  4. Поради избора на усложнена процедура свързана с класифицирането на части от поръчката (на две стъпки – одобрение на кандидати, и след това поръчка), изпълнител е избран в края на април тази година. Към момента доколкото знам тече процедура по обжалване на решението.
  5. Очаква се до края на годината (ако обжалванията паднат) да бъде сключен договор с изпълнителя и той да започне работа
  6. Сроковете за eID по спомен са около 18 месеца, т.е. в края на 2022 г. ще имаме система. Чиято спецификация е писана 6 години и половина по-рано и вече не е напълно актуална (напр. вече е достатъчно сигурно да се записва частен ключ в мобилен телефон с Android или iOS; през 2016 г. не беше).

Защо е толкова важна електронната идентификация (за която съм писал доста)? Дългият отговор е в тази 40-минутна презентация от 2016г. Краткият отговор е: защото гражданите нямат налично и удобно средство да се идентифицират онлайн пред държавата. Електронните подписи, които в преходния период (удължен от „2 години“ на „докато стане“) трябва да вършат тази работа имат редица проблеми.

Първо – те са средство за подписване, не за идентификация и като такива нямат възможността в реално време да предоставят актуална информация за лицето извън записаната в удостоверението. Няма нужда да имаме саморъчен подпис, за да покажем на държавата (или дори на частни субекти) кои сме в онлайн среда. Трябва ни „виртуална лична карта“, която обаче не може да се копира и фалшифицира. Електронни услуги за физически лица могат и трябва да се ползват само с идентификация, с малки изключения.

Второ – струват пари и поради това (без значение колко са евтини), не може да се постигне масовост сред гражданите. Така дори да има е-услуги, хората няма с какво да ги ползват. Пример – опашките пред НОИ през март, след като НОИ пусна доста услуги онлайн, но хората трябваше да се наредят, за да си вземат ПИК. При електронната идентификация положението е „апетитът идва с яденето“. И трябва критична маса хора просто да разполагат със средството за идентификация в джоба си, за да потеглят нещата. Примери за това много, като любимият ми е Естония срещу Финландия. Естония дава на всички безплатна електронна идентификация, Финландия я прави опционална и платена. 15 години по-късно Естония „изнася“ електронно управление за Финландия, които изостават значително (опростявам историята, но е горе-долу така).

Трето – националната схема за електронна идентификация не е само средството (дали ще е карта, „флашка“ или мобилен телефон). Тя е цялата инфраструктура, с която всяка електронна услуга да може да поиска идентификация от централизиран компонент, който да събере нужната информация в реално време. Националната схема е и компонент от системата за трансгранична електронна идентификация в рамките на ЕС (която не че е тръгнала успешно, но по други причини).

Без електронна идентификация, всяка електронна услуга има много малка аудитория, което се потвърждава и от данните – извън услугите на НАП, които НАП активно промотира заедно със своя ПИК, използването на почти всички останали е минимално и доста неудобно.

Защо не е станало още? Всички политически решения по пътя от 2017 досега са лоши – спиране на отделната процедура; обединяване с голяма поръчка без реална нужда от това; засекретяване и избор на утежнена процедура; процедура, която не е разделена на лотове, позволяващи различни изпълнители; бавене.

Така при напълно готова документация и финансиране, цял мандат не стига дори да се започне работа по най-ключовата система за електронното управление. Всички останали институции (вкл. ЦИК за пилотното дистанционно електронно гласуване) пък се оправдават „ами тя е в МВР системата, ние нищо не можем да направим“.

Та така за управленския капацитет, визията и стратегическите проекти за модернизация на страната. Кой щял да дойде след оставката.. ‘де да знам, дано някой, дето да може за един мандат поне договор да сключи.

Материалът Хронология на липсващата електронна идентификация е публикуван за пръв път на БЛОГодаря.

Наръчник за правилно протестиране

Post Syndicated from Bozho original https://blog.bozho.net/blog/3618

Протестите са хубаво нещо по принцип, обаче… тия точно не! Сега ще ви обясня как е правилно да се протестира, така че всички да са доволни.

Правилно протестиращият не иска просто оставка, защото така не е достатъчно ясно какво точно иска. Правилно протестиращият трябва да си носи в джоба лист А4 със законодателни изменения, които преди това е синхронизирал с всички останали на площада. Иначе за какво протестира?

Правилно протестиращият, обаче, трябва да протестира и срещу всичко останало и да има много точен отговор на въпроса къде е бил, когато нещо друго е станало.

Правилно протестиращият трябва да каже кой ще дойде след оставката. Нали е там с много хора – да съберат пари за социология и да имат готов отговор. После изборите ще са проформа.

Правилно протестиращият не е организиран или организатор, но трябва да е подал заявление за протест, да е част от многохилядна тълпа (иначе няма смисъл) и да отговаря в социалните мрежи защо други хора протестират неправилно.

Правилно протестиращият няма предварително подготвен плакат, защото това значи, че някой му плаща. Най-вероятно някой олигарх, то кой друг има пари у нас.

Правилно протестиращият не пие бира. Бира се пие само на маса, а не като тия пропадняци на крак. Това е признак на много ниска култура и липса на национално самосъзнание.

Правилно протестиращият протестира стриктно извън работно време. Противното би значело, че е безработен лентяй.

Правилно протестиращият знае как е било на протестите 90-та година и знае как се прави. Но в същото време трябва да е млад, за да може премиерът да каже една хубава дума за него.

Правилно протестиращият не затваря кръстовища, защото така не пречи на властта, а само на хората, които имат спешна работа в центъра. По изключение може да се затвори някое кръстовище около някоя сграда на властта, но за малко и с предварително предупреждение.

Правилно протестиращият не се разхожда, защото с разходки нищо не се постига.

Правилно протестиращият не прави пърформанси. Не свири на пиано, не се облича театрално, не прави флашмобове. С пърформанси властта няма да падне!

Правилно протестиращият много внимава със стилистиката на своите послания и тези на всички около него. Ако някой извади ковчег, бесилка или чувла, правилно протестиращият трябва да отиде и да го убеди, че така не трябва. Иначе е съпричастен към лошата стилистика.

Правилно протестиращият не е агресивен. Не обижда полицията, не хвърля шишета вода, не се бута, не чупи. Стои си кротко, защото с пърформанси може и властта да не падне, но пък ако падне по друг начин е още по-лошо. Най-добре да не пада.

Правилно протестиращият не се намира в радиус от 100 метра с някой неправилно протестиращ, защото носи отговорност за действията му.

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

Правилно протестиращият, ако бъде набит от полицията в някоя тъмна уличка, се заема лично да идентифицира кой го е бил и прави пресконференция, в която да поздрави ръководството на МВР за пропорционалните мерки за опазване на реда, изразявайки позитивно очакване за дисциплинарно наказание на този един объркал се от умората полицай.

Общо взето, правилно протестиращият трябва да отиде в 18:30 пред някоя сграда, да поздрави полицията, да надуе свирка десетина пъти, да викне „Оставка“, да си тръгне към 21 ч., преди да са дошли провокаторите, а на другия ден да напише писмо на управляващите какви точно промени иска. Всичко друго е напълно недопустимо и дискредитира и омаскарява иначе легитимния граждански протест, който всички бихме подкрепили!

Жалко, че толкова много хора протестират неправилно. Ако следваха този наръчник, властта нямаше да е паднала, но щеше да е по-добре – щеше да е чула протестиращите! Представям си го така – след получаване на исканията на протестиращите се прави междуведомствена работна група, която да предложи нормативни изменения, по които да бъде постигнат консенсус в легитимно избраното Народно събрание! Чувал съм, че така работят развитите западни демокрации, към които се стремим.

Пък и защо да пада легитимно избрана власт? Никакви корупционни скандали, зависимости на премиера, нарушаване на законови и етични стандарти, не могат да са достатъчен аргумент срещу демократично избрана власт. Милион и двеста хиляди избиратели са казали, че искат тези управляващи да дават поръчки и влияние на Пеевски, Доган и други обръчи и да пратят правилните хора във ВСС, които да изберат Гешев. Тези хора на площада са по-малко от милион и двеста хиляди!

Но с времето ще се научим. Като излязат на площада милион и триста хиляди правилно протестиращи (подчертавам правилно), тогава може да има оставка. А дотогава – работа, работа, работа.

Bulk vs Individual Compression

Post Syndicated from Bozho original https://techblog.bozho.net/bulk-vs-individual-compression/

I’d like to share something very brief and very obvious – that compression works better with large amounts of data. That is, if you have to compress 100 sentences you’d better compress them in bulk rather than once sentence at a time. Let me illustrate that:

public static void main(String[] args) throws Exception {
    List<String> sentences = new ArrayList<>();
    for (int i = 0; i < 100; i ++) {
        StringBuilder sentence = new StringBuilder();
        for (int j = 0; j < 100; j ++) { 
          sentence.append(RandomStringUtils.randomAlphabetic(10)).append(" "); 
        } 
        sentences.add(sentence.toString()); 
    } 
    byte[] compressed = compress(StringUtils.join(sentences, ". ")); 
    System.out.println(compressed.length); 
    System.out.println(sentences.stream().collect(Collectors.summingInt(sentence -> compress(sentence).length)));
}

The compress method is using commons-compress to easily generate results for multiple compression algorithms:

public static byte[] compress(String str) {
   if (str == null || str.length() == 0) {
       return new byte[0];
   }
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   try (CompressorOutputStream gzip = new CompressorStreamFactory()
           .createCompressorOutputStream(CompressorStreamFactory.GZIP, out)) {
       gzip.write(str.getBytes("UTF-8"));
       gzip.close();
       return out.toByteArray();
   } catch (Exception ex) {
       throw new RuntimeException(ex);
   }
}

The results are as follows, in bytes (note that there’s some randomness, so algorithms are not directly comparable):

Algorithm Bulk Individual
GZIP 6590 10596
LZ4_FRAMED 9214 10900
BZIP2 6663 12451

Why is that an obvious result? Because of the way most compression algorithms work – they look for patterns in the raw data and create a map of those patterns (a very rough description).

How is that useful? In big data scenarios where the underlying store supports per-record compression (e.g. a database or search engine), you may save a significant amount of disk space if you bundle multiple records into one stored/indexed record.

This is not a generically useful advice, though. You should check the particular datastore implementation. For example MS SQL Server supports both row and page compression. Cassandra does compression on an SSTable level, so it may not matter how you structure your rows. Certainly, if storing data in files, storing it in one file and compressing it is more efficient than compressing multiple files separately.

Disk space is cheap so playing with data bundling and compression may be seen as premature optimization. But in systems that operate on large datasets it’s a decision that can save you a lot of storage costs.

The post Bulk vs Individual Compression appeared first on Bozho's tech blog.