4 komentářů k článku Autentizace v single-page aplikacích – serverová část:

  1. Petr Blahoš

    Overkill?
    Díky, za pěkný článek. Zajimalo by mě, jestli je to Vaše, nebo jestli jste čerpal z nějakého zdroje, protože bych se chtěl více dozvědět proč takhle. O bezpečnosti a kryptografii nevím skoro nic, takže promiňte blbé dotazy:
    * Opravdu pomůže mít tolik solí? Nestačila by jedna serverová (čili application-wide) a jedna per-user? Protože pokud je úkolem soli osolit to tak, aby nešel předpočítat slovník, tak se mi zdá, že jedna by mohla stačit. Navíc, v případě, že někdo ukradne db, tak získá všechny 3 per-user soli, a když někdo ukradne konfiguraci serveru, tak získá všechny 3 (4) serverové soli.
    * To odhlášení na všech zařízeních při změně hesla je geniální. Mě je ale trochu proti srsti posílat zpět heslo, ikdyž zahashované, takže prakticky nerozluštitelné, takže tato moje poznámka asi neobstojí. Ale neudělalo by stejnou službu, kdybychom při změně hesla vygenerovali novou náhodnou sůl pro uživatele?
    Předem děkuji za odpovědi.

    1. Michal Gebauer

      Re: Overkill?
      „Reálné“ odhady na dešifrování jakékoli hashovací fce a náhodného generátoru bych bral skepticky (viz. kauza Snowden, blbost vývojářů některých šifer a generátorů např. poslední průser u Cryptocat komunikátoru, současné možnosti bot netů, paralelizace pomocí OpenCL a CUDA atd.).

      Ve skutečnosti šifra(šifra(heslo + sůl) + jiná sůl) bude trvat dešifrování jen 2x déle. Navíc jedna ze solí je stejná pro všechny uložené hesla.
      Hypoteticky díky neúměrnosti délky soli (170 znaků) a hesla (většinou nepřesáhne 20) by zde mohlo dojít úniku informací o podobě soli i z výsledné šifry pokud bude šifrování šifra(šifra(heslo + sůl uživatele) + sůl serveru).

      Předpoklad „sůl se generuje jako zcela náhodný řetězec“ je mylný. V případě, že se dostanu k databázi nebo na stroj s konfigurací serveru můžu zjistit čas systému, nastavení, prostředí atp. a simulovat podmínky vytvoření hesla (zde může dojít k dramatické úspoře času). Podle generování hashe záleží ještě na míře entropie takového generátoru nebo hashovací fce a pokud je sestaven vlastní řetězec pro vytvoření „náhodné“ soli, je zde další riziko pro její snížení z důvodu chyby.

      Jen pro příklad Nette používá vytvoření náhodného řetězce konfiguraci a prostředí PHP serveru, které kromě ní obsahuje i čas požadavku viz. https://github.com/nette/nette/blob/master/Nette/Utils/Strings.php#L418 a pak pro každý znak znovu získává čas aby se zvýšila entropie (v důsledku plánování systému nemusí být čas lineární). Další info v diskusi https://github.com/nette/nette/pull/882
      Co vím jde o „nejnáhodnější“ funkci v PHP bez cizích knihoven.

  2. Václav Oborník

    Mobilní klient a aplikace třetích stran
    Chtěl bych se zeptat, jak by to bylo s autentizací při potřebě poskytovat API kromě single page aplikaci také mobilním klientům a aplikacím třetích stran (webovým i mobilním)?

    Je možné je vůbec s tímto řešením autentizace podporovat? Mohu mobilnímu klientovi (nativní aplikaci, ne prohlížeči) nastavit cookie?

    Jak byste řešil s zapamatování přihlášení? Pouze prodloužením času platnosti tokenu?

    Díky za odpověďi!

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=9985