15%

Спести 15% на всички хостинг услуги

Тествай уменията си и получи Отстъпка за всеки хостинг план

Използвайте код:

Skills
За начало
14.10.2024

Как да определим силата на паролата: Техническо ръководство за ентропия, устойчивост срещу разбиване и сигурно управление на идентификационни данни

Силата на паролата е количествена мярка за това колко устойчива е тя срещу неоторизирано разкриване чрез brute-force атаки, речникови атаки, credential stuffing и статистическо отгатване. Тя се определя от три взаимно усилващи се променливи: дължина, разнообразие на символното пространство и непредвидимост (ентропия). Парола, която отбелязва над 60 бита ентропия на Shannon и съдържа поне 16 знака, взети от смесен набор от символи, се счита за криптографски силна според настоящите стандарти NIST SP 800-63B.

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

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

Силата на паролата е заместител на цената на атаката — по-конкретно, броят на предположенията, които противникът трябва да направи, преди да намери правилните идентификационни данни. Тази цена се изразява в битове ентропия по формулата:

H = L × log₂(N)

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

По-висока стойност на ентропията означава експоненциално повече работа по отгатване. Разликата между 40 бита и 80 бита не е двойно по-трудна — тя е 2^40 пъти по-трудна, което се равнява на приблизително един трилион допълнителни предположения.

Пулът от символи и неговото влияние върху ентропията

Набор от символиРазмер на пула (N)Ентропия на символ
Само малки букви (a–z)264.70 бита
Малки + главни букви525.70 бита
Буквено-цифрови (a–z, A–Z, 0–9)625.95 бита
Пълен печатаем ASCII (със символи)956.57 бита
Diceware парола (EFF голям списък)7,776 думи12.92 бита на дума

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

Ключови фактори, определящи силата на паролата

Дължина на паролата

Дължината е единствената най-въздействаща променлива във формулата за ентропия. Удвояването на дължината на паролата повдига на квадрат пространството за търсене при фиксиран пул от символи. Разгледайте контраста:

  • 8-знакова парола с пълен печатаем ASCII: H = 8 × 6.57 = ~52.6 bits
  • 16-знакова парола с използване на същия набор от символи: H = 16 × 6.57 = ~105 bits

При 52.6 бита, съвременните GPU-ускорени системи за разбиване на пароли, работещи с Hashcat върху MD5 хешове, могат да изчерпят пространството за часове. При 105 бита, същият хардуер би изисквал геоложки времеви мащаби. NIST SP 800-63B препоръчва минимум от 8 знака за пароли, избрани от потребителя, но администраторите, съзнаващи сигурността, трябва да налагат минимум от 12–16 знака, без изкуствена горна граница.

Разнообразие на символите и сложност

Смесването на класове символи разширява N и следователно увеличава ентропията на символ. Силната парола трябва да съдържа:

  • Главни букви (A–Z)
  • Малки букви (a–z)
  • Цифри (0–9)
  • Специални символи (!, @, #, $, %, ^, &, *, и др.)

Въпреки това, критичен нюанс, който много ръководства пропускат: задължителните правила за сложност могат парадоксално да отслабят паролите. Когато потребителите са принудени да включат символ, те предсказуемо добавят ! или 1 в края на дума. Този модел е добре известен на разбивачите на пароли и е кодиран в наборите от правила, използвани от инструменти като Hashcat. Истинската сложност идва от случайността, а не от изпълнението на изискване.

Непредвидимост и устойчивост срещу атаки на базата на шаблони

Съвременното разбиване на пароли не е чисто brute-force. Инструменти като Hashcat и John the Ripper използват атаки на базата на правила, които прилагат трансформации към речникови думи — изписване с главна буква на първата буква, заместване на a с @, добавяне на години и т.н. Парола като P@ssw0rd!23 изглежда сложна, но се разбива тривиално, защото следва добре известен модел на заместване.

Истинската непредвидимост означава:

  • Без речникови думи, дори с leetspeak замествания
  • Без клавиатурни последователности (qwerty, zxcvbn)
  • Без лична информация (имена, дати на раждане, имена на домашни любимци)
  • Без предвидими шаблони в началото или края (! суфикс, 1 префикс)

Най-надеждният източник на непредвидимост е криптографски сигурен генератор на случайни числа (CSPRNG), който реномираните мениджъри на пароли използват вътрешно.

Уникалност между акаунтите

Повторното използване на идентификационни данни превръща едно единствено пробиване в системен компромис. Когато услуга, съхраняваща пароли в обикновен текст или слаб MD5, бъде пробита, атакуващите незабавно изпробват тези идентификационни данни срещу други ценни цели — техника, наречена credential stuffing. Услуги като Gmail, банкови портали и контролни панели за хостинг са основни цели.

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

Методи за оценка на силата на паролата

Изчисляване на ентропията

Формулата за ентропия H = L × log₂(N) е най-обективната мярка. Ето референтни стойности за практическа оценка:

Пример за паролаДължинаПул от символиЕнтропия (битове)Устойчивост
`password`826~37.6Незначителна
`P@ssw0rd`895~52.6Часове (GPU)
`Tr0ub4dor&3`1195~72.3Месеци
`correct-horse-battery-staple`2826+1~130+Векове
Произволни 16 знака пълен ASCII1695~105Астрономична

Обърнете внимание, че correct-horse-battery-staple — известната XKCD парола — постига изключителна ентропия чрез дължина, въпреки че използва само малки букви и тирета. Това е силата на дължината над сложността.

Инструменти за разбиване на пароли, използвани от специалисти по сигурността

Инженерите по сигурността и тестерите за проникване използват следните инструменти за емпирично тестване на политиките за пароли:

Hashcat е стандартният за индустрията GPU-ускорен инструмент за възстановяване на пароли. Той поддържа над 300 типа хешове и може да изпълнява речникови, brute-force, базирани на правила и хибридни атаки. На съвременен RTX 4090, Hashcat може да тества приблизително 164 милиарда MD5 хеша в секунда — контекст, който прави горните числа за ентропия осезаемо реални.

John the Ripper е базиран на CPU разбивач с мощни възможности за атаки на базата на правила и широка поддръжка на формати на хешове. Той се използва широко в съдебни и одиторски контексти.

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

За тестване на хеш на парола офлайн с Hashcat в режим на бенчмарк:

hashcat -b -m 0

За изпълнение на речникова атака с правила срещу файл с MD5 хешове:

hashcat -a 0 -m 0 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Онлайн инструменти за тестване на пароли

Няколко базирани на браузър инструмента осигуряват бърза оценка на силата:

  • Have I Been Pwned (HIBP) Password Check — проверява SHA-1 хеш префикса на паролата срещу база данни с над 800 милиона пробити пароли, използвайки модел на k-анонимност, което означава, че пълната парола никога не се предава.
  • Bitwarden Password Strength Tester — използва zxcvbn под капака за реалистична оценка на времето за разбиване.
  • Kaspersky Password Checker — предоставя анализ на дължина, сложност и шаблони.

Критично оперативно предупреждение: Никога не въвеждайте реална, използвана парола в какъвто и да е онлайн инструмент. Използвайте структурно подобни, но различни тестови идентификационни данни. Дори инструменти, използващи модели на k-анонимност, не трябва да получават вашите реални производствени пароли.

Измерители на силата на паролата в приложенията

Вградените измерители на силата варират значително по качество. Много използват опростени евристики (прагове за дължина, наличие на класове символи), които могат да бъдат заобиколени. Измерител, който оценява P@ssw0rd1! като „Силна”, е подвеждащ — този низ се появява в всеки основен речник на пробити пароли. Предпочитайте приложения, които интегрират zxcvbn или еквивалентни оценители, отчитащи шаблони.

Вектори на атаки срещу пароли: Срещу какво всъщност се защитавате

Разбирането на модела на заплахата изостря всяко решение относно политиката за пароли.

Brute-force атаките систематично изпробват всяка възможна комбинация в рамките на символно пространство. Те са изчислително ограничени и стават непрактични над ~80 бита ентропия с текущия хардуер.

Речниковите атаки използват списъци с думи, получени от реални пароли, изтекли при пробиви. Наборът от данни RockYou (14 милиона пароли) и неговите наследници покриват огромното мнозинство от пароли, избрани от хора. Ако паролата ви се появява в естествен език, тя е в речник.

Атаките на базата на правила прилагат правила за трансформация към речникови думи — изписване с главна буква, добавяне на числа, заместване на символи. Те разбиват мнозинството от „сложни” пароли, които потребителите конструират чрез модифициране на прости думи.

Credential stuffing използва двойки потребителско име/парола от едно пробиване за атака срещу други услуги. Това се предотвратява изцяло чрез уникалност на паролата.

Атаките с rainbow таблици използват предварително изчислени съответствия хеш-към-обикновен текст. Те се предотвратяват чрез правилно хеширане на пароли с уникална сол (bcrypt, Argon2, scrypt) от страна на сървъра — отговорност на приложението, а не на потребителя.

Социалното инженерство и фишингът заобикалят изцяло силата на паролата. Многофакторното удостоверяване е основната защита тук.

Най-добри практики за създаване и управление на силни пароли

Използвайте мениджър на пароли

Мениджърът на пароли е единственото подобрение на сигурността с най-висок ефект, достъпно за повечето потребители и администратори. Инструменти като Bitwarden (с отворен код, одитиран), 1Password и KeePassXC (офлайн, локално съхранение) генерират криптографски случайни пароли и ги съхраняват в криптирано хранилище. Това елиминира когнитивната тежест на запаметяването и прави уникалните, произволни пароли от 20+ знака практични за всеки акаунт.

За системни администратори, управляващи идентификационни данни на сървъри — включително среди за VPS Хостинг и Dedicated сървъри — ориентиран към екипи мениджър на пароли с контрол на достъпа на базата на роли (като Bitwarden Teams или HashiCorp Vault) е от съществена инфраструктура.

Генерирайте пароли с CSPRNG

Никога не конструирайте пароли ръчно. Използвайте генератора на вашия мениджър на пароли или на Linux/macOS:

# Generate a 20-character random password using /dev/urandom
LC_ALL=C tr -dc 'A-Za-z0-9!@#$%^&*()-_=+' < /dev/urandom | head -c 20; echo
# Generate a Diceware-style passphrase using OpenSSL
openssl rand -base64 32

Внедрете многофакторно удостоверяване (MFA)

MFA е задължителен слой за всеки акаунт със значителна стойност. Дори компрометирана парола не може да предостави достъп без втория фактор. Предпочитайте TOTP приложения за удостоверяване (Authy, Google Authenticator, Aegis) пред SMS-базирано 2FA, което е уязвимо към SIM-swapping атаки. За среди с най-висока степен на сигурност използвайте хардуерни ключове за сигурност (YubiKey, FIDO2), които са устойчиви на фишинг по дизайн.

На сървъри, изпълняващи уеб приложения или контролни панели — включително среди, управлявани чрез VPS контролни панели — налагайте MFA на ниво приложение и обмислете SSH удостоверяване на базата на ключове като заместител на SSH вход с парола изцяло.

Налагайте силни политики за пароли на системно ниво

За администратори, управляващи Linux сървъри, PAM (Pluggable Authentication Modules) осигурява детайлно налагане на политики за пароли. Инсталирайте и конфигурирайте libpam-pwquality:

apt install libpam-pwquality

След това редактирайте /etc/security/pwquality.conf:

minlen = 16
minclass = 3
maxrepeat = 2
gecoscheck = 1
dictcheck = 1

Това налага минимална дължина от 16 знака, изисква символи от поне 3 класа, забранява повече от 2 последователни идентични символа и проверява срещу речникови думи и GECOS полето на потребителя (име).

За политика за остаряване на паролите редактирайте /etc/login.defs:

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   14

Наблюдавайте за пробиви на идентификационни данни

Интегрирайте наблюдението за пробиви в операциите си по сигурността. Have I Been Pwned предлага безплатен API за проверка на имейл адреси срещу известни бази данни за пробиви. За организационна употреба, услуги като SpyCloud или Enzoic осигуряват наблюдение на идентификационни данни в реално време и могат да задействат принудително нулиране на паролата, когато идентификационните данни на служител се появят в набор от данни за пробив.

Сигурно хеширане на пароли от страна на сървъра

Ако управлявате уеб приложения, съхраняващи потребителски идентификационни данни — независимо дали на Споделен уеб хостинг или в dedicated среда — никога не съхранявайте пароли в обикновен текст или със слаби алгоритми за хеширане (MD5, SHA-1, несолен SHA-256). Използвайте специализирана функция за хеширане на пароли:

  • Argon2id — победител в Password Hashing Competition; препоръчан от OWASP за нови приложения
  • bcrypt — широко поддържан, изпитан в битки; използвайте работен фактор 12 или по-висок
  • scrypt — интензивен по памет; добра устойчивост срещу GPU-базирани атаки

Пример с използване на библиотеката argon2-cffi на Python:

from argon2 import PasswordHasher

ph = PasswordHasher(time_cost=2, memory_cost=65536, parallelism=2)
hash = ph.hash("user_supplied_password")
# Verify:
ph.verify(hash, "user_supplied_password")

Паролни фрази като практична алтернатива

За пароли, които трябва да бъдат запомнени (главна парола на мениджъра на пароли, ключ за пълно дисково криптиране), Diceware парола предлага най-добрия баланс между ентропия и запомняемост. Хвърлете физически зар пет пъти, за да изберете всяка дума от EFF Large Wordlist. Пет думи дават приблизително 64.6 бита ентропия; шест думи дават 77.5 бита.

Example: "clam-unmasked-revival-stunt-dagger"
Entropy: ~64.6 bits (5 words × 12.92 bits)

Това е по-силно от повечето „сложни” пароли, избрани от потребители, и много по-лесно за запомняне.

Защита на идентификационните данни в цялата хостинг инфраструктура

Сигурността на паролите се простира отвъд отделните акаунти до целия стек на инфраструктурата. Администраторите, управляващи хостинг среди, трябва да прилагат многопластови контроли на идентификационните данни:

  • SSH достъп: Деактивирайте изцяло удостоверяването с парола; използвайте Ed25519 или RSA-4096 двойки ключове. Съхранявайте частните ключове с силна парола.
  • Идентификационни данни за база данни: Използвайте дълги, произволно генерирани пароли за потребители на база данни. Никога не използвайте root акаунти на база данни за връзки с приложения.
  • Акаунти на контролен панел: Налагайте силни пароли и MFA за всички входове в контролния панел. Платформи, достъпни чрез VPS с cPanel, трябва да имат наложено минимално ниво на силата на паролата в cPanel от 65.
  • Имейл акаунти: Слабите имейл пароли са основен вектор на атака за превземане на акаунти. Ако управлявате Имейл хостинг, налагайте силни политики за пароли на ниво пощенски сървър и активирайте DMARC, DKIM и SPF за намаляване на излагането на фишинг.
  • SSL/TLS частни ключове: Защитавайте частните ключове, свързани със SSL сертификати, с разрешения на файловата система (chmod 600) и, където е възможно, ги съхранявайте в хардуерен модул за сигурност (HSM) или мениджър на тайни.

Сила на паролата срещу политика за пароли: Сравнение

ИзмерениеОтговорност на потребителяОтговорност на администратора
Генериране на паролаИзползвайте мениджър на базата на CSPRNGНалагайте минимални изисквания за ентропия
СъхранениеКриптирано хранилище (мениджър на пароли)Argon2id/bcrypt с уникални соли
Предотвратяване на повторна употребаУникална парола за всеки акаунтНалагайте чрез PAM параметър `remember`
Откриване на пробивиНаблюдавайте HIBPИнтегрирайте API за пробиви в потока за удостоверяване
MFAАктивирайте за всички акаунтиНалагайте на ниво приложение/сървър
РотацияСменяйте при съмнение за компромисЗадайте изтичане, управлявано от политика (90–180 дни)
SSH достъпИзползвайте двойки ключовеДеактивирайте `PasswordAuthentication yes` в `sshd_config`

Матрица за решения и ключови технически изводи

Използвайте този контролен списък за оценка и укрепване на текущата ви позиция по отношение на паролите:

  • Целева ентропия: Стремете се към минимум от 80 бита за общи акаунти; 100+ бита за привилегирован достъп (root на сървъра, главна парола на мениджъра на пароли, ключове за криптиране).
  • Минимална дължина: Никога не приемайте пароли по-кратки от 12 знака в никоя система, която контролирате; предпочитайте 16–20 за потребителски акаунти, 32+ за служебни акаунти и API ключове.
  • Пул от символи: Използвайте пълен печатаем ASCII за произволно генерирани пароли; използвайте Diceware за запомнени паролни фрази.
  • Уникалност: Нулева толерантност към повторна употреба на идентификационни данни. Внедрете мениджър на пароли, за да направите това оперативно осъществимо.
  • Алгоритъм за хеширане: Argon2id е текущият златен стандарт за съхранение на пароли от страна на сървъра. Мигрирайте от bcrypt само ако Argon2id е наличен в стека ви.
  • MFA слой: TOTP минимум; FIDO2/WebAuthn за привилегировани и административни акаунти.
  • Укрепване на SSH: Деактивирайте SSH вход с парола на всички сървъри. Използвайте PasswordAuthentication no в /etc/ssh/sshd_config.
  • Наблюдение за пробиви: Абонирайте се за HIBP известия за всички организационни имейл домейни.
  • Честота на одит: Изпълнявайте одити на пароли срещу собствената си база данни с хешове, използвайки Hashcat на тримесечие, за да идентифицирате слаби идентификационни данни преди атакуващите.
  • Налагане на политика: Използвайте PAM pwquality на Linux системи; налагайте еквивалентни контроли на Windows чрез Group Policy (Fine-Grained Password Policies).

Често задавани въпроси

Каква е минималната дължина на паролата, препоръчана от NIST през 2024 г.?

NIST SP 800-63B задава абсолютния минимум на 8 знака за пароли, избрани от потребителя, но изрично препоръчва верификаторите да позволяват пароли с дължина до поне 64 знака. Специалистите по сигурността трябва да налагат практически минимум от 12–16 знака и да насърчават паролни фрази от 20+ знака за чувствителни акаунти.

По-силна ли е 12-знакова парола със символи от 20-знакова парола само с малки букви?

Не непременно. Произволно генерирана 20-знакова парола само с малки букви има приблизително 94 бита ентропия (20 × 4.70), докато 12-знакова парола с пълен ASCII има приблизително 78.8 бита (12 × 6.57). По-дългата парола печели по ентропия въпреки използването на по-малък пул от символи — дължината се натрупва по-бързо от разнообразието на символите.

Каква е разликата между речникова атака и brute-force атака?

Brute-force атаката изпробва систематично всяка възможна комбинация от символи в рамките на дефинирано пространство — тя е изчерпателна, но изчислително ограничена. Речниковата атака използва курирани списъци с думи от реални пароли, изтекли при пробиви, общи думи и известни шаблони. Речниковите атаки разбиват огромното мнозинство от пароли, избрани от хора, за секунди; brute-force е запазен за кратки пароли, при които пълното пространство за търсене е осъществимо.

Трябва ли редовно да сменям паролите си, дори ако няма пробив?

Текущите насоки на NIST (SP 800-63B) изрично препоръчват срещу задължителна периодична ротация на паролите без доказателства за компромис, тъй като принудителната ротация кара потребителите да правят предвидими, постепенни промени (напр. Password1 към Password2). Сменяйте паролите незабавно при потвърден или предполагаем пробив и ротирайте идентификационните данни на служебните акаунти по определен график (90–180 дни) като практика за управление на риска.

Как да проверя дали паролата ми вече е изложена при пробив на данни, без да я изпращам на сървър на трета страна?

Използвайте Have I Been Pwned Pwned Passwords API с неговата имплементация на k-анонимност. Вашият клиент изчислява SHA-1 хеша на паролата, изпраща само първите 5 знака от този хеш към API и получава обратно всички съответстващи суфикси на хешове. Пълният хеш — и следователно паролата — никога не напуска вашата машина. Това може да бъде скриптирано директно:

PASSWORD="YourTestPassword"
HASH=$(echo -n "$PASSWORD" | sha1sum | awk '{print toupper($1)}')
PREFIX="${HASH:0:5}"
SUFFIX="${HASH:5}"
curl -s "https://api.pwnedpasswords.com/range/$PREFIX" | grep "$SUFFIX"

Ако командата върне резултат, паролата е видяна при пробив и не трябва да се използва.

15%

Спести 15% на всички хостинг услуги

Тествай уменията си и получи Отстъпка за всеки хостинг план

Използвайте код:

Skills
За начало