Jelentkezz be, hogy követhesd  
Követő(k) 0
tomimester

Jelszó titkosítás

32 hozzászólás ebben a témában

Hali, most a úgy vannak tárolva a jelszavak, hogy még kliens oldalon használom a felhasználónévre és jelszóra a hash("sha512", felhasználónév/jelszó) függvényt, és így küldöm szerver oldalra, amikor a regisztrációs gombra nyom. Mondták, hogy ez nem elég biztonságos, mit tehetnék még?

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Szerver oldalt hashelj. Illetve érdemes még valamilyen kulcsot is használni az egész mellé. Például: valami+jelszó+valami2. Majd az ebből kapott verziót hashelni egyszer vagy akár kétszer. Kicsit olvass utána a témában, kismillió opció létezik, kinek mi jött be stb stb... Kliens oldalról triggerrel átdobod a kívánt jelszót/beírt jelszót. Azt tartsd észben, hogy a kliens oldalt esetleg tudja modifikálni a játékos, így ha ott akarsz hashelni abból akár gond is lehet (persze ettől még szerver oldalon is lehet, tehát például érdemes a speciális karaktereket letiltani vagy esetleg az egész jelszóra egy "filtert" készíteni).

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet AlexSwamp felhasználótól, 54 perce

Szerver oldalt hashelj. Illetve érdemes még valamilyen kulcsot is használni az egész mellé. Például: valami+jelszó+valami2. Majd az ebből kapott verziót hashelni egyszer vagy akár kétszer. Kicsit olvass utána a témában, kismillió opció létezik, kinek mi jött be stb stb... Kliens oldalról triggerrel átdobod a kívánt jelszót/beírt jelszót. Azt tartsd észben, hogy a kliens oldalt esetleg tudja modifikálni a játékos, így ha ott akarsz hashelni abból akár gond is lehet (persze ettől még szerver oldalon is lehet, tehát például érdemes a speciális karaktereket letiltani vagy esetleg az egész jelszóra egy "filtert" készíteni).

köszi, a salt-ra, gondolsz ugye? és milyen függvénnyel rakjam a jelszó elejéhez meg a végéhez a salt-ot?
és az megoldható lenne hogy a salt-ot ne derítsék ki?

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

simán azzal hogy valahol deffiniálod  vagy a hashelésben akár. pl.:

local new_pass = ikszde..password..ikszde
hash("sha512", new_pass)

Vagy 

hash("sha512", ikszde..password..ikszde)

Saltot csak akkor tudják meg, ha mondjuk a szerver oldali filehoz hozzáfér (elvileg...). Nem fontos az elejéhez és a végéhez, akárhogy saltozhatod, az rád van bízva hányszor és hogyan.

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

de ha visszafordítják a jelszót, akkor ki tudják venni melyik a salt, nem?

úgy értem fel fog tűnni annak aki megszerezné az adatbázist, hogy mindenkinek ugyan az a szó van az elején és a végén...

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

dik azt hogy forditjak vissza meg miert ferne hozza barki az adatbazishoz dyly

 

Elég egyszer hashelni, egy korrekt eljárással.

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

mert pl. valahogyan sikerül feltörni az adatbázist, vagy nem tudom.... tényleg fontos lenne az adatbázis biztonsága, nem szeretném ha bárki felhasználóját azért lopnák el mert gyenge a biztonság nálam....

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Adj meg egy erős jelszót az SQL szerveren, és egyébként mindenhol (min 16 karakter, spec. karakterek), tiltsd le a távoli SQL elérést, állíts be logolást, akár email értesítést, és úgy nem kell félned.

Az SHA256 pl pont nem azok közé tartozik, amit csak úgy visszafordítanak. Viszont továbbra is elég egyszer hashelni.

Nem lesz kicsi a biztonság!

1 személy kedveli ezt

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet AnthonyGates felhasználótól, 2 órája

Adj meg egy erős jelszót az SQL szerveren, és egyébként mindenhol (min 16 karakter, spec. karakterek), tiltsd le a távoli SQL elérést, állíts be logolást, akár email értesítést, és úgy nem kell félned.

Az SHA256 pl pont nem azok közé tartozik, amit csak úgy visszafordítanak. Viszont továbbra is elég egyszer hashelni.

Nem lesz kicsi a biztonság!

Általában nem is a hashelés és a saltozás a gond, hanem hogy mindenkinek adnak hozzáférést mindenhez, meg root jogokon futtatnak mindent. Szóval hiába a biztonságos hashelés ha közben maga a szerver alap úgy ahogy van hibás. :sweat_smile: De amúgy valóban elég egyszer. Sok esetben azért kerül ki a jelszó mert mindenhol ugyan azt használja a tulajdonosa és valahol sikerült rést találni a pajzson...:smile:

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

sha 512-re gondoltam, szerintem az biztonságosabb illetve az okés, hogy kliens és szerver oldalon is van hash? vagy tényleg elég egyszer?

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Teljesen elég egyszer szerver oldalon hashelni. Igazából SHA256 is bőven elég, nem azon fog múlni az egész. Inkább amit említettek, hogy az sql hozzáféréseket limitáld illetve igyekezz ne root usert használni etc. 

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

debian 9-et használok, sajnos root felhasználót alapból nem tudok használni, és amúgy se szoktam.. :D

találtam 1 másik függvényt, azt hallottam ez biztonságosabb lenne, vélemények?
https://wiki.multitheftauto.com/wiki/PasswordHash

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

ez milyen lenne?
 

hash("sha512", hash("sha512", salt_1) .. hash("sha512", password) .. hash("sha512", salt_2))

és a salt mi legyen? random számok, vagy mit adjak meg salt-ként? értem, hogy elég lenne egyszer hashelni, de azért kíváncsi lennék így milyen lenne. illetve a felhasználóneveket hogy tároljam? azt is salt-olva, és sha512 -vel titkosítva?

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Szerintem teljesen felesleges ennyi hash. Ennyivel bőven elég vagy már:

local salt = "$o98123Ghasd#.dfrWQ"

hash("sha256",salt..password) 

Felhasználókat nem kell hashelni, szerintem felesleges. De igazából hashelheted mint az email címeket is, de szerintem ezek már talán a túlzás fokát is elérik.

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet AlexSwamp felhasználótól, 1 perce

Szerintem teljesen felesleges ennyi hash. Ennyivel bőven elég vagy már:

local salt = "$o98123Ghasd#.dfrWQ"

hash("sha256",salt..password) 

Felhasználókat nem kell hashelni, szerintem felesleges. De igazából hashelheted mint az email címeket is, de szerintem ezek már talán a túlzás fokát is elérik.

ismerős a neved, ha jól tudom te fejlesztettél egy MTA szerót, már nem emlékszem melyiket. ott is hasonló védelem volt? csak mert szerintem a biztonságnak nincs határa :D, és még ha ki is kerülne tényleg nem akarom semmiféle képpen hogy vissza hash-eljék.

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Nem fejlesztettem soha, nem vagyok fejlesztő csak olvasgattam és próbálgattam a témában már sokat. Illetve maximum hobby szinten kisebb-nagyobb dolgokat megcsináltam megnézve hogy amit elképzeltem működik -e. Speciel amúgy saját szerveren nem vittem túlzásba, jelszót hasheltem egyetlen saltozással mindig. Igazából maga a jelszó nem onna kerül ki, nem beszélve arról, hogy visszafejtés sem egynapos munkafolyamat. Legtöbb esetben inkább ott hasalnak meg a dolgok hogy hozzáférnek az sql-hez és megnézik mondjuk az email címét/usernevét és azt más oldalakon megpróbálják megfejteni (mondjuk email-t). Ha jobban érzed magad hasheld be a felhasználónevet és az email-t is. Szerintem inkább arra figyelj jobban, hogy ne férjenek hozzá az sql-hez, meg maga a szerver magjához, ne tudják injectálni és a többi. :) 

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet AlexSwamp felhasználótól, 15 perce

Nem fejlesztettem soha, nem vagyok fejlesztő csak olvasgattam és próbálgattam a témában már sokat. Illetve maximum hobby szinten kisebb-nagyobb dolgokat megcsináltam megnézve hogy amit elképzeltem működik -e. Speciel amúgy saját szerveren nem vittem túlzásba, jelszót hasheltem egyetlen saltozással mindig. Igazából maga a jelszó nem onna kerül ki, nem beszélve arról, hogy visszafejtés sem egynapos munkafolyamat. Legtöbb esetben inkább ott hasalnak meg a dolgok hogy hozzáférnek az sql-hez és megnézik mondjuk az email címét/usernevét és azt más oldalakon megpróbálják megfejteni (mondjuk email-t). Ha jobban érzed magad hasheld be a felhasználónevet és az email-t is. Szerintem inkább arra figyelj jobban, hogy ne férjenek hozzá az sql-hez, meg maga a szerver magjához, ne tudják injectálni és a többi. :) 

senki nem fér hozzá az adatbázishoz, rajtam meg a tulajdonoson kívül. akkor amit fentebb írtam:
 

hash("sha512", hash("sha512", salt_1) .. hash("sha512", password) .. hash("sha512", salt_2))

erre írhatom tovább a rendszeremet? és a salt már alapból titkosítva legyen, és úgy hashelem mégegyszer, vagy a salt az ne legyen titkosítva, és akkor legyen először hashelve amikor összerakom a stringeket?

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Szerintem is felesleges ennyi hash, de ha nem lassítja a rendszereket, és a lekérést, akkor csak nyugodtan. :D

 

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Az egy dolog, hogy most ki fér hozzá, a kérdés az hogy később ki fog esetleg bejutni valamilyen formában (erre is értettem a limitálást). Szerintem iszonyatosan túlgondolod, saltozást felesleges hashelni és az egész salt+jelszó kombót is elég egyszer hashelni. Csak feleslegesen lassítod be a processzorod vele (gondolj bele hogy minden egyes folyamatot végig kell futtatnia és mondjuk szorozd fel 500 emberrel), igazából az általunk leírt verzió is teljesen biztonságos már, de ha nagyon biztonságosat akarsz, akkor pedig írj egy saját kódolást és használd azt. :smile:

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet AlexSwamp felhasználótól, 2 órája

Az egy dolog, hogy most ki fér hozzá, a kérdés az hogy később ki fog esetleg bejutni valamilyen formában (erre is értettem a limitálást). Szerintem iszonyatosan túlgondolod, saltozást felesleges hashelni és az egész salt+jelszó kombót is elég egyszer hashelni. Csak feleslegesen lassítod be a processzorod vele (gondolj bele hogy minden egyes folyamatot végig kell futtatnia és mondjuk szorozd fel 500 emberrel), igazából az általunk leírt verzió is teljesen biztonságos már, de ha nagyon biztonságosat akarsz, akkor pedig írj egy saját kódolást és használd azt. :smile:

erre már gondoltam, de mégse lenne olyan biztonságos mint egy ilyen rendszer. nem lassítja be a procit, 500 playerünk soha nem lesz, de maga az ötlet ahogy tárolnám a jelszavakat, felhasználóneveket (hash("sha512", hash("sha512", salt_1) .. hash("sha512", password) .. hash("sha512", salt_2))) jó lenne, vagy van vele baj?

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

A szervergép azért van, hogy terhelni lehessen. Ha már belebasznak egy bölömbika processzort ne csak super mariozni akarjanak már rajta az emberek. Azért van, hogy ki lehessen használni.

Másrészről érdemes a jelszót kliens oldalon hashelni és úgy elküldeni, ugyanis az RPC-k sima bájtokat küldenek, így lényegében akármilyen egyszerűbb hálózat figyelő programmal kilehet figyelni egyes emberek jelszavát.

Összedobtam egy gyors kis tesztet, megnézzük mennyi idő alatt fut le:

local TEST_SETTINGS = {
    interval = 10000,

    salt_1 = randomString(16),
    salt_2 = randomString(16),
}

local tick = getTickCount()

for i = 1, TEST_SETTINGS.interval do
    local password = randomString(32)

    hash("sha512", hash("sha512", TEST_SETTINGS.salt_1) .. hash("sha512", password) .. hash("sha512", TEST_SETTINGS.salt_2))
end

print(string.format("Executed in %dms", getTickCount() - tick))


Természetesen a jelszó minden egyes ciklusnál egy tetszőleges 32 karakter hosszúságú szöveg ami alfanumerikus karaktereket tartalmaz. A fenti kód az én gépemen átlagban véve 310ms alatt futott le. Most annak az esélye, hogy éles szerveren egy adott pillanatban, egy csettintésre összejönne 10.000 kérés, azt nem tartom valószínűnek.

Az egyes algoritmusokat brute forceolni tudják csak.

Saját algoritmust meg nem érdemes fejleszteni se, hiszen a meglévőeket hozzártő szakemberek írták, és fejlesztik azt.

1 személy kedveli ezt

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon
Idézet DrAkE felhasználótól, 21 perce

A szervergép azért van, hogy terhelni lehessen. Ha már belebasznak egy bölömbika processzort ne csak super mariozni akarjanak már rajta az emberek. Azért van, hogy ki lehessen használni.

Másrészről érdemes a jelszót kliens oldalon hashelni és úgy elküldeni, ugyanis az RPC-k sima bájtokat küldenek, így lényegében akármilyen egyszerűbb hálózat figyelő programmal kilehet figyelni egyes emberek jelszavát.

Összedobtam egy gyors kis tesztet, megnézzük mennyi idő alatt fut le:

 

local TEST_SETTINGS = {
    interval = 10000,

    salt_1 = randomString(16),
    salt_2 = randomString(16),
}

local tick = getTickCount()

for i = 1, TEST_SETTINGS.interval do
    local password = randomString(32)

    hash("sha512", hash("sha512", TEST_SETTINGS.salt_1) .. hash("sha512", password) .. hash("sha512", TEST_SETTINGS.salt_2))
end

print(string.format("Executed in %dms", getTickCount() - tick))


Természetesen a jelszó minden egyes ciklusnál egy tetszőleges 32 karakter hosszúságú szöveg ami alfanumerikus karaktereket tartalmaz. A fenti kód az én gépemen átlagban véve 310ms alatt futott le. Most annak az esélye, hogy éles szerveren egy adott pillanatban, egy csettintésre összejönne 10.000 kérés, azt nem tartom valószínűnek.

Az egyes algoritmusokat brute forceolni tudják csak.

Saját algoritmust meg nem érdemes fejleszteni se, hiszen a meglévőeket hozzártő szakemberek írták, és fejlesztik azt.

 

arra gondoltam, hogy talán még teaEncode is mehetne bele, de az lehet már tényleg túlzás. :D akkor mehet szerintetek ez a hash amit írtam? attól féltem ha valamit többször hash-elek akkor könnyebben vissza lehet fejteni de akk úgy néz ki nem... illetve a salt akkor random karakterekből, számokból álljon, vagy olyat amit én adok meg, és ha esetleg használnám a teaEncode-t akkor annak a jelszava is olyan legyen mint a salt?
és kliensen, szerveren hash a jelszót?

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Magát a jelszót hashelve küldd el a szervernek, amit a szerveren tovább hashelhetsz egy bizonyos salt-tal. A salt-nak egy általad megadott karakternek kell lennie és nem véletlenszerűnek. Ha mindig véletlenszerű lenne nem tudnád összevetni, hogy helyes jelszót írt-e be vagy sem, mivel nem lenne meg a salt hozzá (bár van aki elmenti adatbázisban minden egyes emberhez tartozó saját saltot).

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Úgy értettem, hogy véletlen karakterek legyenek (számok, betűk), mint maga a salt, amit 1x definiálok. amikor a szervernek küldöm elég lenne egy teaEncode vagy hash("sha512", ...) salt nélkül? Random karakterek alatt azt értem, mint pl. amit a phpMyAdmin generál jelszóként.

Példa:

Kliens:
triggerServerEvent ("login", localPlayer, hash("sha512", password))

Szerver:
salt_1 = -- random karakterek
salt_2 = -- random karakterek
key = -- random karakterek

addEventHandler("login", root, function(password)
    teaEncode(hash("sha512", hash("sha512", salt_1) .. hash("sha512", password) .. hash("sha512", salt_2)), key)
end)

Szerkesztve tomimester által

Megosztás


Megosztás link alapján
Megosztás egy közösségi oldalon

Regisztrálj vagy jelentkezz be, hogy válaszolhass

Csak felhasználóként kommentelhetsz.

Regisztrálj

Légy közösségünk tagja még ma! Csak fél perc.


Regisztrálok

Jelentkezz be

Már van felhasználód? Lépj be!


Bejelentkezek
Jelentkezz be, hogy követhesd  
Követő(k) 0