Passkeys и WebAuthn – пълно ръководство за автентикация без парола през 2026

Какво са Passkeys?

Passkeys са най-значимата промяна в уеб автентикацията от изобретяването на паролата. Изградени върху стандартите FIDO2 и WebAuthn, passkeys заменят традиционните пароли с криптографски двойки ключове, защитени от биометричния сензор на устройството — четец за пръстови отпечатъци, разпознаване на лице или PIN на устройството. Никога не пишете парола, никога не помните парола и никога не предавате тайна по мрежата.

Когато потребител се регистрира с passkey, устройството му генерира двойка публичен-частен ключ. Публичният ключ се изпраща до сървъра и се съхранява към акаунта на потребителя. Частният ключ остава на устройството, заключен зад биометрията или PIN. По време на вход сървърът издава криптографско предизвикателство; устройството го подписва с частния ключ (след биометрично потвърждение), а сървърът верифицира подписа със съхранения публичен ключ. Ако подписът съвпада, потребителят е автентикиран. Целият процес отнема около две секунди и не изисква когнитивно усилие отвъд докосването на пръстов отпечатък или поглед към камерата.

До 2026 г. Google, Apple и Microsoft са направили passkeys първокласна функция на платформите си. iCloud Keychain синхронизира passkeys между всички Apple устройства. Google Password Manager ги синхронизира между Android и Chrome. Windows Hello съхранява и използва passkeys нативно. Резултатът е изживяване за автентикация без парола, което е едновременно по-сигурно и по-удобно от всяка система, базирана на пароли.

Проблемите с паролите

За да оцените защо passkeys имат значение, разгледайте системните слабости на автентикацията, базирана на пароли:

Фишинг

Фишингът остава вектор на атака номер едно. Убедителен имейл насочва потребителя към фалшива страница за вход. Потребителят въвежда данните си, които се прихващат от атакуващия. Никакво количество обучение на потребителите не е елиминирало този риск; докато потребителят може да въведе парола на фалшив домейн, фишингът работи.

Credential Stuffing

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

Слаби пароли

Въпреки десетилетия насоки, потребителите продължават да избират предвидими пароли. „123456", „password" и „qwerty" оглавяват списъка с най-често използвани пароли всяка година. Дори мениджърите на пароли, макар ефективни, имат степен на приемане под 30% сред общото население.

Умора от пароли

Средният потребител поддържа акаунти в над 100 услуги. Запомнянето на уникални, сложни пароли за всяка е нереалистично. Това води до преизползване, несигурно съхранение (бележки, лепящи се бележки) и чести нулирания на пароли — които самите те често могат да бъдат експлоатирани чрез превземане на имейл акаунт.

Двуфакторна автентикация (2FA) помага, но...

TOTP кодовете (Google Authenticator) и SMS OTP добавят втори слой, но не са устойчиви на фишинг. Фишинг проксита в реално време могат да прихванат и паролата, и OTP кода, докато потребителят ги въвежда. Хардуерните ключове за сигурност (YubiKey) решават това, но имат ниско приемане сред потребителите поради цена и неудобство.

Passkeys адресират всички тези проблеми едновременно. Те са устойчиви на фишинг по дизайн, няма какво да се преизползва, няма какво да се помни и няма какво да се прихване.

Как работят Passkeys — техническата основа

Криптография с публичен ключ

Passkeys са изградени върху асиметрична криптография. Устройството генерира двойка ключове:

• Частен ключ — съхраняван сигурно в хардуерно обезпеченото хранилище на устройството (Secure Enclave при Apple устройства, TPM при Windows, StrongBox при Android). Той никога не напуска устройството.
• Публичен ключ — изпраща се до разчитащата страна (сървъра на уебсайта ви) и се съхранява в записа на потребителския акаунт.

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

Обвързване с произход (Origin Binding)

Всеки passkey е обвързан с конкретен origin (напр. https://example.com). Браузърът няма да позволи passkey, създаден за example.com, да бъде използван в examp1e.com (фишинг домейн). Това се прилага на ниво протокол, което прави невъзможно фишинг сайтовете да изискват удостоверения, които не им принадлежат — независимо колко убедителна изглежда фалшивата страница.

Потребителска верификация

Преди подписване на предизвикателството устройството изисква потребителска верификация — биометрична проверка (пръстов отпечатък, лице) или PIN на устройството. Това гарантира, че притежаването на устройството само по себе си не е достатъчно; легитимният потребител трябва също да присъства. Функционално е еквивалентно на двуфакторна автентикация (нещо, което имате + нещо, което сте) в един жест.

WebAuthn API обяснен

WebAuthn (Web Authentication API) е стандартът от страна на браузъра, който позволява passkeys. Той предоставя два основни метода:

Регистрация (създаване на Passkey)

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(serverChallenge),
    rp: {
      name: 'Моят уебсайт',
      id: 'example.com',
    },
    user: {
      id: new Uint8Array(userId),
      name: '[email protected]',
      displayName: 'Иван Иванов',
    },
    pubKeyCredParams: [
      { alg: -7, type: 'public-key' },   // ES256
      { alg: -257, type: 'public-key' },  // RS256
    ],
    authenticatorSelection: {
      authenticatorAttachment: 'platform',
      residentKey: 'required',
      userVerification: 'required',
    },
    timeout: 60000,
  },
});

// Изпратете credential.response до сървъра за верификация и съхранение

Браузърът подканва потребителя да верифицира самоличността си (напр. Touch ID). При успех връща PublicKeyCredential, съдържащ публичния ключ и атестационен обект, който сървърът може да верифицира.

Автентикация (използване на Passkey)

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(serverChallenge),
    rpId: 'example.com',
    allowCredentials: [],  // празен за discoverable credentials (passkeys)
    userVerification: 'required',
    timeout: 60000,
  },
});

// Изпратете assertion.response до сървъра за верификация на подписа

С discoverable credentials (по подразбиране за passkeys) масивът allowCredentials е празен. Браузърът или платформата представят списък с налични passkeys за дадения origin и потребителят избира един. Това позволява истински поток за вход без потребителско име — потребителят не трябва да въвежда нищо.

Стандартът FIDO2

FIDO2 е обединяващият стандарт, който комбинира WebAuthn (браузърното API) и CTAP2 (Client to Authenticator Protocol, за външни автентикатори като ключове за сигурност). Заедно те дефинират пълния поток на автентикация:

1. Разчитащата страна (вашият сървър) генерира предизвикателство и изпраща опции за регистрация/автентикация до клиента.
2. Браузърът (чрез WebAuthn) комуникира с автентикатора (платформена биометрия или външен ключ за сигурност) чрез CTAP2.
3. Автентикаторът създава или използва удостоверение, подписва предизвикателството и връща резултата.
4. Браузърът изпраща отговора до сървъра, който верифицира подписа и завършва операцията.

FIDO Alliance — чиито членове включват Google, Apple, Microsoft, Amazon, Meta и Visa — управлява стандарта. До 2026 г. FIDO2 съответствието е де факто изискване за всяка система за автентикация, която претендира за съвременна сигурност.

Passkeys срещу пароли срещу 2FA

| Характеристика | Пароли | Пароли + TOTP | Пароли + SMS OTP | Passkeys | |---|---|---|---|---| | Устойчивост на фишинг | Не | Не | Не | Да | | Риск от преизползване | Висок | Висок | Висок | Няма | | Риск при пробив на данни | Хеш на парола изтича | Хеш на парола изтича | Хеш на парола изтича | Съхранява се само публичен ключ | | Усилие от потребителя | Високо (запомняне/въвеждане) | По-високо (въвеждане + код) | По-високо (въвеждане + чакане за SMS) | Минимално (биометрично докосване) | | Възстановяване на акаунт | Нулиране по имейл (експлоатируемо) | Резервни кодове | Нулиране по имейл | Платформена синхронизация + възстановяване | | Риск от brute-force | Зависи от силата на паролата | По-нисък (времево ограничен код) | По-нисък (ограничена честота) | Няма (асиметрична криптография) |

Passkeys са превъзходни във всяко измерение на сигурността. Единствената област, в която паролите все още имат предимство, е универсалност — наследени системи и по-стари устройства може да не поддържат WebAuthn. Тази пропаст обаче бързо се затваря.

Поддръжка от браузъри и устройства

Към началото на 2026 г. поддръжката на passkeys е практически универсална сред съвременните платформи:

• Chrome (десктоп и Android) — пълна поддръжка от версия 108.
• Safari (macOS и iOS) — пълна поддръжка от iOS 16 и macOS Ventura.
• Edge — пълна поддръжка чрез Windows Hello.
• Firefox — пълна поддръжка от версия 122.
• Android — Google Password Manager синхронизира passkeys между всички Android устройства.
• iOS/iPadOS — iCloud Keychain синхронизира passkeys между Apple устройства.
• Windows — Windows Hello съхранява passkeys в TPM.

Автентикацията между устройства също е стандартизирана: ако трябва да влезете на устройство, което няма вашия passkey, можете да сканирате QR код с телефона си. Телефонът доказва притежаването на passkey чрез Bluetooth близост, и десктоп браузърът завършва автентикацията.

Ръководство за имплементация

Сървърна настройка

Сървърът ви трябва да обработва две операции: регистрация и автентикация. Използвайте утвърдена FIDO2 библиотека, вместо да имплементирате криптографската верификация сами.

Node.js — използвайте SimpleWebAuthn:

npm install @simplewebauthn/server @simplewebauthn/browser

Ендпойнт за регистрация:

import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
} from '@simplewebauthn/server';

app.post('/api/auth/register/options', async (req, res) => {
  const user = await getUser(req.session.userId);

  const options = await generateRegistrationOptions({
    rpName: 'Моят уебсайт',
    rpID: 'example.com',
    userID: user.id,
    userName: user.email,
    userDisplayName: user.name,
    attestationType: 'none',
    authenticatorSelection: {
      residentKey: 'required',
      userVerification: 'required',
    },
  });

  req.session.currentChallenge = options.challenge;
  res.json(options);
});

app.post('/api/auth/register/verify', async (req, res) => {
  const verification = await verifyRegistrationResponse({
    response: req.body,
    expectedChallenge: req.session.currentChallenge,
    expectedOrigin: 'https://example.com',
    expectedRPID: 'example.com',
  });

  if (verification.verified) {
    await saveCredential(req.session.userId, verification.registrationInfo);
    res.json({ verified: true });
  }
});

Ендпойнт за автентикация:

import {
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';

app.post('/api/auth/login/options', async (req, res) => {
  const options = await generateAuthenticationOptions({
    rpID: 'example.com',
    userVerification: 'required',
  });

  req.session.currentChallenge = options.challenge;
  res.json(options);
});

app.post('/api/auth/login/verify', async (req, res) => {
  const credential = await findCredentialById(req.body.id);

  const verification = await verifyAuthenticationResponse({
    response: req.body,
    expectedChallenge: req.session.currentChallenge,
    expectedOrigin: 'https://example.com',
    expectedRPID: 'example.com',
    authenticator: credential,
  });

  if (verification.verified) {
    req.session.userId = credential.userId;
    await updateSignCount(credential.id, verification.authenticationInfo.newSignCount);
    res.json({ verified: true });
  }
});

Клиентска интеграция

import {
  startRegistration,
  startAuthentication,
} from '@simplewebauthn/browser';

async function registerPasskey() {
  const optionsRes = await fetch('/api/auth/register/options', { method: 'POST' });
  const options = await optionsRes.json();

  const credential = await startRegistration(options);

  const verifyRes = await fetch('/api/auth/register/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(credential),
  });

  const result = await verifyRes.json();
  if (result.verified) {
    alert('Passkey регистриран успешно!');
  }
}

async function loginWithPasskey() {
  const optionsRes = await fetch('/api/auth/login/options', { method: 'POST' });
  const options = await optionsRes.json();

  const assertion = await startAuthentication(options);

  const verifyRes = await fetch('/api/auth/login/verify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(assertion),
  });

  const result = await verifyRes.json();
  if (result.verified) {
    window.location.href = '/dashboard';
  }
}

Схема на базата данни

Съхранявайте удостоверенията заедно с потребителските акаунти:

CREATE TABLE passkey_credentials (
  id TEXT PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  public_key BYTEA NOT NULL,
  counter BIGINT NOT NULL DEFAULT 0,
  device_type TEXT,
  backed_up BOOLEAN DEFAULT FALSE,
  transports TEXT[],
  created_at TIMESTAMPTZ DEFAULT NOW()
);

UX съображения

Потребителското изживяване на passkeys е едно от най-големите им предимства, но лошата имплементация може да подкопае приемането.

Поток за регистрация

• Предложете регистрация на passkey след като потребителят се е автентикирал чрез съществуващ метод (парола, OAuth). Не налагайте passkey-only регистрация от първия ден.
• Използвайте ясен език: „Създайте passkey" с кратко обяснение като „Влизайте с пръстов отпечатък или лице — без парола."
• Покажете потвърждение за успех с визуално представяне на използваната биометрия (икона на пръстов отпечатък, икона на Face ID).

Поток за вход

• Осигурете видим бутон „Влезте с passkey" наред с традиционния вход.
• За връщащи се потребители с passkey, автоматично задействайте подканата за passkey (чрез conditional UI / autofill), така че да не се налага да кликват нищо.
• Винаги предлагайте резервен вариант (парола, magic link, OAuth) за потребители, които все още не са регистрирали passkey или са на устройство без синхронизираните си удостоверения.

Управление на Passkeys

• Позволете на потребителите да преглеждат и изтриват регистрираните си passkeys в настройките на акаунта.
• Показвайте информация за устройството (име, дата на последно използване), за да могат потребителите да идентифицират кои passkeys са техни.
• Позволете на потребителите да регистрират множество passkeys (напр. един на телефона, един на лаптопа, един като хардуерен ключ за резервно копие).

Ползи за сигурността

Устойчивост на фишинг

Частният ключ е обвързан с origin. Дори ако потребител посети перфектно копие на сайта ви на фишинг домейн, браузърът няма да намери съвпадащо удостоверение. Фишингът става технически невъзможен за акаунти, защитени с passkey.

Никакви тайни на сървъра

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

Без преизползване на удостоверения

Всеки passkey е уникален за конкретен origin и потребител. Няма споделена тайна, която да бъде тествана в други уебсайтове. Credential stuffing става невъзможен.

Защита от replay атаки

Всяка автентикация включва уникално предизвикателство от сървъра и брояч на подписи, който се увеличава с всяко използване. Повторното възпроизвеждане на прихванат автентикационен отговор ще се провали, защото предизвикателството е изтекло и броячът е напреднал.

Защита от социално инженерство

Няма какво потребителят да „каже" на атакуващ. Няма парола за прочитане по телефона, няма OTP за споделяне в чат. Автентикацията е физическа (биометрия + притежание на устройство) и не може да бъде комуникирана устно или чрез текст.

Миграция от пароли към Passkeys

Преходът на потребителска база от пароли към passkeys е постепенен процес:

Фаза 1 — Предложете Passkeys като опция

Добавете регистрация на passkey в страницата с настройки на акаунта. Промотирайте с банери и подканвания в приложението. Потребители, регистрирали passkeys, могат да използват и двата метода за вход.

Фаза 2 — Passkey-First вход

За потребители, регистрирали passkey, показвайте подканата за passkey първо. Полето за парола е налично, но деакцентирано. Проследявайте метрики за приемане: какъв процент от входовете използват passkeys?

Фаза 3 — Passkey по предпочитание

Нови акаунти по подразбиране преминават към регистрация с passkey. Създаването на парола все още е налично за потребители, които откажат. Имейл маркетингът насърчава съществуващите потребители да регистрират passkey.

Фаза 4 — Задължителен Passkey (по избор)

За приложения с висока сигурност (банкиране, здравеопазване, корпоративни), изисквайте passkey автентикация и премахнете входа с парола изцяло. Предложете регистрация на хардуерен ключ за сигурност като резервен вариант за потребители, чиито устройства не поддържат синхронизирани passkeys.

Този поетапен подход гарантира, че никой потребител не е изключен, докато екосистемата узрява.

Реално приемане

Google

Google внедри поддръжка на passkeys за всички Google акаунти през 2023 г. До 2026 г. входовете с passkey са надвишили входовете с парола по обем. Google съобщава, че автентикацията с passkey е 40% по-бърза от парола + 2FA и е намалила компрометирането на акаунти, свързано с фишинг, с над 90%.

Apple

Apple интегрира passkeys в iCloud Keychain с iOS 16. Всяко Apple устройство — iPhone, iPad, Mac — може да създава и синхронизира passkeys автоматично. Autofill интерфейсът на Safari показва passkeys като основна опция за вход в поддържани сайтове.

Microsoft

Windows Hello поддържа passkeys от Windows 11 23H2. Microsoft акаунти, Azure AD и Microsoft 365 — всички приемат passkeys. Компанията агресивно оттегля автентикацията само с парола за корпоративни акаунти.

GitHub

GitHub активира вход с passkey през 2023 г. и оттогава го е направил препоръчителния метод за автентикация за разработчици. Комбинирано с политиката им за задължителна 2FA, passkeys осигуряват най-силната налична защита на акаунти в платформата.

Електронна търговия и банкиране

Основни платформи за електронна търговия (Amazon, магазини на Shopify) и банки (HSBC, ING) са приели passkeys за намаляване на триенето при checkout и за покриване на регулаторни изисквания за сигурност. Вход с passkey при checkout може да увеличи конверсиите, като намали отпадането, причинено от забравени пароли.

Бъдещето на автентикацията

Няколко тенденции оформят пейзажа на автентикацията отвъд 2026 г.:

• Крива на приемане на passkeys — индустриалните прогнози предполагат, че до 2028 г. passkeys ще бъдат основният метод за вход за над 50% от потребителския уеб трафик.
• Подобрения между устройства — Bluetooth верификацията на близост ще стане по-бърза и надеждна, правейки потоците чрез QR код безпроблемни.
• Корпоративна SSO интеграция — доставчиците на идентичност (Okta, Auth0, Microsoft Entra) добавят нативна поддръжка на passkeys към SSO потоците си, позволявайки вход без парола за всички корпоративни приложения.
• Регулаторен тласък — PSD3 в Европа и актуализираните насоки на NIST в САЩ се насочват към препоръчване на автентикация, устойчива на фишинг, което на практика подкрепя passkeys.
• Доставчици на удостоверения — мениджъри на пароли от трети страни (1Password, Bitwarden, Dashlane) вече съхраняват и синхронизират passkeys, разширявайки покритието отвъд нативните за платформата решения.

Паролата все още не е мъртва, но заместникът й е тук, доказан и се мащабира бързо. За всеки нов уеб проект, стартиран през 2026 г., поддръжката на passkeys трябва да бъде част от стратегията за автентикация от първия ден.

Заключение

Passkeys и WebAuthn представляват фундаментално подобрение в начина, по който се автентикираме в уеба. Те елиминират фишинга, преизползването на удостоверения и умората от пароли в един единствен, удобен за потребителя жест. Техническата основа е солидна (криптография с публичен ключ, обвързване с origin, биометрична верификация), инструментите са зрели (SimpleWebAuthn, платформени автентикатори), и поддръжката от екосистемата е универсална (Google, Apple, Microsoft, всички основни браузъри).

Ако изграждате ново приложение, имплементирайте passkeys от самото начало. Ако поддържате съществуващо, започнете пътя на миграция днес. Потребителите ви ще бъдат по-сигурни, екипът ви за поддръжка ще обработва по-малко тикети за „забравена парола", а конверсиите при вход ще се подобрят.

Имате нужда от помощ? Свържете се с нас.