Etykieta na poświadczeniu nie wyznacza zakresu poświadczenia.

Kryptografia jest nie do przejścia. SRP-6a zgodny z RFC 5054, AES-256-GCM, porównania w stałym czasie, dowód wiedzy zerowej. 1Password zrobił kryptografię dobrze. Źle zrobił napis na puszce.

W tym miesiącu dwóch inżynierów z Token Security spędziło trzy dni na odwrotnym inżynierowaniu własnościowego protokołu uwierzytelniania SRP w 1Password. Nie szukali podatności. Próbowali zastąpić mostek SCIM klientem Pythona na potrzeby narzędzi do obsługi tożsamości maszynowych. Znaleźli rozbieżność między tym, co poświadczenie deklaruje, że może zrobić, a tym, co faktycznie może zrobić [1][2].

Token konta usługi ograniczony do jednego sejfu, z uprawnieniami do odczytu, potrafi wylistować każdego użytkownika w organizacji. Każdą grupę. Każde członkostwo w grupie. Każde uprawnienie na poziomie sejfu w każdym sejfie. Imiona, adresy e-mail, stany, znaczniki czasu ostatniego uwierzytelnienia. Etykieta tokena mówi „jeden sejf". API mówi coś innego [1].

1Password potwierdził. To zachowanie jest zamierzone. Szczegółowe ograniczanie zakresu znajduje się na mapie drogowej, bez podanej daty [2].

Do czego faktycznie sięga token

Gil Portnoy i Henry, pisząc dla Token Security, udokumentowali pięć punktów końcowych API, które token konta usługi „z jednego sejfu" obsługuje z pełnym powodzeniem [1]:

/api/v2/users zwraca każdego użytkownika w organizacji: UUID, imię i nazwisko, adres e-mail, stan, typ, znacznik czasu ostatniego uwierzytelnienia. /api/v1/groups zwraca każdą grupę wraz z jej uprawnieniami i stanem. Polecenia CLI dotyczące członkostwa w grupach, użytkowników i uprawnień sejfu oraz grup sejfu zwracają dane bieżące. /api/v3/account zwraca metadane konta. /api/v2/vault/{id}/vaultaccess zwraca informacje o dostępie do sejfu.

Żaden z tych punktów końcowych nie jest ograniczony do tego jednego sejfu, dla którego token został wydany. Tokenowi powiedziano: „odczytaj jeden sejf". API dało mu mapę całej organizacji [1].

Ostrzejszy punkt: enumeracja nie działa przez oficjalny SDK 1Password. Ta ścieżka zwraca UNSUPPORTED lub FORBIDDEN. Działa przez wewnętrzne API CLI, które badacze musieli odwrotnie inżynierować. „Zakres" jest ograniczeniem po stronie klienta, na poziomie SDK. Leżące u podstaw poświadczenie ma zasięg odczytu w całej organizacji. Atakujący nie korzysta z Pana SDK [1].

Badacze zbudowali klienta w około 420 liniach Pythona. Pięć punktów końcowych API. Pełna widoczność organizacji. Opracowanie opublikowali 16 lipca [1].

Zamek nie jest problemem. Problemem jest pęk kluczy.

Badacze są na tym punkcie ostrożni. Kryptografia jest rzeczywiście silna. Implementacja SRP wykorzystuje standaryzowany w RFC dowód wiedzy zerowej: serwer nigdy nie widzi hasła, klient nigdy nie widzi soli, a każda nieudana próba uwierzytelnienia zwraca ten sam komunikat błędu, więc atakujący nie dowiaduje się niczego. 1Password udokumentował własne odstępstwa od standardu (w tym fragment tekstu piosenki „Penny Lane" The Beatles ukryty w stałej kryptograficznej jako easter egg) i odstępstwa te są obojętne dla bezpieczeństwa [1].

Problemem nie jest zamek. Problemem jest to, co otwiera klucz. Kiedy poświadczenie jest opisane jako „ograniczone do jednego sejfu", administratorzy wydają je agentom, wierząc, że promień rażenia jest wąski. Agent dostaje poświadczenie. Poświadczenie dostaje schemat organizacyjny. Nikt tego nie zamierzał, ale nikt też nie widzi, jak to się dzieje [1].

Kiedy przekazuje Pan agentowi token „ograniczony", agent działa w granicach tego zakresu, który API faktycznie egzekwuje, a nie tego, który opisuje etykieta. Jeśli agent zostanie przejęty — przez wstrzyknięcie promptu, zatruty plik konwencji, atak na łańcuch dostaw lub którykolwiek z wektorów, których obrony oparte na tekście nie potrafią w pełni zamknąć — atakujący nie dostaje jednego sejfu. Dostaje topologię organizacyjną: kto należy do której grupy, kto ma dostęp do których sejfów, kiedy każda osoba uwierzytelniła się po raz ostatni. To faza rozpoznania w trakcie naruszenia, dostarczona jednym wywołaniem API [1].

Rozbieżność między zakresem udokumentowanym a zakresem rzeczywistym nie jest specyficzna dla 1Password. Każde API do zarządzania poświadczeniami podejmuje dorozumiane decyzje autoryzacyjne, których administratorzy nigdy nie widzą. Token Security udowodnił, że ta rozbieżność jest realna, mierzalna i możliwa do wykorzystania w weekend pracy z jednym hookiem Frida [1].

Sejf zbudowany z myślą o tym robi to inaczej

Zadaniem poświadczenia jest przetrwanie w świecie, w którym się znajduje. Jeśli „ograniczony" token potrafi po cichu odwzorować Pana organizację, ten zakres nigdy nie był realny. Był etykietą.

Clavitor nie opisuje poświadczeń i nie liczy na szczęście. Agent dostaje jedno poświadczenie z jawną nazwą, pobierane na żywo w chwili wywołania, wstrzykiwane do jednego żądania i znikające. Nie istnieje token pozostający w mocy, który atakujący mógłby wykorzystać ponownie. Nie istnieje punkt końcowy z mapą organizacji ukryty za etykietą zakresu, której nikt nie zweryfikował. Sejf nie udostępnia agentowi enumeracji. Agent sięga tam, do czego został nazwany, i nigdzie indziej.

Każdy dostęp jest rejestrowany na konkretnym agencie, który go wykonał, w sejfie, a nie na punkcie końcowym, na którym agent działa. Jeśli token zostanie przejęty, promień rażenia obejmuje zakres tego jednego wywołania, a nie topologię organizacyjną stojącą za nim.

Zasady stojące za sejfem, który egzekwuje zakres, zamiast go opisywać: Dziesięć zasad zarządzania poświadczeniami

Clavitor (@clavitorai) to sejf na poświadczenia zbudowany dla agentów AI — i przeciwko nim. clavitor.ai

Źródła

[1] Token Security (Gil Portnoy, Henry) — Odwrotne inżynierowanie własnościowego protokołu uwierzytelniania SRP w 1Password — @TheTokenSec

[2] @TheTokenSec — wątek na X dotyczący ustalenia rozszerzenia zakresu, 16 lipca 2026 — „1Password potwierdził, że jest to zachowanie zamierzone, mające na celu obsługę przepływów pracy związanych z zarządzaniem sejfami"