Уеб-разработка: работа с паролите

В допълнение към темата за добрите практики при работата със свободен софтуер. В частност — разработката на уеб-услуги. Често ви се е случвало интересът към даден сайт да ви бъде спрян от задължителна форма за регистрация, въвеждане на пароли и т.н. Много хора приемат всичко това за нормална даденост, но все пак поне веднъж сте се питали “защо ми искат изобщо регистрация тук”, нали?

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

Имаме ли нужда от пароли?

Въпросът звучи реторичен и като че ли подразбиращият се отговор е утвърдителен. Но нека помислим пак — имаме ли наистина нужда да искаме от потребителите си да ни дават парола за достъп до сайта? Този въпрос е може би основният за решаване при работата с пароли в разработката на страници. Може да го разделим на две части — “За какво са ни пароли?” и “Как ще ги съхраняваме?“. И двата въпроса могат да имат различни отговори, които изобщо не са “предопределени” от някаква уеб-тенденция за искане или неискане на пароли. Трябва да отговорим за конкретния сайт, по който работим и на двата въпроса, да намерим правилното им решение.

Водещо правило при обмислянето на тези два въпроса е “колкото по-малко, толкова по-добре”. Това означава, че подробното и излишно утежнено занимание с пароли изобщо няма да помага на сайта ни. А напротив — ще пречи, като затруднява писането, изпробването и поддръжката му. Пароли трябва да се ползват само и единствено ако са наистина нужни.

За какво са ни пароли?

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

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

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

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

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

Освен OpenID има и други системи за идентификация, като MicroID или Live ID на Майкрософт (известно преди като .NET Passport). Важно при избора на такава система е и дали е централизирана или разпределена. OpenID например е разпределена система, докато Live ID е централизирана и изцяло под контрола на Майкрософт. OpenID е с публикувана спецификация, докато Live ID е “walled garden”, затворена система на фирмата Майкрософт. MicroID пък е начин да се идентифицира дадена публикация в мрежата. Тоест тя не сработва като начин за “влизане” на потребителя в сайта, но веднъж идентифициран по друг начин (с OpenID или пък с парола), неговото съдържание в сайта може да бъде направено автоматично разпознаваемо с добавяне на MicroID-тагове.

Как ще съхраняваме паролите?

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

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

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

Във всеки случай паролите, независимо дали се пазят във файл, бил той и защитен по някакъв начин, например извън уеб-папките, или пък се пазят в SQL база от данни, трябва задължително да се замаскират — най-добре с шифриране. Това не е труден процес, всеки съвременен език за програмиране на уеб-страници позволява съвсем лесно да се работи с шифрирани пароли. Някои системи за сайтове (CMS, Wiki, blog и т.н.) поддържат вътрешно автоматично шифриране на паролите. Даже всички разпространени и развити готови системи (WordPress, Drupal, Mediawiki, Joomla, Mambo, PhpBB и безброй още други) идват с интегрирано шифриране на всички пароли.