01 февруари 2015

Електронно банкиране с Firefox 34+



След upgrade на Firefox започнах да имам проблем с електроннота банкиране при ПИБ. Оказа се, че от Firefox версия 34 нататък, са премахнали window.crypto.signText функцията в резултат, на което не могат да се подписват платежни нареждания. Детайли за мотивите около премахването могат да се прочетат тук, а решение на проблемът е, чрез инсталиране на signTextJS плъгина от тук.

20 декември 2014

Честита национализация

След промените в пенсионното осигуряване, гласувани вчера, може спокойно да се приеме, че вторият стълб за осигуряване е зачеркнат. Твърденията, че това се прави заради хората и им се дава право на избор, са меко казано смешни и само наивници биха им се вързали. На практика, това което е прието, че парите отиват в НОИ, но имаш право да си ги запазиш във фонда. Само че предвид кратките срокове за упражняване на това „право“, то има цена и то доста висока. В моя случай, разходите, които ще трябва да направя биха ми излезнали колкото годишната доходност. За хората, които се намират в чужбина по една или друга причина през това време, упражняването на това право, ще стане икономически неизгодно. За мен тази поправка и на това разчита, че доста от хората или няма да са заинтересовани или няма да могат да упражнят „правото“ си на избор. За сметка на това, прехвърлянето на голяма сума пари от фондовете към НОИ, доста ще натисне цените на активите, определено ще прецака хората, които остават във втория стълб. Разбира се, то ще даде възможност на хора с доста финансов ресурс, да направят добри пари. Мисля, че това обяснява и защо се бърза толкова с тази поправка и се прави в нарушение на всякакви административни и морални правила. Ясно е КОЙ покрай далаверата с КТБ гушна едни пари и сега иска да ги мултиплицира, а пък на ГЕРБ им трябва финансов ресурс в бюджета, чрез който пък да могат да се похвалят какво са направили, както и да облажат някои обръчи.

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

17 януари 2013

ГЕРБ срещу майките 2

Предложението на Бойко Борисов към майките, осветено с малко повече детайли в тази статия на Дневник, е добра илюстрация за това, че демографията не е сред приоритетите на ГЕРБ. Ако трябва да говорим с цифри, офертата е всички майки да получават по-малко пари за майчинство, без да има нищо в замяна (детските градини не се строят с пари на НОИ, а вноските към НОИ не се променят). Най-малко засегнати са майките, които почти не са работили или си осигуряват на минимума. За целият период на майчинството ще получат грубо 1000 лева по-малко. Най-силно засегнати са майките осигуряващи се на максималния осигурителен доход. За тях офертата е да получат с около 6000 лева по-малко. Всички останали са между тези две граници. Майките, взимащи около средната за страната заплата, ще получат около 3000 лева по-малко.

Ако ГЕРБ смятат да намаляват периода на майчинските, то трябва да го правят за сметка на увеличаване на периода за изплащане на обезщетения близки до заплатата, както и да намалят периода, който се използва за пресмятане на размера на обезщетението. Последното е особено важно, ако искат да стимулират раждането на повече от едно дете. В момента има казуси, как майчинските за второто дете за 2-3 пъти по-ниски от майчинските за първото дете, без майката да си е сменяла работата или да има сериозни промени в заплатата.

31 декември 2012

Проблеми със сигурността на Microinvest Warehouse Open

Във Microinvest Warehouse Open има проблем със сигурността, който на няколко пъти съм повдигал. За мое съжаление, хората от Microinvest го неглижират. С настоящия си постинг бих искал да дам публичност на проблема, така че от една страна хората, които ползват продукта да преценят до колко той отговаря на техните разбирания за сигурност, а от друга да стимулирам хората от Microinvest да го отстранят.

Microinvest Warehouse Open, както и повечето складово счетоводни програми, принадлежат към класа програми, предоставящи интерфейс върху някаква база данни. С други думи казано съхранението, манипулирането и управлението на данните се извършва от някаква СУБД (в случая на Warehouse Open това е MySQL), а приложният софтуер ни предоставя по-удобен начин да се случва това (не ни се налага да пишем директно сложни SQL команди). Когато се налага да  се реализират някакви правила за достъп и промяна на данните сме изправени пред следната дилема – дали да ползваме функционалностите предоставени от СУБД или да направим нещо върху нея (ако е възможно), което да е реализирано в приложния софтуер.

Всяка себе уважаваща се СУБД предлага доста гъвкавост при управление на достъпа до данните. В повечето случаи не е трудно да се ограничи достъпа на потребителя до конкретна база данни, таблица, колони или редове в таблица, както и операциите, които може да прави върху дадени данни (да ги изтрива, променя по специфичен начин и т.н.). Имайки това в предвид, някак си съвсем естествено идва потребителите на приложния софтуер, да са потребители на СУБД. Разбира се, това може да наложи да се направят множество специфични изгледи на таблици или използването на stored procedures. Съответно, това усложнява структурата на базата данни и може би коства повече усилия да се реализира.

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

  • Данните за идентифициране пред СУБД трябва да се пазят в тайна. Разбиването на паролата на този единствен потребител, компрометира най-малко данните на използваното приложение. В същото време тази информация трябва да съхранява някъде, така че когато някой потребител иска да влезе в приложението, то да може да се закачи до СУБД.
  • Ефективно всеки потребител на приложението има повече права, от колкото биха му били нужни за да си върши работата. Това от своя страна означава, че много по-лесно може да се използват грешки на самото приложение (sql injections, грешки в модела/интерфейса направата за достъп и т.н.).
  • При злонамерени опити за прихващане на комуникациите между приложението и СУБД, чисто статистически най-вероятно е да има успех при потребителите, които най-често ползват приложението. Обикновено тези потребители (от бизнес гледна точка) не би трябвало да имат значителни права за работа върху данните. Така че компрометирането на техните account-и, не би трябвало да нанесе сериозни щети, ако управлението на сигурността на данните на приложението се извършва от СУБД. Когато самото приложение има грижата да управлява правата за достъп, то рискът от компрометиране на системата е значително по-висок.
Подходът за реализиране на системата за сигурност в приложния софтуер се ползва най-често в web базираните приложения. Като цяло крайният потребител има достъп единствено до интерфейса на приложението, така че възможностите му да прочете файла, в който приложението съхранява информацията за достъп до СУБД или да предприеме атаки върху комуникацията между СУБД и приложението са значително ограничени. Съответно негативните ефекти от реализирането на този подход са силно смекчени.

За съжаление това не е така при stand-alone приложенията. Ако чрез инструментите на операционната система би могло да се ограничат възможностите за атака (от компютъра на който работи приложението) на комуникацията между приложния софтуер и СУБД, то не е толкова лесно да се ограничи достъпа до файла, който съхранява информацията за достъп до СУБД. Като цяло затвореният софтуер разчита на security through obscurity подхода. Информацията се пази криптирана и се разчита, че само приложението знае алгоритъма и ключа който се използва за декриптирането и. Разбира се, този подход не работи при приложенията с отворен код, тъй като всеки би могъл до види използвания алгоритъм и ключ. За мое най-голямо учудване Microinvest Warehouse Open използва именно този подход.

Лесно може да видите информацията касаеща връзката до СУБД чрез:
cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep Db

Криптираната парола за достъп до MySQL се съхранява във value полето на DbPassword реда. Бърз поглед върху изходния код на Warehouse Open ни дава информация за използвания алгоритъм и ключ. Имайки тази информация, лесно може да видим паролата чрез тази команда:
cat  ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep DbPassword | cut -f4 -d'"' | openssl enc -des-cbc -a -d -K 4d6963726f696e76 -iv 1234567890abcdef; echo

Мисля, че не е необходимо да обяснявам какви биха могли да бъдат последствията, ако паролата за достъп стане известна на злонамерен човек. Ако при инсталирането на Warehouse Open е използван административен потребител на MySQL, то рискът се пренася и върху другите приложения, които използват същия MySQL сървър.

Като цяло докато този проблем не бъде разрешен, не може да се разчита на правата за достъп на Warehouse Open. Съвсем тривиално е всеки да се сдобие с каквито права за достъп иска. Разбира се, това не добавя кой знае какъв допълнителен риск, ако всичко (приложен софтуер и СУБД) се върти на една машина, до която злонамерения потребител има физически достъп. В такава ситуация, макар и една идея по-трудно, могат да се случат доста неприятни неща. За съжаление, този проблем компрометира ситуации, в които машината, на която е разположена СУБД е добре физически и мрежово защитена.

30 декември 2012

RD Suite - край на играта

Последните 2-3 години не ми остава много време за RD Suite. Факторите за това са много и по всичко личи ще нещата ще изглеждат по същия начин и през следващите 2-3 години. За съжаление не можах да създам общност около проекта, така че няма кой да го движи, когато аз нямам възможност (разбира се, вината около това е изцяло моя). В тоя ред на мисли, смятам, че след 6 годишно публично съществуване е най-добре официално да сложа край на проекта. Ако някой все пак е решил да го продължи, мога да му прехвърля каквото сметне за необходимо. Хостингът е платен до средата на 2013.

Тези, които ползват в момента софтуера, могат при нужда да ми пишат. Далеч съм от мисълта да ги оставям да се оправят сами. Не изключвам възможността след 3 или 4 години да има remake (макар и под ново име). Разбира се, за да се случи това, проектът трябва да ми е основен източник на доходи, което означава, че и фокусът му ще е по-различен.