Monthly Archives: November 2021

Simple Things That Are Actually Hard: User Authentication

от Божидар Божанов
лиценз CC BY

You build a system. User authentication is the component that is always there, regardless of the functionality of the system. And by now it should be simple to implement it – just “drag” some ready-to-use authentication module, or configure it with some basic options (e.g. Spring Security), and you’re done.

Well, no. It’s the most obvious thing and yet it’s extremely complicated to get right. It’s not just login form -> check username/password -> set cookie. It has a lot of other things to think about:

  • Cookie security – how to make it so that a cookie doesn’t leak or can’t be forged. Should you even have a cookie, or use some stateless approach like JWT, use SameSite lax or strict?
  • Bind cookie to IP and logout user if IP changes?
  • Password requirements – minimum length, special characters? UI to help with selecting a password?
  • Storing passwords in the database – bcrypt, scrypt, PBKDF2, SHA with multiple iterations?
  • Allow storing in the browser? Generally “yes”, but some applications deliberately hash it before sending it, so that it can’t be stored automatically
  • Email vs username – do you need a username at all? Should change of email be allowed?
  • Rate-limiting authentication attempts – how many failed logins should block the account, for how long, should admins get notifications or at least logs for locked accounts? Is the limit per IP, per account, a combination of those?
  • Captcha – do you need captcha at all, which one, and after how many attempts? Is Re-Captcha an option?
  • Password reset – password reset token database table or expiring links with HMAC? Rate-limit password reset?
  • SSO – should your service should support LDAP/ActiveDirectory authentication (probably yes), should it support SAML 2.0 or OpenID Connect, and if yes, which ones? Or all of them? Should it ONLY support SSO, rather than internal authentication?
  • 2FA – TOTP or other? Implement the whole 2FA flow, including enable/disable and use or backup codes; add option to not ask for 2FA for a particular device for a period of time? Configuring subset of AD/LDAP users to authenticate based on certain group memberships?
  • Force 2FA by admin configuration – implement time window for activating 2FA after a global option is enabled?
  • Login by link – should the option to send a one-time login link be email be supported?
  • XSS protection – make sure no XSS vulnerabilities exist especially on the login page (but not only, as XSS can steal cookies)
  • Dedicated authentication log – keep a history of all logins, with time, IP, user agent
  • Force logout – is the ability to logout a logged-in device needed, how to implement it, e.g. with stateless tokens it’s not trivial.
  • Keeping a mobile device logged in – what should be stored client-side? (certainly not the password)
  • Working behind proxy – if the client IP matters (it does), make sure the X-Forwarded-For header is parsed
  • Capture login timezone for user and store it in the session to adjust times in the UI?
  • TLS Mutual authentication – if we need to support hardware token authentication with private key, we should enable TLS mutual. What should be in the truststore, does the web server support per-page mutual TLS or should we use a subdomain, if there’s a load balancer / reverse proxy, does it support it and how to forward certificate details?
  • Require account activation or let the user login immediately after registration? Require account approval by back-office staff?
  • Initial password setting for accounts created by admins – generate initial password and force changing it on first login? Don’t generate password and start from a password reset flow?
  • Login anomalies – how to detect them and should you inform the user? Should you rely on 3rd party tools (e.g. a SIEM), or have such functionality built-in?

And that’s for the most obvious feature that every application has. No wonder it has been implemented incorrectly many, many times. The IT world is complex and nothing is simple. Sending email isn’t simple, authentication isn’t simple, logging isn’t simple. Working with strings and dates isn’t simple, sanitizing input and output isn’t simple.

We have done a poor job in building the frameworks and tools to help us with all those things. We can’t really ignore them, we have to think about them actively and take conscious, informed decisions.

The post Simple Things That Are Actually Hard: User Authentication appeared first on Bozho's tech blog.

Как се пише: вездесъщ или въздесъщ?

от Павлина Върбанова
лиценз CC BY-NC-ND
Правилно е да се пише вездесъщ, също и вездесъща, вездесъщо, вездесъщи. Нима не е казано също, че Бог е вездесъщ, всезнаещ и всемогъщ? След полицейските коли веднага се появи открит ландроувър с вездесъщите журналисти.

Как се пише: автомат или афтомат?

от Павлина Върбанова
лиценз CC BY-NC-ND
Правилно е да се пише автомат, мн.ч. автомати. Думата е заета чрез руски (автомат) или немски (Automat) от къснолатински и гръцки. Докато чаках да стане време за срещата, си взех капучино от кафе автомата. Автоматът за затваряне Dorma TS73V е подходящ за по-тежки врати. Електронният стълбищен автомат управлява стълбищното осветление на жилищни сгради и други […]

ЕС: Законодателeн акт за свободата на медиите

от Нели Огнянова
лиценз CC BY

Откривайки European News Media Forum, Комисарят за вътрешния пазар Тиери Бретон  днес потвърди, че се готви Законодателен акт за свободата на медиите:

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

В отговор Европейската комисия ще представи през следващата година Законодателен акт за свободата на медиите. Целта му ще бъде да гарантира честни и независими медии. Искаме

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

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

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

Ето какво е казал Бретон през април 2021.

Комисар Вера Йоурова закри  форума. Тя обобщи инициативите, които ЕК ще предприеме през идващата година – като използва законодателни, незаконодателни и финансови инструменти.

Integrity Guarantees of Blockchains In Case of Single Owner Or Colluding Owners

от Божидар Божанов
лиценз CC BY

The title may sound as a paper title, rather than a blogpost, because it was originally an idea for such, but I’m unlikely to find the time to put a proper paper about it, so here it is – a blogpost.

Blockchain has been touted as the ultimate integrity guarantee – if you “have blockchain”, nobody can tamper with your data. Of course, reality is more complicated, and even in the most distributed of ledgers, there are known attacks. But most organizations that are experimenting with blockchain, rely on a private network, sometimes having themselves as the sole owner of the infrastructure, and sometimes sharing it with just a few partners.

The point of having the technology in the first place is to guarantee that once collected, data cannot be tampered with. So let’s review how that works in practice.

First, we have two define two terms – “tamper-resistant” (sometimes referred to as tamper-free) and “tamper-evident”. “Tamper-resistant” means nobody can ever tamper with the data and the state of the data structure is always guaranteed to be without any modifications. “Tamper-evident”, on the other hand, means that a data structure can be validated for integrity violations, and it will be known that there have been modifications (alterations, deletions or back-dating of entries). Therefore, with tamper-evident structures you can prove that the data is intact, but if it’s not intact, you can’t know the original state. It’s still a very important property, as the ability to prove that data is not tampered with is crucial for compliance and legal aspects.

Blockchain is usually built ontop of several main cryptographic primitives: cryptographic hashes, hash chains, Merkle trees, cryptographic timestamps and digital signatures. They all play a role in the integrity guarantees, but the most important ones are the Merkle tree (with all of its variations, like a Patricia Merkle tree) and the hash chain. The original bitcoin paper describes a blockchain to be a hash chain, based on the roots of multiple Merkle trees (which form a single block). Some blockchains rely on a single, ever-growing merkle tree, but let’s not get into particular implementation details.

In all cases, blockchains are considered tamper-resistant because their significantly distributed in a way that enough number of members have a copy of the data. If some node modifies that data, e.g. 5 blocks in the past, it has to prove to everyone else that this is the correct merkle root for that block. You have to have more than 50% of the network capacity in order to do that (and it’s more complicated than just having them), but it’s still possible. In a way, tamper resistance = tamper evidence + distributed data.

But many of the practical applications of blockchain rely on private networks, serving one or several entities. They are often based on proof of authority, which means whoever has access to a set of private keys, controls what the network agree on. So let’s review the two cases:

  • Multiple owners – in case of multiple node owners, several of them can collude to rewrite the chain. The collusion can be based on mutual business interest (e.g. in a supply chain, several members may team up against the producer to report distorted data), or can be based on security compromise (e.g. multiple members are hacked by the same group). In that case, the remaining node owners can have a backup of the original data, but finding out whether the rest were malicious or the changes were legitimate part of the business logic would require a complicated investigation.
  • Single owner – a single owner can have a nice Merkle tree or hash chain, but an admin with access to the underlying data store can regenerate the whole chain and it will look legitimate, while in reality it will be tampered with. Splitting access between multiple admins is one approach (or giving them access to separate nodes, none of whom has access to a majority), but they often drink beer together and collusion is again possible. But more importantly – you can’t prove to a 3rd party that your own employees haven’t colluded under orders from management in order to cover some tracks to present a better picture to a regulator.

In the case of a single owner, you don’t even have a tamper-evident structure – the chain can be fully rewritten and nobody will understand that. In case of multiple owners, it depends on the implementation. There will be a record of the modification at the non-colluding party, but proving which side “cheated” would be next to impossible. Tamper-evidence is only partially achieved, because you can’t prove whose data was modified and whose data hasn’t (you only know that one of the copies has tampered data).

In order to achieve tamper-evident structure with both scenarios is to use anchoring. Checkpoints of the data need to be anchored externally, so that there is a clear record of what has been the state of the chain at different points in time. Before blockchain, the recommended approach was to print it in newspapers (e.g. as an ad) and because it has a large enough circulation, nobody can collect all newspapers and modify the published checkpoint hash. This published hash would be either a root of the Merkle tree, or the latest hash in a hash chain. An ever-growing Merkle tree would allow consistency and inclusion proofs to be validated.

When we have electronic distribution of data, we can use public blockchains to regularly anchor our internal ones, in order to achieve proper tamper-evident data. We, at LogSentinel, for example, do exactly that – we allow publishing the latest Merkle root and the latest hash chain to Ethereum. Then even if those with access to the underlying datastore manage to modify and regenerate the entire chain/tree, there will be no match with the publicly advertised values.

How to store data on publish blockchains is a separate topic. In case of Ethereum, you can put any payload within a transaction, so you can put that hash in low-value transactions between two own addresses (or self-transactions). You can use smart-contracts as well, but that’s not necessary. For Bitcoin, you can use OP_RETURN. Other implementations may have different approaches to storing data within transactions.

If we want to achieve tamper-resistance, we just need to have several copies of the data, all subject to tamper-evidence guarantees. Just as in a public network. But what a public network gives is is a layer, which we can trust with providing us with the necessary piece for achieving local tamper evidence. Of course, going to hardware, it’s easier to have write-only storage (WORM, write once, ready many). The problem with it, is that it’s expensive and that you can’t reuse it. It’s not so much applicable to use-cases that require short-lived data that requires tamper-resistance.

So in summary, in order to have proper integrity guarantees and the ability to prove that the data in a single-owner or multi-owner private blockchains hasn’t been tampered with, we have to send publicly the latest hash of whatever structure we are using (chain or tree). If not, we are only complicating our lives by integrating a complex piece of technology without getting the real benefit it can bring – proving the integrity of our data.

The post Integrity Guarantees of Blockchains In Case of Single Owner Or Colluding Owners appeared first on Bozho's tech blog.

Как се пише: апендицит, апендисит, апандисит или апендисит?

от Павлина Върбанова
лиценз CC BY-NC-ND
Правилно е да се пише апендицит или апандисит. Двете форми са дублетни. Препоръчваме ви да употребявате медицинския термин апендицит. Думата е заета чрез руски или френски от новолатински – appendicitis. При съмнение за остър апендицит/апандисит детето се хоспитализира в клиниката за активно наблюдение. Спорно е съществуването на т.нар. хроничен апендицит/апандисит.

Как се пише: акомпанятор или акомпаниатор?

от Павлина Върбанова
лиценз CC BY-NC-ND
Правилно е да се пише акомпанятор, мн.ч. акомпанятори. Думата е заета от италиански – accompagnatore. Професионалният пианист може да бъде: солист, акомпанятор, пианист в оркестър и т.н. Акомпанятори ще бъдат ученици от класа по клавирен съпровод на Олга Дичева.

Представителна история за една шофьорска книжка

от Божидар Божанов
лиценз CC BY

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

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

Последва дежурното обаждане (от пътна полиция към СДВР) „то не може“, предадено към мен – настоях за правно основание за отказа, тъй като Законът за електронно управление ги задължава да приемат заявлението и да изпълнят услугата. Казаха, че пак ще звъннат. Не звъннаха. Потърсихме ги отново, като в отговор потвърдиха, че не – няма да издадат така книжката.

Подадохме сигнал до Държавна агенция „Електронно управление“, аргументирайки се, че мълчаливият (към онзи момент) отказ противоречи на Закона за електронното управление.

Отговорът на ДАЕУ беше да се съгласят мотивите от изричния отказ на МВР, получен няколко дни след това. А той е абсурден. Според Закона за българските лични документи, МВР предоставя електронни услуги за лични документи през централизирана система за услуги. В правилния за прилагане на закона се изреждат услугите, включени в портала. Но издаване на шофьорска книжка липсва (тъй като към онзи момент не се поддържа). Да, Законът за електронното управление казва следното:

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

Обаче МВР казва „нашият подзаконов акт дерогира (отменя) закона, защото нашият специален закон делегира детайлите на нашия подзаконов акт, а той не казва нищо за тая конкретна услуга“. Абсурдна теза, граничеща с тази на РИК Стара Загора при отказа за вписване на листата на Демократична България, но останал несанкциониран.

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

  • Неудобно е – след като се оправиш с неудобния и „чуплив“ квалифициран електронен подпис, трябва да търсиш бланки (които ги няма там, където трябва – в административния регистър)
  • „Не може по електронен път“ – администрацията си търси всякакви абсурдни оправдания за да „им дойдеш“ на гише, както са си свиканли
  • Няма контрол – ДАЕУ като че ли беше уплашено, че няма политическата подкрепа да напише акт на МВР и да им издаде задължително предписание да спазват закона, макар че има такива правомощия

Само първият от тези проблеми е технически. Останалите са организационни и политически. И ще трябва да бъдат решени.

Материалът Представителна история за една шофьорска книжка е публикуван за пръв път на БЛОГодаря.

Законодателен акт за цифровите пазари – общ подход на Съвета на ЕС

от Нели Огнянова
лиценз CC BY

 

Според прессъобщение от 25 ноември 2021 Съветът на ЕС прие позицията си („общ подход“) относно предложението за Законодателен акт за цифровите пазари (DMA) . Предложението има за цел да осигури конкурентен и справедлив цифров сектор с оглед насърчаване на иновациите, висококачествени цифрови продукти и услуги, справедливи цени и високо качество и избор. 

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

С това предложение министрите се стремят да създадат равни условия в цифровия сектор с ясни права и задължения за големите онлайн платформи. Регулирането на цифровия пазар на ниво ЕС трябва да  осигури равни условия и конкурентен и справедлив цифров сектор.

Предложението за DMA е насочено към вратарите, които контролират „услугите на основната платформа“.  Основните платформени услуги включват: онлайн посреднически услуги, онлайн търсачки, социални мрежи, облачни услуги, рекламни услуги и др.

Основните промени в първоначалното предложение на Комисията са следните:

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

Общият подход, постигнат на Съвета на ЕС,   предоставя на председателството на Съвета на ЕС мандат за по-нататъшни дискусии с Европейския парламент, които са насрочени за 2022 г.

Законодателен акт за цифровите услуги – общ подход на Съвета на ЕС

от Нели Огнянова
лиценз CC BY

 

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

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

Основните промени спрямо  първоначалното предложение  на Комисията са следните:

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

Общият подход, постигнат на заседанието на Съвета (ноември 2021), допълва позицията за преговори, договорена вече от Съвета, и предоставя на председателството на Съвета мандат за по-нататъшни дискусии с Европейския парламент, които са насрочени за 2022 г.