Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 13. 08. 2018, 12:17:00
-
Jaká je nejlepší autentifikace v poměru "implementační náročnost/bezpečnost"?
Můj námět:
Pro uložení n-tice (user, password, roles) do databáze použít pro password MD5 a Salt, viz. https://en.wikipedia.org/wiki/Salt_(cryptography)
Jako Salt bych nejraději použil username namísto nějakého náhodného řetězce, je to vhodné?
A další otázka, jak bezpečně posílat heslo přes HTTP, jedině přes HTTPS nebo existuje i jiná možnost? Např. generování MD5 sumy v javascriptu.
-
Co mají všichni s tou MD5, která se na ukládání hesel nehodí a ještě se musí zbytečně ukládat sůl?
-
Koupil si v levnych knihach 20let starou prirucku programujeme v PHP3.0... na MD5 zapomen.
-
Můj námět:
Můj námět - přestaň znovuvynalézat hranaté kolo.
-
Jaká je nejlepší autentifikace v poměru "implementační náročnost/bezpečnost"?
Co mate s tou "autentifikaci" cesky je to jen AUTENTIZACE vsechno ostatni jsou patvary...
-
salt dynamicky generuj ....
a input data sifruj a generuj salt z sifrovanych dat))
takhle to bude secure (ignoruj lidi co nedokazou security... kdyz sifrujes tak to bezpecne bude)
-
MD5 ne a username misto nahodneho retezce taky ne.
-
MD5 ne a username misto nahodneho retezce taky ne.
ja treba pouzivam sha 512 a silnejsi + vicenasobne sifrovani i generovani saltu ze sifrovanych dat)) takze max secure))
(s pouzitym funkce crypt samozrejme)
-
Jaká je nejlepší autentifikace v poměru "implementační náročnost/bezpečnost"?
Použít hotové funkce vašeho frameworku/knihovny/serveru.
A další otázka, jak bezpečně posílat heslo přes HTTP
Blbě, protože prohlížeče bezpečné metody autentizace (kdy se heslo nepřenáší, nebo se používá asymetrická kryptografie atd.) neimplementují buď vůbec, nebo zoufale blbě. S tím ale jako jednotlivec nic nenaděláte, takže vám nezbývá, než použít nějaký workaround, který váš framework nabízí.
-
Jaká je nejlepší autentifikace autentizace...
Pro uložení n-tice (user, password, roles)...
Role autentizace neřeší. Ty patří do autorizace. Opravdu bych doporučil nevynalézat kolo, které navíc bude ve výsledku hranaté (a to pak raději běžte psát sobotní komix ;-)).
-
Na nejakou databazi se proboha vyser a nauc se pouzivat OpenLDAP.
-
... neimplementují buď vůbec, nebo zoufale blbě...
jj, soudruzi v chrozille(o tech ostatnich netreba mluvit) totiz nemaji cas, resej jak budou posilat vsechno do cmoudu
... jak bezpečně posílat heslo přes HTTP...
Jde to, ale ma to jeden hak(mozna spis kotvu) ... bez zasahu ala admin se neodhlasis. Muzes pouzit http digest, ze to hnusne vypada, s tim se da zit, ale potiz je prave v tom, ze neexistuje zadnej rozumnej zpusob jak jednou prihlasenej browser odhlasit.
Podobny je to s prihlasovanim klicem, coz je prozmenu jeste vetsi vopicarna ze strany usera (na to ze by si to zvladal zprovoznit BFU ve svym browseru rovnou zapomen).
Mimochodem, posilat hesla pres https taky neni ani trochu bezpecny, ve finale je totiz uplne jedno jestli si tvoje hesla cte nekdo cestou, nebo jestli si je cte nekdo na serveru. V pripade bezpecnych zpusobu prihlasovani server tvoje heslo nikdy nesmi videt a nesmi mit ani zadnou moznost jak se k nemu dostat (= i vsemozny pseudoreseni javascriptem jsou khovnu uplne stejne, protoze kdo ma pristup k serveru ti muze kdykoli zmenit i ten script)
-
anonym napis mail a mozna pomuzu (mam vlastni spusob sifrovani))))) ... teda pokud potrebujes php)))
-
ale potiz je prave v tom, ze neexistuje zadnej rozumnej zpusob jak jednou prihlasenej browser odhlasit.
Ctrl+Shift+Del, Clear Active Logins. Ano, odhlásí to všechny weby najednou.
anonym napis mail a mozna pomuzu (mam vlastni spusob sifrovani))))) ... teda pokud potrebujes php)))
Ano, vynalézat vlastní šifrování, protože to určitě udělám líp než protokol léta prohlížený odborníky, a určitě tam nenadělám žádné začátečnické chyby, to je klíčem k úspěchu!
-
ale potiz je prave v tom, ze neexistuje zadnej rozumnej zpusob jak jednou prihlasenej browser odhlasit.
Ctrl+Shift+Del, Clear Active Logins. Ano, odhlásí to všechny weby najednou.
anonym napis mail a mozna pomuzu (mam vlastni spusob sifrovani))))) ... teda pokud potrebujes php)))
Ano, vynalézat vlastní šifrování, protože to určitě udělám líp než protokol léta prohlížený odborníky, a určitě tam nenadělám žádné začátečnické chyby, to je klíčem k úspěchu!
mno pokud jse spolehas na "odborniky" tak jses radnej pako)) koukni jse na cpu vyvojare, misto kopirovani stejneho (treba cpu intel chyby a features) jsi jedou open-source(nebo half-open source) a dokonale zastoupi "vseobecne uznano nejlepsi metodu")))
-
anonym napis mail a mozna pomuzu (mam vlastni spusob sifrovani)))))
Jseš to ty? (https://www.root.cz/zpravicky/chytrejsi-lide-nemaji-lepsi-hesla/977825/) ;D ;D ;D
-
Ctrl+Shift+Del, Clear Active Logins. Ano, odhlásí to všechny weby najednou.
To ze ja a ty vime jak odhlasit session ze strany browseru je ale na dve veci, kdyz potrebujes zaridit odhlaseni na strane serveru ... jo, taky na to existuje postup ... ze "prej" kdyz se petkrat uklonis a zariznes slepici ... a pak browseru posles 401 ... tak to odhlasi ... coz je chovani ovsem nikde nezdokumentovany a nijak nestandardizovany.
-
Pokud se jedná o PHP je nejjednodušší a díky použití BCrypt dostatečně bezpečné využití stadnardní funkce password_hash:
http://php.net/manual/en/function.password-hash.php (http://php.net/manual/en/function.password-hash.php).
-
anonym napis mail a mozna pomuzu (mam vlastni spusob sifrovani)))))
Jseš to ty? (https://www.root.cz/zpravicky/chytrejsi-lide-nemaji-lepsi-hesla/977825/) ;D ;D ;D
ja ne ))) pokud se nemeni soustava bitova a ta nesifruje tak to pro mne neni sifrovani)))
-
doporucoval bych taktiku, kterou pouziva treba ejabberd - ukladej hesla plaintextem. Pecka jak nikdy. Dodnes nepochopim, o co jim jde...
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
ja ti navrhuju reseni bez frameworku)) daj email adresu))
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
A co kdybys nam oznamil, o co ti vlastne jde? Jak uz nekdo rikal, znovuvynalezas tu kolo - a to pomerne dost spatne. Pokud ti jde o ukladani hesel - hash, v PHP treba bcrypt (blowfish). Javascriptem posilat heslo jak? Pri registraci? Normalne POSTem pres HTTPS, proc bys to delal jinak? Nebo snad pri prihlaseni? Mame JWT tokeny, taky pres HTTPS. Ja fakt netusim, proc ma kazdej druhej tendenci myslet si, ze vsechno dokaze udelat lip nez jak se to pouziva.
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
ja ti navrhuju reseni bez frameworku)) daj email adresu))
anonym: takze reknu tak pokud chces reseni ja mam sifrovaci + sifrovane hash funkce)) zadnej framework... (nejsem lopata co kopiruje a pouziva framework jde x chyba na milion pouziti))))
-
Ok, takže používám Servlet API v Javě a chci si udělat autentifikaci a autorizaci. Neobjevuju kolo, Servlety jsou snad normální věc. Umožňují mi uložit si Session - nevím jak, prostě to mají zmáknuté.
Pointa je, že používám čistě Servlety bez frameworku typu Spring a Javy EE. No a chci si udělat přihlašování.
Takže něco jako je toto:
public static boolean authenticate(String username, String password) {
if (username.isEmpty() || password.isEmpty()) {
return false;
}
User user = userDao.getUserByUsername(username);
if (user == null) {
return false;
}
String hashedPassword = BCrypt.hashpw(password, user.getSalt());
return hashedPassword.equals(user.getHashedPassword());
}
public static Route handleLoginPost = (Request request, Response response) -> {
Map<String, Object> model = new HashMap<>();
if (!UserController.authenticate(getQueryUsername(request), getQueryPassword(request))) {
model.put("authenticationFailed", true);
return ViewUtil.render(request, model, Path.Template.LOGIN);
}
model.put("authenticationSucceeded", true);
request.session().attribute("currentUser", getQueryUsername(request));
if (getQueryLoginRedirect(request) != null) {
response.redirect(getQueryLoginRedirect(request));
}
return ViewUtil.render(request, model, Path.Template.LOGIN);
};
Jak je vidět, je to v principu velice jednoduché. Nicméně třeba takový Spring Security je několika-megabajtová hydra.
Proto mě zajímá problematika autentifikace. Chci si ujasnit, jestli je pro 9/10 případů v pořádku použít jednoduchý způsob autentifikace, a nebo je třeba vymýšlet nějaké další složitosti.
Nedělám SW pro banku dpč.
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
ja ti navrhuju reseni bez frameworku)) daj email adresu))
nemůžu ti dát email, já jsem anonym. Napiš to tady.
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
ja ti navrhuju reseni bez frameworku)) daj email adresu))
nemůžu ti dát email, já jsem anonym. Napiš to tady.
to by pak sifrovani postradalo smysl)) pointa source code je mit ho uzamcene na webservru)) bez pristupu jinejch)) no jak chces))
-
Umožňují mi uložit si Session - nevím jak, prostě to mají zmáknuté.
už tohle mluví za vše.
Jinak "JAVA Servlet specification http://download.oracle.com/otndocs/jcp/servlet-4-final-spec/index.html (http://download.oracle.com/otndocs/jcp/servlet-4-final-spec/index.html)" jasně říká jak se řeší zabezpečení viz. kapitola 13.1. Dále se také v kapitole 7.1 dozvíš jak fungují session a po přečtení zjistíš co všechno si vlatně evidentně nevěděl. Takové studium posune tvojí práci daleko dopředu. Má to pár stránek, ale hodně to pomůže.
Stefan
-
Umožňují mi uložit si Session - nevím jak, prostě to mají zmáknuté.
už tohle mluví za vše.
Jinak "JAVA Servlet specification http://download.oracle.com/otndocs/jcp/servlet-4-final-spec/index.html (http://download.oracle.com/otndocs/jcp/servlet-4-final-spec/index.html)" jasně říká jak se řeší zabezpečení viz. kapitola 13.1. Dále se také v kapitole 7.1 dozvíš jak fungují session a po přečtení zjistíš co všechno si vlatně evidentně nevěděl. Takové studium posune tvojí práci daleko dopředu. Má to pár stránek, ale hodně to pomůže.
Stefan
Budes se divit, ale ja to o Session uz davno cetl. Mam predstavu jak funguje, ale nevim to presne.
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
Hlubší vhled do problematiky na fóru? K tomu tyhle diskuse fakt neslouží. Začni tím, že si k tomu dohledáš nějaké pořádné ucelené informace a nastuduješ si je. A pak tady diskutuj o konkrétních detailech, ne že přijdeš stylem "chci postavit barák, mám pytel cementu a lopatu, poraďte mi, jak na to".
-
Takže jste se tady zmohli jen na to se vysmát a přesměrovat na existující framework. Bez jakéhokoliv hlubšího vhledu do problematiky.
ja ti navrhuju reseni bez frameworku)) daj email adresu))
nemůžu ti dát email, já jsem anonym. Napiš to tady.
to by pak sifrovani postradalo smysl)) pointa source code je mit ho uzamcene na webservru))
Aha. Tak to je určitě úžasné šifrování, když ho nejde zveřejnit, protože by přestalo fungovat. Odkazovaný znovuvynálezce solení asi bude o několik levelů výš.
::) ::) ::)
-
@anonym:
Pokud se rozhodnete řešit na webu autentizaci pomocí hesel, tak byste měl řešit následující problémy:
1) Čitelnost hesel v databázi
Pokud unikne databáze, uživatele nepotěší, že si útočník jejich hesla rovnou přečte. Hashovací funkce se používají proto, aby čitelná podoba hesla (kterou je třeba dát serveru pro přihlášení) nebyla z databáze zjistitelná. Je dobré zvolit nějakou hashovací funkci považovanou dnes za bezpečnou (naptř. z rodiny SHA-2, tedy SHA224/256/384/512).
Princip je takový, že server přijaté heslo zahashuje a výsledek porovná s tím, co má uložené v databázi.
2) "duhové" tabulky (rainbow tables)
Problém je, že si každý může hashe pro různá hesla předpočítat dopředu, vytvořit si jakousi tabulku dvojic (hash,heslo), tedy vlastně funkci "inverzní" k hashovací. Tím se zahashované heslo uživatele stává čitelné, jakmile se objeví v takové "duhové" tabulce, a tedy jsme v zásadě na začátku (nelze spoléhat, že si uživatelé budou volit hesla, která v předpočítané tabulce nikdy nebudou). A ano, takových tabulek předpočítaných dvojic (hash,heslo) lze najít hromadu, stačí mít jen dostatek diskového prostoru.
Pro vyřešení tohoto problému byla zavedena sůl (salt), tedy náhodně vypadající řetězec (generovaný ideálně náhodně), který se k heslu před hashováním přidá. To znamená, že útočník si nemůže dopředu předpočítat "duhovou" tabulku, protože pro výpočet hashe potřebuje znát sůl.
Další výhoda použití soli spočívá v tom, že uživatelé se stejným heslem budou mít rozdílný hash (pokud budou mít rozdílnou sůl).
Sůl není tajný parametr, takže ji můžete ukládat klidně v databázi. Jen to jen věc přidávající na náhodnosti. Měla by být ale dostatečně náhodná.
3) Vysoký výkon počítačů
I když útočník nemůže využít (díky soli) nějaké již hotové "duhové" tabulky, stále může po nahlédnutí do databáze použít hrubou sílu a pro dvojici (salt, hash) najít vstupní heslo. Samozřejmě za předpokladu, že zná algoritmus hashování a aplikace soli, ale utajování těchto věcí je proti principům dnešní kryptografie (tajné jsou klíče/hesla, ne postupy).
Řešení tohoto problému je v celku přímočaré; použít hashovací funkci, jejíž výpočet trvá velmi velmi dlouho. Uživatel její výpočet pocítí pouze při přihlášení, takže nárůst náročnosti pro něj nepředstavuje problém, i kdyby ten výpočet trval vteřinu. Nejjednodušším způsob, jak zvýšit výpočetní náročnost hashovací funkce, je její iterativní použití (tzn. ji na výsledek používat opakovaně). Stačí jen zvolit vhodný počet iterací (tisíce-statisíce nebudou problém).
--------------
Tak, to bychom měli vhled do problematiky.
--------------
Weby nedělám, ale přijde mi, že v dnešní javascriptové době by se dalo autentizovat i pomocí privátních/veřejných klíčů. Privátní klíč by se mohl generovat z uživatelova jména, hesla (a bhůvíčeho) a mezi serverem a klientem by se pak vyměnila jenom challenge (náhodná data) a response (podpis challenge). Ale určitě už takové věci existují.
-
A preco si vobec v dnesnej dobe chcete robit vlastnu autentifikaciu. Urobit ju bezpecne nie je jednoduche: 2FA, OTP, ... Najjednoduchsie je nasadit SSO (OAuth, pripadne SAML pre enterprise). Pokial nechcete/nemozete pouzit public IdPs (Google, Github, LI, ...) tak si nasadte Keycloak, ktory ma vela moznosti na auth/pouzite flows/....
-
S bezpecnostou sa nesranduje, nevymysla sa koleso a neoplati sa spoliehat sa na nazory anonymnych ludi z nahodneho fora, ktora objavite, ktore by sa tou tematikou mohlo zaoberat.
Oplati sa doverovat autoritam, ktore sa bezpecnostou zaoberaju.., napr. na kurzoch pocitacovej bezpecnosti na FMFI UK sa vseobecne spominaju nariadenia od americkeho NIST, alebo nemeckeho uradu pre bezpecnost BSI, poziadavky na certifikaciu FIPS, pripadne bezpecnost webov celkom kvalitne a podrobne riesi projekt OWASP.
OWASP o hashovani hesiel: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Do_not_limit_the_character_set_and_set_long_max_lengths_for_credentials
NIST o roznych druhoch overovania identity:
https://pages.nist.gov/800-63-3/sp800-63b.html
Zhrnutie: Odporuca sa pouzivat hashovacie metody, ktore su povazovane za bezpecne, s rozumnou (nastavitelnou) cenou vypoctu, aby sa nedali pri brute-forcovani odskusat tisicky hesiel za sekundu. Take su napr. Argon2, PBKDF2, scrypt, bcrypt. Vsetky by mali mat overenu implementaciu pre bezne programovacie jazyky (napr. PHP ma aj Argon2 ako sucast standardnej kniznice, pre Python existuje passlib) a rozumne implementacie zvyknu salt generovat pri hashovani nahodne a ukladat ho ku hashu do jedneho "hash stringu", takze ho vacsinou netreba navyse riesit vo vlastnom kode (ale toto si treba overit samozrejme)
-
To je prostě jak se zabezpečením domu. Můžeš koupit Jablotron alarm, dát to všudemožně, ale když tě bude chtít vykrást profík, protože doma máš v trezoru růžový diamant velký jako vejce, tak tě stejně vykrade.
Ale kdo z náš tohle doma má? Nikdo. Tak pro by k vám někdo takový chodil - to je to nejlepší zabezpěčení. Proto první úroveň zabezpěčení je zámek na dvěře. S tím se spokojí 70% bytů. 98% bytů se pak spokojí s nějakým obyč jablotronem, který si dají do obýváku a do garáže. Je jasné, že jinou úroveň zabezpěčení potřebuje třeba bank, kde i tohle by bylo málo.
Ale to neznamená, že když si chci zabezpěčit svůj dům, musím mít řešení jako banka a trezory jako banka. To je to, co se mi tu někteří trotli typu Lol Phierae snaží vnutit.
Takže mi bohatě stačí řešení pro 9 z 10 případů užití. Potřebuju jen vědět, jakým algoritmem zahashovat heslo, které si odchytnu na restu, a jestli mi stačí dát na server HTTPS aby se to heslo nedalo odposlechnout cestou na server. A udělat obojí co nejjednodušeji.
Prolomit se dá stejně všechno.
-
Potřebuju jen vědět, jakým algoritmem zahashovat heslo
ROT11
-
Potřebuju jen vědět, jakým algoritmem zahashovat heslo
PBKDF2/scrypt/bcrypt/argon2 (ty jsou nejlepší, o tom, který konkrétně z nich, se budou lidi hádat -- PBKDF2 se dá dobře akcelerovat na GPU/FPGA, což nechceme, ale zase používá „standardní“ HMAC-SHA, zatímco ty zbylé tři jsou méně standardní a člověk si tak může naběhnout (https://en.wikipedia.org/wiki/Bcrypt#User_input)) nebo iterovaná SHA2.
a jestli mi stačí dát na server HTTPS aby se to heslo nedalo odposlechnout cestou na server
Ještě je potřeba dát si pozor, abys nelinkoval obsah z HTTP (zejména javascripty, protože přes ty může někdo vyčíst to formulářové pole s heslem -- btw. u JS se dá dát do kódu hash a pak linkovat cizí JS a nejde podvrhnout, ale to je asi moc opruz dělat. Možná to stojí za zvážení pokud používáš nějakou CDN), a nastavit HSTS, aby nešly udělat downgrade útoky. Osobně po nastavení ověřuji HTTPS na https://www.ssllabs.com/ssltest/.