Може би излишно, ако знаете точно как работят паролите и удостоверяването… но може би интересно за някои:
Тази нова идея се основава на същите концепции като ключовете за достъп (лични ключове, свързани с домейн и сигурно съхранени в TPM или Secure Enclave), но основната разлика е в домейна на приложението. Можете да използвате пароли, за да влезете – с други думи: „Хей уебсайт, искам да вляза, това е моят публичен ключ, който записах в
Но какво всъщност означава това, да сте влезли в системата? Всъщност не е нищо повече или по-малко от това, че вашият браузър изпраща токен с всяка заявка, която получавате от сървъра, след като той определи, че вашите идентификационни данни наистина са валидни. След това браузърът трябва да запомни някъде този токен. Това е мястото, където днес се използват бисквитки (или понякога локално хранилище в браузъра, в случай на едностранични приложения). Ако някой има достъп до файлове на вашия твърд диск, той може сам да чете и използва тази бисквитка. Ето защо други коментатори говорят за заобикаляне на двуфакторно удостоверяване.
Преди това можеше да се направи и чрез инжектиране на злонамерен JavaScript в уебсайт (междусайтови скриптови атаки), тъй като браузърът не правеше разлика между „Това е бисквитка с токен, който е полезен само за сървъра“ и „Това е бисквитка с токен Представено Полезно само за сървъра „Бисквитка с локално съхранена информация“. В днешно време можете да използвате флага „HttpOnly“, за да посочите, че бисквитката може да не е изложена на JavaScript… Може да се гадае дали всички разработчици правят това правилно Вярно, но всеки разработчик, загрижен за сигурността, ще приложи това.
Това, което прави това предложение, всъщност е да разшири концепциите зад ключовете за достъп до токени за сесии. Ако разбирам правилно (и ако съм прав, вие сте прочели само статията на T.net, но не и източника все още), той няма да съхранява токен, а генерира двойка публичен/частен ключ и изпраща публичния ключ към сървъра. Вместо да изпраща заглавка на бисквитка, той криптографски подписва всяка заявка с този публичен ключ, така че сървърът може да потвърди заявката със свързания частен ключ, че заявката действително идва от вас.
За разлика от паролите, тези DBSC ключове също са свързани с една система и не трябва да можете да ги премествате на други устройства. Ако искате да влезете на друго устройство, трябва да предоставите идентификационните си данни (потребителско име, парола, 2fa, ключ за достъп) отново и ще получите нова сесия.
[Reactie gewijzigd door multiplexer op 3 april 2024 12:18]
„Удобен за хипстър органайзер. Мислител. Комуникатор. Печелен с награди уеб нинджа. Типичен геймър. Зъл гуру на зомбитата. Фен на бирата.“