Diskuze: integrace GDPR, jak šifrovat hesla pro aplikace třetích stran

V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Aktivity

Zdeněk Srb

Člen

Zdeněk Srb:24.9.2018 20:54

Chci se zeptat někoho kdo řešil implementaci GDPR, jak se vypořádal s problematikou hesel uložených v databázi, které slouží k autorizaci při komunikaci přes SOAP nebo pro REST api. Jediné co mě zatím napadá je nějaký šifrovací algorytmus s privátním klíčem, který bude mimo databázi. Každopádně si rád nechám poradit.

Odpovědět

24.9.2018 20:54

Peter Mlich

Člen

Peter Mlich:25.9.2018 8:09

Neposilej hesla, posilej potvrzovaci hash.

Mas system, ktery resi jen hesla uzivatelu. Pod nim mas seznam programu, ktere uzivatel pouziva. A ke kazdemu programu ma unikatni hash zalozeny na jmene programu, uzivateli, heslu.
Stejny hash by ti mel poslal program, ktery chce overit uzivatele.
Pokud mas na strance link na jiny program, tak do linku pridavas session, cookies, ze jsi nalogovany v programu1, opet posles hash a chces se nalogovat na program 2. Opet, system overi nalogovani na program 1 a kdyz je ok, naloguje te na program 2. (tohle samozrejme neni bezpecne, ale spousta firem to vyuziva, treba zname je logovani pres fb ucet pro komentare nebo tady do fora)

Cili, kazdy program, ktery uzivatel pouziva ma unikatni hash.

Nahoru Odpovědět

25.9.2018 8:09

Zdeněk Srb

Člen

Zdeněk Srb:25.9.2018 8:50

Možná se mýlím, ale já vždy předpokládal, že hash funguje jen za předpokladu, že alespoň jedna strana zná to heslo v čitelném tvaru, tedy se ale bavíme o komunikaci dvou stran, které by obě měli jen otisk. Počítám, že hlavní důvod pro to, že poskytovatel té služby chce, aby heslo chodilo v plain textu je ten, že si to hashuje na své straně a on to heslo v čitelné podobě uložené také nemá. Jediná další možnost je při každém volání té služby nutit uživatele zadat heslo ručně, jenže to by nás asi přišli zabít.

Nahoru Odpovědět

25.9.2018 8:50

Martin Štěpánek

Tvůrce

Martin Štěpánek :25.9.2018 12:15

Základem tohoto je, že ti třetí strana pokud možno poskytne hash/token určený přímo pro tebe pro autentizaci u nich. Jako například, když Facebook ti při přihlášení na tvé stránce poskytne token, kterým ho pak můžeš přes API ověřit.
Pokud tu ta možnost není, tak ti asi nezbývá žádný jiný způsob než stornovat hesla a ano v tom případě by se měl použít vhodný obousměrný šifrovací algoritmus. Přímo php má nějaké funkce pro toto, takže bych doporučil se podívat na ně. :-)

Akceptované řešení
+20 Zkušeností
+2,50 Kč

Nahoru Odpovědět

25.9.2018 12:15

Všechno jde naprogramovat, chce to jen čas a chuť...

Martin Štěpánek

Tvůrce

Martin Štěpánek :25.9.2018 12:17

Z hlediska gdpr by mělo být jedno, jak to storuješ, jde o to, abys o tom informoval uživatele a on a tím souhlasil. Pokud ti při přihlášení zaškrtne, že souhlasí se zpracováním osobních údajů podle tebe, tak si klidně ty hesla teoreticky můžeš uložit jako plaintext, pak už jsi zodpovědný jen za případný únik. Takže z hlediska gdpr jde jen o to dát jim možnost souhlasit s ukládáním hesel a pokud nebudou, tak ať si ty hesla zadávají pokaždé sami...

Nahoru Odpovědět

25.9.2018 12:17

Všechno jde naprogramovat, chce to jen čas a chuť...

Peter Mlich

Člen

Peter Mlich:26.9.2018 15:48

Ono se to spatne popisuje. Zkusim to narozneji.

user> user + psw
program registrace> prijme, ulozi do tabulky (id, user, userhash = hashuj(user,psw,sul), a dalsi udaje)
program registrace> a prida do tabulky sluzeb sluzby, pro kazdou vyrobi individualni sluzbahash = hashuj(sluzba, userhash,sul)

sluzba1 login> odesila user + psw (normal login)

prijima to program registrace, vyrobi userhash jako pri registraci
a dale to zpracovava pro login v tabulce sluzby, vyrobi sluzbahash a overi s tabulkou

Nalogovani zapise do tabulky nalogovani (id, sluzba_id, user, nalogovanihash), nalogovanihash se pak odesila do seesion

link na strance na sluzbu2

prijme to program pro logovani do sluzeb a zjisti, zda jsi nalogovany podle nalogovanihash , ktery mas v session. Kdyz te najde, tak ti jenom zmeni sluzba_id na odpovidajici hodnotu pro sluzba2

Asi by to slo napsat i jednoduseji, vic nazorneji

No, jde o to, ze dneska zadny system by nemelo zajimat tvoje psw. System by mel mit vytvoreny a ulozeny jen hash.
Ano, nemuzes poslat uzivateli jeho heslo.
Ale muzes mu ho zmenit!
A nebo si ho muze pres nejaky formular zmenit sam. Posles mu na mail link na formular, ktery mu otevres na nejaky cas, kdy je mozne zmenit heslo. Otevre ho prave klikem na ten link. A opet, uzivatel sice posila heslo, ale ty mu vyrobis jen novy hash. Takze zase nemas zadne heslo.

U GDPR jde o to, aby jsi si ukladal co nejmene udaju, kterymi lze uzivatele identifikovat. Pokud mas ten hash dos pomichany pomoci soli (treba sul zalozena na aktualnim case a nahodnych znacich), tak pokud by se uzivatel registroval vzdy stejnym jmenem a heslem, mel by byt hash vzdy unikatni.
Cili, pokud bude tvuj program na 10 pc a uzivatel se v kazdem z nich registruje, tak nemuzes s jistotou rici, kdyz pouziva stejny nick, ze je to stejny user.

Jo, neco jineho je, kdyby vsech 10 programu ukladalo user, psw. To jsou 2 udaje, ktere jsou obvykle pro dva ruzne lidi unikatni.

Samozrejme, muzes si ukladat dalsi pomocne udaje jako ip a pod. Ale tady fakt setrit. Fakt jen pouzit pro vlastni ucely a neposilat je sluzbe 1 a 2, sluzbam tretich stran.
Ty si je samozrejme muzou zjistit take, protoze jim posles odpoved, ano, prihlaseny, ne neprihlaseny. Ale, to uz je jejich problem, jejich porusovani prav uzivatele. Tys jim nic takoveho nedal.

Nahoru Odpovědět

26.9.2018 15:48

Zdeněk Srb

Člen

Zdeněk Srb:27.9.2018 9:23

diky všem za názory

Nahoru Odpovědět

27.9.2018 9:23

Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 7 zpráv z 7.