Dotaz: Autentizace klíčem pro aplikaci klient - server (http) - jak na to?

[chin]

Dobré ráno. Mám webovou aplikaci a klienty napsané v javě, kteří s ní komunikují. Chci, aby se autentizovalo pomocí klíčů a ne hesel. Jak to udělat co nejbezpečněji? Napadá mě spousta alternativ jako:

1. Vygenerovat klíč a prohlásit ho za heslo - nejjednodušší, nicméně nejbezpečnější???
2. Vygenerovat klíč, server odešle náhodně vygenerovanou zprávu šifrovanou tímto klíčem, klient jí dešifruje a zpět zašle třeba její hash zašifrovaný tím samým klíčem. Server hash dešifruje, vytvoří hash z jím zaslané zprávy a porovná je. Složitější, ale neposílá se samotný klíč - bezpečnější???
3. To samé jako druhý bod, jen použít asymetrickou kryptografii, kdy server má veřejný klíč a klient privátní (plus klidně i naopak, pokud chci ověřit obě strany a nedůvěřuji CA u https).
4. ...

Klienti si s webovou aplikací vyměňují docela citlivé údaje a bude to celé komunikovat přes internet, takže by to mělo být podle toho bezpečné ...

Budu vděčný za jakýkoliv rozumný nápad, děkuji.

Odpovědi

[Sten]

TLS (HTTPS) podporuje autentizaci pomocí klientského certifikátu, návod např. zde

[Filip Jirsák]

Jak píše Sten, použijte standardní HTTPS s přihlášením klienta privátním klíčem. Na obou stranách nastavte rozumnou množinu povolených protokolů, inspirovat se můžete např. u Qualsys SSL Labs. Na klientovi ověřujte přímo konkrétní serverový certifikát (nebo jednu konkrétní autoritu, pokud jí důvěřujete a chcete to mít pohodlnější), na serveru ověřujte konkrétní certifikáty (nebo opět zvolte jednu nebo pár autorit, kterým budete důvěřovat).

[chin]

To mi přijde trochu moc komplikované - na straně klienta pracovat s keystore, na straně serveru přidávat do databáze informace o certifikátu, aby se jím šlo autentizovat i autorizovat a to celé cca jednou ročně (nebo mít vlastní CA) absolvovat pro větší množství klientů.

[Sten]

Přesně to odpovídá bodu 3. Pokud je klientů víc, jde ty certifikáty jednoduše ověřovat přes vlastní CA.

[Filip Jirsák]

Musíte si vybrat, buď jednoduchost, nebo bezpečnost. Stejně ta data předpokládám posíláte přes HTTPS, takže musíte řešit keystore na serveru a trustore na klientovi. Přidat k tomu autentizaci klienta certifikátem je pak relativně snadné.

[Šangala]

Nevím jestli je to rozumné, ale řešil jsem to páry klíčů, každý klient má svůj pár veřejný dá na server a veřejný serveru dostane.

Klient pošle požadavek, dostane „náhodnou zprávu“ šifrovanou svým veřejným klíčem, dešifruje ji a pošle zpět zašifrovanou veřejným server klíčem zpět a obdrží stejně šifrovaný ticket, který šifrovaný posílá s požadavky dokud server nevynutí změnu ticketu.

Všechna komunikace byla navíc podepisovaná „druhým klíčem“ (a doplněná o náhodná data) a umožňovala navíc zadání hesla, kde se navíc vyměňovala 2nd sůl, takže heslo běželo po síti zašifrované a navíc jen jako hash.

[Sten]

U té autorizace jste v podstatě implementoval to, co dělá TLS.

[Šangala]

No vida

[Lieselotte]

Problém imho je, že ten klient je potom ochoten rozšifrovat a zpětně zašifrovat veřejným klíčem serveru prakticky cokoliv, což není problém, pokud se privátní klíč používá _POUZE_ na tuto autorizaci. Pokud se ale používá i na něco jiného, alternativně jde klienta donutit, aby použil k dešifrování libovolný odpovídající privátní klíč, pak je to skutečně velký průšvih.