shranjevanje gesla v bazo (brez autentikacije)

A je to potem sploh geslo?

Edino da enkriptiraš. Kak open ssl.

Malo bolj opiši vse skupaj.

Drugače pa kot rečeno, če nočeš imeti plain gesla v bazi, ga enkriptiraj. Uporabiš kak pyopenssl.

Situejšn trenutno na testnem okolju je uporabnik se logira preko erp sistema, ko uporabi en modul od tega sistema se uporabi njegov certifikat (na samem serverju, file system) in njegov pw ki je v bazi plain text. To je opis trenutnega stanja.

Vrž ven še tisto obstoječo txt geslo, ker ne služ ničemur.

Tak security ne igra nobene vloge. Če nimaš na bazi row based security. Zvež vse prek ldapa. Ne pa shranjevat gesl.

MrStein je 3. nov 2016 ob 17:06 izjavil:

Preden shraniĹĄ v bazo, geslo enkriptiraĹĄ.
Ko prebereĹĄ, pa dekriptiraĹĄ, preden ga uporabiĹĄ.

VpraĹĄanja so:
- kaki algoritem uporabiti (najbolje pogledati, kaj ti jezik oziroma framework podpira)
- kak ključ za enkripcijo uporabiti (varnostno gledano bi bilo dobro uporabiti prijavno geslo uporabnika, s katerim se je v ERP prijavil, če obstaja in če ti je na voljo; sicer pa skupen ključ za vse userje, kar je že problem, recimo: kje ga hraniti?)

gesla se vedno hashiranjo, saj je ravno to point, da se ga ne da odkriptirat!
preverjanje pravilnega vnosa se nato preverja da se vptikano geslo zaheshira in se ta hash primerja z tistim v bazi...

Excalibrus vse lepo in prav, stolpcu je pravzaprav ime hash_pw, ker sem s takim namenom se lotil. Ampak...fora je v tem da noben ne bo tipkal tega po inicialnem vnosu (ob registraciji podjetja)....everrrrrr. Tako da ne morem primerjat s hashem ki bi bil v bazi ker ni gesla spljoh.

detroit je 4. nov 2016 ob 11:50 izjavil:

Excalibrus vse lepo in prav, stolpcu je pravzaprav ime hash_pw, ker sem s takim namenom se lotil. Ampak...fora je v tem da noben ne bo tipkal tega po inicialnem vnosu (ob registraciji podjetja)....everrrrrr. Tako da ne morem primerjat s hashem ki bi bil v bazi ker ni gesla spljoh.

Zato pa pobriš iz baze še tiste passworde pa predpostav da je zadeva zaupanja vredna. Al pa nared kot se spodobi avtentikacijo.

Za hrambo certifikatov (in s tem tudi "gesel") obstajajo kake rešitve.
(bi morale, ker to gre zdaj v množično uporabo)

Spura, zakaj pa si odgovoril, če ni vprašanje?

detroit> Torej uporabnik se logira v sistem, nato uporablja funkcionalnost ki upobljajo certifikate za vzpostavo seje in to uporabnik nikakor ne bo sam tipkal, tako je bilo zahtevano. Je pa res da mi je bolj pomembno kot zahteve varnost sistema in zato si razširjam "varnostna" obzorja.

OK, štekam. Nimaš pa nobene možnosti, da dodajaš funkcionalnost na drugo stran te seje?

Ker pravilno bi moralo jit nekako takole: Uporabnik se prijavi v tvojo aplikacijo in odpre modul, ki se želi povezati z drugo aplikacijo. Modul ugotovi, da nima dostopa in uporabnika preusmeri na stran, kjer se lahko prijavi v drugo aplikacijo z namenom izkazovanja svoje identitete, po prijavi pa druga aplikacija vrne varnostni žeton prvi aplikaciji (recimo takšnega, ki ima življensko dobo tri mesece ali karkoli se vam zdi dober kompromis med varnostjo in uporabnostjo). Ta prijava je lahko poljubno zahtevna, saj se dogaja le enkrat na precej dolg interval. Tvoja aplikacija potem shrani ta žeton v obliki, ki ni berljiva direktno (bodisi šifrirano v bazi, bodisi v ločeni bazi, bodisi v ločenem servisu, namenjenem shranjevanju občutljivih podatkov) in se z njim predstavlja drugi aplikaciji, kadar se mora.

stvar (ta modul) je še v POC zato pa je tko na hojladri security. Torej jype v bistvu ne bi smel na backendu autentikacije za to "zunanjo povezavo". Hmm to bi znalo zakomplicirat stvari do amena. Hvala vsem za pomoč seveda