В началото на годината обнових интерактивната графика с умиранията и смъртността от всички причини за последните 12 години. Добавих филтрите за 2022-ра. След запитване от колега добавих и линейна графика в допълнение към кръговата. Филтрите показват същите една до друга.
Графиките от последните две години остават непроменени: 2020 и 2021. Припомням, че тези данни показват само в абсолютни стойности, както и спрямо населението. Сравнението дори в рамките на България и за период от 10 години води до изкривявания заради променящата се възрастова структура. Затова ви съветвам да прегледате текста ми за това как може правилно да сравняваме този показател през годините и между държави. Преди време бях оборил и мита, че в България се умира едва ли не най-много.
Причината, разбира се, да се обръща внимание на тези данни, е пандемията на коронавирус. Има доста объркване какво показват данните за смъртността, митове за причините за увеличението и разликата между огромното превишение и доказаните случаи на починали от COVID19.
От горните данни смесени с тези публикувани редовно в отворен формат от здравните власти, може да видим интересни разминавания между заболеваемостта и смъртността от последната вълна. Обяснения за това бяха дадени доста, включително заради характерните особености на конкретния щам. Отново скрити в данните са обаче значително по-високата заболеваемост сред децата, последствията от които ще осъзнаваме тепърва.
Със същите данни може да сравним и процентът на доказано починалите от COVID19 спрямо починалите от всички причини, както и превишаването на общата смъртност от март 2020 спрямо средното за за дадената седмица от периода 2010-2019-та. Виждат се паралели и интересни разминавания, които бяха вече обяснени с разминаването в диагностиката при първата за България вълна, както и намалената смъртност най-вече през летните месеци заради по-малкото инфекциозни болести, катастрофи и други инциденти като цяло.
Не е практика за технически спецификации да се търси широко обществено обсъждане, но тъй като тази система е много важна, смятам, че е редно да дадем пример за прозрачност от първия ден. Още при номинирането ми за министър на електронното управление дадох това обещание и ще направя каквото е необходимо този екип продължава да дава този пример. Разчитам на професионалистите във всички области да дадат своята експертна и конструктивна обратна връзка и препоръки. Тази прозрачност ще продължи и на етапа на изпълнение (вкл. с изискването за отворен код на разработката).
Резултатът от проекта ще бъде мобилно приложение (за Android и iOS), с което да се идентифицираме за ползването на всички електронни услуги, т.е. държавата да знае кой стои отсреща, когато ползва услугите. До момента това се извършва с електронен подпис, с ПИК, с ПИН и др. Тези средства няма да отпаднат веднага, но малко по малко ще бъдат замествани с електронната идентификация.
След първоначалната регистрация, от гледна точка на потребителя, процесът ще бъде следния:
отваря портал за електронни услуги
избира „вход с eID“ и потвърждава с мобилния си телефон (или друго мобилно устройство)
подава заявления за услуги, които са с предварително попълнени данни (тъй като системата вече знае кой стои отсреща)
подписване на заявлението чрез повторно потвърждение с мобилния телефон
Проектът предвижда първа фаза за проекетиране, тъй като трябва да бъдат взети специфични технологични решения. Например дали потвърждението с телефона да стане с т.нар. push-нотификация или чрез сканиране на QR код от екрана (съответно с deep link, в случай, че потребителят използва мобилния телефон и за заявяване на услугата, вместо компютър). Трябва да бъде избран и методът за подписване, като целта е криптографските ключове да се разделят на няколко части, като една се съхранява в мобилния телефон, а друга – на сървъра (така че да се минимизират рискове от изтичане от едното от двете места).
Първоначалната регистрация е много важна за да може максимален брой хора да използват приложението. Затова предвиждаме първоначална регистрация по следните начини:
Квалифициран електронен подпис, в т.ч. облачен КЕП (чрез системата за електронна автентикация)
ПИК на НАП (отново през еАвт)
ПИК на НОИ (отново през еАвт)
международен паспорт, който разполага с чип, благодарение на който може да бъде идентифицирано лицето (чипът може да бъде прочетен с мобилен телефон)
снимане на лична карта
Към тези методи могат да бъдат добавени два компонента за повишаване на сигурността:
Отговор на въпроси, които държавата има, но не са публично достъпна информация (напр. във връзка с имена на роднини или данни за предходни постоянни адреси)
Т.нар. liveness detection, т.е. проверка чрез камерата на телефона дали отсреща действително стои лицето, което твърди, че стои (без да може да се използва негова снимка, за да „излъже“ системата). Това е стандартна практика в много приложения за онлайн идентификация
Всеки един от изброените механизми ще има съответното ниво на осигуреност („средно“ или „високо“), което ще дава достъп до различни услуги. Напр. само със сканирана лична карта (плюс отговори на въпроси/liveness detection), лицата няма да имат достъп до чувствителни данни, като здравното си досие. За да преминат от ниво на осигуреност „средно“ към „високо“ се предвижда опция за еднократно посещение на администрация или пощенски клон. Но дори с ниво „средно“ ще могат да се използват всички масови услуги. В бъдеще, когато чип се появи и в личната карта, той ще може да бъде използван за първоначална регистрация и то с ниво на осигуреност „високо“.
Ако човек няма мобилно устройство, той едва ли би ползвал електронни услуги. Има изключения от това твърдение, но те са твърде малко. В други държави се допуска идентификация с SMS код, но нивото на сигурност при този метод не е задоволително и преценихме, че няма нужда от такъв риск.
Докато се изгражда системата (в следващите няколко месеца), ще подготвим и нормативни изменения, за да може да функционира системата в съответствие със закона.
Освен самото приложение, в рамките на проекта ще бъдат пилотно надградени и системите на НАП, НОИ, МВР, както и портала за електронни услуги на Министерството на електронното управление, така че да има богат избор от услуги, които да бъдат използвани с новото средство за идентификация и подписване (подписването формално ще бъде чрез т.нар. „усъвършенстван електронен подпис“, което е допустимо за заявяване на услуги съгласно действащия Закон за електронното управление).
Смятам, че правилно се фокусирахме върху подготовката на този проект, за да можем да го стартираме в рамките на първите 100 дни от управлението.
Тази събота ще се проведе националната конференция на Да, България . След три поредни вота се натрупа страшна умора, но и доста въпроси и пътища напред, които трябва да намерят своето решение.
Имаше, разбира се, много нападки, конспирации и интриги завъртяни около партията. Някой бяха очаквани, други следваше да прозрем по-рано. Лесно се затъва в блатото на кой какво кога бил казал и достатъчно сме го правили в последната година. Ако съм имал някакви съмнения в начина на процедиране, в ръководенето на партията или в работата на националния съвет (НС), щях веднага да изляза и да спра да се занимавам. Казах го още в деня на учредяването на партията.
Всяко решение в Да, България се взима след обстойно обсъждане и гласуване на националният съвет и затова е важно какви хора има в него. Не съм бил съгласен с някои решения, но съм разбирал защо другите гласуват така. Това е същността на демократичния процес. Ако някой не е съгласен с една или друга политика, сътрудничество или компромис, като член на партията в събота е мястото са определи с какви хора и решения иска са се продължи напред.
Затова, ако сте членове на Да, България, ще съм благодарен, ако ме подкрепите като кандидат за НС. Уверен съм, че има с какво да помогна и допринеса. Позициите си съм описвал подробно в социалните мрежи и в блога ми през годините. Решенията по тях, както и самата политика, са процес, който трябва да бъде извървян. За целта трябва да седнем на масата, където се взимат решенията и стъпките, а не да гледаме и подвикваме отстрани.Всички кандидати и аргументи ще намерите на страницата на Да, България.
Microsoft Exchange has a bug that practically stops email. (The public sector is primarily using Exchange, so many of the institutions I’m responsible for as a minister, have their email “stuck”). The bug is described here, and fortunately, has a solution.
But let me say something simple and obvious: don’t reinvent date formats, please. When in doubt, use ISO 8601 or epoch millis (in UTC), or RFC 2822. Nothing else makes sense.
Certainly treating an int as a date is an abysmal idea (it doesn’t even save that much resources). 202201010000 is not a date format worth considering.
(As a side note, another advice – add automate tests for future timestamps. Sometiimes they catch odd behavior).
Не знам какво ме прихвана, но около Коледа и Нова година реших да изтупам праха от някои стари машини вкъщи. От много време вече работя все на лаптоп и настолна машина не бях пипал от доста години. Светко има в стаята си едно настолно HP, което нарочно бях избрал, за да е по-лесно за ъпгрейди, но няколко години вече не е видяло нова част, а пък и Линуксът му е стар. Деца на обущар…
Но понеже Оги получи за рождения си ден кашон с части за сглобяване на настолен компютър, след като го сглобихме, инсталирахме и настроихме, темата за настолните машини някак се завърна. Оги си избра Ubuntu 20.04 Focal Fossa – май основно заради “котката” на тапета. Всъщност фосата не е котка, а вид африканска цивета и има толкова общо с котките, колкото и, например, африканското диво куче или лисиците. Но тапетът е готин, а и си прилича на дива котка, няма какво да се лъжем.
Покрай всичко това реших да изровя старите машини. Старият ни компютър, който с Краси бяхме взели на части и сглобили, когато отидохме да живеем в Надежда навремето, бях дал на мама и татко с идеята да го ползват за музикална кутия. Вътре има много музика – копирана от мои дискове и изтеглена със свободни авторски права от интернет. Много класическа музика – тогава те искаха да могат да си слушат класика и аз бях подготвил стария “wishmaster” да им служи за това.
Дал съм им го някъде преди 10 години. Толкова не е бил включван. Сега, като го пуснах, при стартирането взе да си проверява файловата система, защото са били минали 3580 дни…
Музиката си е там, линуксът си върви, макар и вече стар. Но тати го няма, така и не са стигнали до това да си пускат музика от компютъра. Трябваше да им показвам и повече да им настоявам да го ползват.
Тази машина се казва “wishmaster”, заради Nightwish. Да, близо до ума е. Между другото, и името на блога ми е от същата песен. Сега се чудя дали да обновя софтуера ѝ – всичко е замръзнало някъде между 2009 и 2011. Комбинация от Debian Squeeze, когато още е бил Sid/unstable и Sidux.
Няма проблем да го обновя, аз с такива неща даже си почивам, но като се сетя, ми става тъжно. Гледам го като паметник на отминало време, сещам се за татко. За всичко, което сме си говорили, за трудностите накрая, за болестите, колко трудно му беше на него и колко мъчно ми беше на мен, че не мога да помогна повече и как нямах даже на кого да разкажа, освен вкъщи на Краси и децата. Сигурно ще ми мине с времето…
Другата машина, която пуснах, е един попаднал ми Уиндоус 10, който беше в ужасно състояние като инсталация и на практика работеше само в safe mode, но има интересни чаркове, които все още мога да използвам – видеокарта и т.н. След като Уиндоуса не успях да оправя (е, не си дадох и прекалено зор), приенсталирах. Но понеже или заради дъното, или заради флашката, не успях да заредя от usb, се наложи да изровя старите класьори с дискове. Не съм записвал CD/DVD от ужасно много време, и аз не помня откога. В един класьор, дето Краси ми го беше подарила, когато раборех в Енергото, намерих всичките дискове на Debian Woody (от когато излезе, значи от 2002г.) – е, тръгна, но не разпозна диска… то SATA по това време си е още лека екзотика.
Рових, рових и намерих едно Ubuntu 4.10 – всичко мина ОК, само дето не можа да пусне видеокартата и остана в текстов. Тя тая geforce-ка излиза бая години след това, как да я познае. Викам на децата, “ето, тоя диск е от 4 (месец април) 2010г. – явно тогава за последно съм записвал инсталационен диск”. И тагадък-тагадък – лека-полека надстройване до 6.06, после до 8.04, после до 10.04… Следва минаване към 64-битов (дискът беше 32) и евентуално към Debian. Чак взех да се чудя защо си губя времето, но пък след толкова години администриране на сървъри, ми е интересно.
И изведнъж ми просветва – не е било април 2010г., а октомври 2004г.! След това кой ще ти записва инсталационни дискове?
Най-веселото е, че всички тия линукси си работят достатъчно добре за нещата, за които смятам да ги ползвам (или за които съм ги ползвал и преди).
Има един още по-стар линукс, който наистина първо трябва да бъде почистен от прах и да видя дали изобщо се включва. А и не знам дали имам AT клавиатура.
Не искам да пазя стари вещи и да събирам прах вкъщи. Просто ми беше интересно да поровя в тези стари джаджи и да си спомня разни неща. После дойде новата година и вече трябва да гледам напред. Поздрави на всички за новата 2022 година, много здраве ви пожелавам! Другото ще си го купим, ако изобщо ни потрябва. ;)
Last week the Bulgarian National assembly appointed the new government. I am one of the appointed ministers – a minister for electronic governance.
The portfolio includes digitizing registers and processes in all government institutions, reducing bureaucracy, electronic identity, cybersecurity, digital skills and more.
Thanks to all my readers for following this blog throughout the years. I will be sharing some digital policy details here from now on while I’m minister. That may include some technical articles, but they are unlikely to be developer-oriented.
I hope to make some important changes and put forward key ideas for e-governance and digital policy that can be used as an example outside my country (last time I was involved in public policy, I helped pass an “open source law”).
I’ve written a few articles about IT people looking for challenges – not just technical challenges. And I think that’s a great challenge where I’ll have to put all my knowledge and skills to work for the common good.
В понеделник ще бъда предложен на Народното събрание за министър на електронното управление.
Отговорността и очакванията са огромни, а задачите – неизброими.
Ще започнем с електронната идентификация, с отпадането на удостоверения и с оптимизираме и електронизиране на ключови процеси. Ще трябва паралелно с това да създадем и министерство.
Целта е да премахнем бюрокрацията и да спестим време и нерви на гражданите и бизнеса.
Преди 6 години подтикнат от дискусия в Twitter изкарах статистика с анимирани графики за ключов аспект от демографската криза – все по-късната възраст, в която двойките решават да имат деца. По този показател въобще не сме на челните места в Европа. Всъщност, дори погледнато средно сме сред държавите с най-ниска средна възраст на родилките. Все пак отлагането на децата допринася значително за „разреждането“ на поколенията и намаляването на общата раждаемост.
В тази и предишната ми статия отново се съсредоточваме върху жените, най-вече защото за тях има най-точни данни. Този фокус обаче е в немалка степен погрешен. От една страна, жените в детеродна възраст изнасят на раменете си един изключително тежък процес докато в същото време се очаква да отговорят на всички останали обществени очаквания в икономически и социален смисъл. От друга, почти изцяло се пропуска ролята на мъжа в репродуктивното здраве, както и в процесите, които описвам по-долу.
Първото нещо попада в по-широкия дебат за равноправното участие в грижата за децата, бащинството, дискриминацията на работното място, достъпа до ясли и градини, социалната мрежа и сигурност в началото на кариерата и прочие. Тези теми засягат в огромна степен и решението за отлагане на децата и дават обяснение, защо все по-малко се решават на тази стъпка в началото на 20-те си години. Тук следва да включим и все още битуващата стигма и очакване за определена отговорност на жените и то в определена възраст. Решението е лично на всяка двойка и за такова винаги има разнообразни и лични причини. Следвайки общата статистика може само да наблюдаваме резултатите. В никакъв случай обаче не може да определяме конкретен тип решения или аспект от работната или социалната среда като първопричина. Може да се работи в посока стимули и решение на споменатите проблеми. Никой от тях обаче няма да помогне взет самостоятелно.
Вторият споменат аспект е много малко изследван и това не помага въобще на обсъждания проблем. Когато се говори за репродуктивни проблеми, всички обръщат внимание на жените и особено на късната възраст. Докато рисковете и трудностите несъмнено се повишават значително, почти изцяло се пропуска нашата роля на мъже в този процес. Репродуктивните проблеми при мъжете не са по-малко и имат също толкова негативни последствия. Отделно влошеното общо здраве, масовото пушене, липса на спорт и общо затлъстяване на не малка част от сънародниците ни задълбочава проблема. Битува обаче разбиране, че това няма значение и вината се прехвърля почти изцяло на жените. От там и съответно повечето данни и изследвания са с фокус именно върху последните.
С всичко това наум и ясно осъзнавайки, че ефективно продължавам този проблем, реших да обновя графиките с данните между 2000 и 2020 г. Повече подробности за графиките ще намерите в предишния ми текст. Тук ще гледам да мина през важните точки.
Първата графика показва кривата на възрастовото разпределение през годините. Малко трудно се чете и затова направих следващите графики. Вижда се обаче ясно изместване на кривите вдясно към по-големите възрасти. Вижда се също спиране и обръщане на намалението на родилките под 25 г., за което ще говорим после.
Тук се вижда промяната по възрастови групи спрямо 2000 г. Вижда се, че родилките над 30 години заемат много по-голям дял, нещо, което знаем. Децата родени от майки над 45 г. пък са се увеличили 10 пъти, като основното увеличение е било след 2014-та. Обяснението за последното са делата по онова време срещу фонда за асистирана репродукция относно дискриминативните им практики.
Следващата графика показва броя деца родени по възрастова група на майките. Забелязва се резкия спад на броя деца от жени под 25 г. и изместването към 30 и 35 годишните. За това разбираме и от средната възраст на майките като индикатор публикуван всяка година от НСИ. Тази анимация обаче показва динамиката на този процес.
Около 2010-та година нарастването на средната възраст се е дължало не на намалението на ражданията сред 20-годишните, а на увеличената раждаемост сред 35 годишните поради отлагане на деца в края на 90-те. 10 години по-късно обаче вече се вижда ясно изместване на общия профил на жените, а и двойките, които се решават на деца в посока на стандартното за Западна Европа.
Горната графика обаче показва броя деца в абсолютни стойности. В действителност възрастовият профил на жените в детеродна възраст се е променял значително през разглеждания период от 20 години. Повече за това по-нататък. Докато до тук разглеждахме раждания, следващата графика показва раждаемостта – т.е. брой деца на всеки 1000 жени.
Сега се вижда онова паралелно увеличение до 2010-та година при 35 годишните, за което говорих преди. След 2010-та обаче не се вижда вече изместване на профила на родилките. Т.е. жените през 2010-та под 25 г. са раждали почти толкова, колкото тези през 2020-та. Просто като общ брой са били по-малко. Вижда се дори увеличение при тези между 25 и 30 г.
Оказва се, че основната причина за повишаването на средната възраст на раждане не е до каква степен жените навлизащи в детеродна възраст и по-слабите им половинки са готови на деца, а решенията, които техните родители са взели през 90-те. Защото сегашните 20 до 30 годишни са именно тези родени между 1990 и 2000 г.
На следната графика виждаме в лилаво динамиката на броя жени от всяка възрастова група през годините между 2000 и 2020 г. Освен ниската и отложена раждаемост през 90-те, един голям фактор е емиграцията. Затова този път добавих приблизителна оценка какъв би бил броя им, ако изключим изцяло емиграцията. В оценката взимам населението през 60-те и прилагам същите индекси на раждаемост и смъртност, каквито са регистрирани през следващите 60 години.
Виждаме ясно отдалечаване на двете криви колкото повече време минава. Тази разлика отразява не само хората напуснали страната, но и децата им, които тепърва ще влизат в детеродна възраст. През 2010-та година разликата е била около 342 хиляди жени между 15 и 55 години. През 2020-та вече е 415 хиляди. Това е липса изцяло базирана на емиграцията.
Разбира се, тази оценка е доста груба и в нея прозират няколко дефекта. Основният е, че предполага същата раждаемост и смъртност при условия на „затворени граници“. Най-малкото икономическите и социалните ефекти от подобна мярка биха влошили значително и двата показателя. Отделно, че в актуалните данни се отчитат двойки, които са родили деца и за заминали заедно и такива, които са били в чужбина, но са е върнали и са имали деца преди или след прибирането.
Динамиката на населението не е нещо, което може да се обрисува с толкова прост механизъм като описания. Целта тук обаче е да даде приблизителна представа за ефектът, който намалената раждаемост през 90-те има над раждаемостта сега, както и че дори без емиграцията такова намаление щеше да се наблюдава, макар и с известно закъснение.
Един положителен сигнал, който виждаме в данните от последните години, е лекото увеличение на жените навлизащи в детеродна възраст. Вижда се от увеличението на броя момичета под 20 години. Това, разбира се, е ефектът от повишената раждаемост, която видяхме в началото на графиките горе. В същото време е твърде слаб и все още кратък сигнал, за да може да си правим изводи. Вълната на ефекта от 90-те ще има нужда от 40 години да отмине, през което време ще виждаме намаляваща раждаемост. Т.н. демографски преход тепърва започва.
Има две неща, които могат да го обърнат. За първото ще си говорим друг път. Второто е имиграцията и включва както така бленуваното и обещаваното от всеки следващ провъзгласил се за спасител връщане на някаква част от българите от чужбина, така и миграция от трети страни като южна Азия, съседните балкански страни или такива, с които България е имала добри контакти и обмен на студенти в миналото. С досегашната политика, публично говорене, действия към правата на човека и бездействие по ред други теми, което и от двете е трудно да си представим да се случи в мащаби, които ще променят сигнала нагоре.
Реших да обновя картата, която изготвих през юли. Тогава тя даваше представа за пътя на над 9400 души. Сега с последните заявления виждаме този на над 12 хиляди.
Наскоро отново стана дума дали съдържанието ѝ отговоря на GDPR и въобще дали се обработват някакви лични данни. Описал съм подробно алгоритъма в оригиналната статия от преди 5 години, когато картата имаше едва 1268 записа. В последната отбелязах отново важното.
В случая става дума за информация, която се публикува от ЦИК в рамките на специален закон. Доколко това е правилно съм оспорвал вече – едно е да разлепяш списъци пред секции, друго е да ги публикувал в електронен формат, както много общини правят. Има много по-добър начин ЦИК да осигури проверката на заявилите гласуване в чужбина спазвайки изискването за проверимост заложено в закона. Но са се спрели на чисто чиновническо решение. Отделно собственото им чиновническо мислене довежда до там да не спазват собствените си процедури и системи за сигурност и се стига до теч на лични данни, както този с ЕГН-тата на членовете на комисии зад граница. При заявленията за гласуване не говорим за теч на данни обаче, а нарочно публикуване.
Въпросът дали и как може да се обработват не е приложим при тази карта или инициативата Glasuvam.org като цяло, тъй като тук се борави със статистика върху публикуваната информация. Не се записват имената на хората, а анонимизирана информация с цел потвърждение на броя заявили желание по секции, потвърждение на собствените данни на ЦИК, както и промените и прехвърляне на заявления, които често правят в рамките на кампанията. В този смисъл анонимизираната информация не съдържа лични данни и не може да се използва за идентифициране на даден човек.
Всъщност, макар картата да не „проследява“ отделни активни българи в чужбина, подобно на картата за българчетата родени зад граница и статистиката, която извадих след това за тях, тя дава представа за общото движение на групи от хора. Така има повече естетическа стойност и „поглед отвисоко“, а не е инструмент за проследяване, както навярно би могло да се приеме буквално заглавието на първата ми статия.
В същото време, в интервюта и предишни текстове съм предупреждавал, че подобна обработка на големи масиви от данни без анонимизиране и всички мерки, които взимам години преди да се въведе GDPR, би могло да се проследяват по подобен начин хора. Разбира се, това е далеч по-трудно, непрактично и неточно, в сравнение с редовните течове на информация, особено такива включващи българите в чужбина. Такива са не само скорошния на ЦИК, но и този на НАП преди две години и този на Външно преди доста повече, когато изтекоха адресите в България и чужбина на подали заявление да гласуват зад граница. Истината е, че има прекалено много идентифицираща информация в частни и обществени структури, от които може да се сглоби притеснително точна картинка кои сме и какво правим. Това отдавна се използва като основа на бизнес модела на редица компании, някои за които дори не сме чували. Докато обръщаме много внимание на действията и проблемите в администрацията, истината е, че подобни „течове“ са редовна практика и всъщност същността на най-големите бизнеси, от които вече неизменно зависим.
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.
