search

martin-nohava / kryzbu

Kryptograficky zabezpečené úložiště 🔒
MIT License
1 stars 0 forks source link

Návrh autentizace uživatele (diagram) #1

Closed martin-nohava closed 2 years ago

martin-nohava commented 2 years ago

Je zapotřebí navrhnout proces autentizace uživatele, strany, protokol, kryptografické prostředky apod.

Implementace dílčích částí:

implementováno v c9af47f58aaae014f7b13a1de07a33c24399b9e6

implementováno v f14304f5b13310ee93bd2ba440e16d4409c6728a

implementováno v 6558093fc8cd87c4b6bee99d9720b1d783d2a474

implementováno v 0d2efe08672e800bd212d9dbc0435954f2717887 (origin/login-beta)

částečně implementováno v dc05c6a4008d9670051b0f3b55d1d9cdd6e47750 (origin/login-beta) pro [LIST_DIR, UPLOAD, GETKEY, LOGIN]

Bloc3k commented 2 years ago

Hlavně to chce udělat do přehledného výstižného diagramu. Bude se moct rovnou použít ve studii a dokumentaci. Diagramy budou dva, jeden pro symetrickou a druhý pro asymetrickou kryptografii.

Asymetrickou navrhují udělat tak že si klient požádá o autentizaci inicializační zprávou která bude obsahovat i identifikaci konkrétního uživatele který žádá o autentizaci. Server pošle nonce, ten klient podepíše soukromím klíčem a pošle zpět. Server pak ověří podpis veřejným klíčem. Tím je klient autentizován a může se vytvořit session s daným klientem. To ještě nevím jak bych dělal.

Symetrickou verzi nějak podobně jen budou muset mít predsdileny sym. klíč a nonce se nebude podepisovat ale šifrovat. Server pokud dokáže dešifrovat zprávu obsahující serverem zaslané nonce tak ví ze muselo být zašifrováno odpovídajícím klíčem, tedy klient vlastní tajemství. Autentizace úspěšná => vytvoření session.

martin-nohava commented 2 years ago

Návrh č. 1

V tomto návrhu jsem se snažil především zaměřit na reálné použití, aby nebylo potřeba přepisovat například hash hesla do serveru a nebo dělat podobné nepraktické kroky, které by při reálném nasazení programu byly velmi uživatelsky nepřívětivé.

Popis:

1) Inicializace serveru – vytvoření páru veřejný a privátní klíč serveru RSA 2) Registrace uživatele administrátorem na serveru – zadání jména a hesla, vytvoří se automaticky hash hesla a symetrický klíč pro AES. Vše se uloží do databáze. 3) Žádost o rsa.pub – klient požádá server o veřejný klíč pokud jej nemá 4) Přihlášení uživatele – zašle žádost o ser-nonce (username, usr-nonce), šifruje pomoci veřejného klíče serveru. Server odpoví s (ser-nonce, usr-nonce) šifrováný pomocí uloženého uživatelského hesla. Klient dvojici rozšifruje pomocí hesla zadaného uživatelem do konzole klienta a pomoci veřejného klíče serveru opět zašifruje a odešle. Server ověří správnost ser-nonce a zpátky zašle klíč pro AES uložený v databázi pro daného uživatele, šifruje opět jeho heslem a přidává key-nonce pro jedinečnost každé zprávy. Od této chvíle má klient i server klíč pro symetrické šifrování, které jak autentizuje uživatele tak šifruje přenášená data.

Nalezená slabá místa

Bloc3k commented 2 years ago

Vypadá dobře. Jen mě trochu trápí, se nebude ten klíč pro sym. kryptografii měnit a bude furt stejný. Mohly bychom tam přidat nějaké promíchávání se solí nebo s těma nonce.

martin-nohava commented 2 years ago

To by jsme mohli vyřešit solením no. Klíč bych neměnil.

martin-nohava commented 2 years ago

Tento typ autentizace byl kompletně implementován v lehce modifikované podobě commitem 7796098c6e9c24334ce19909ce3b08cf24d8458e. (Modifikace: Žádost šifrovaná dle diagramu [Komunikace] + přenášena přes TLS spojení. Datová část komunikace šifrována již pouze pomocí TLS.)

Pro další úpravy systému autentizace a optimalizace budou otevřeny samostatné Issues.