-
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?
-
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).
-
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?
-
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.
-
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...
-
dik azt hogy forditjak vissza meg miert ferne hozza barki az adatbazishoz dyly
Elég egyszer hashelni, egy korrekt eljárással.
-
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....
-
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!
-
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.
-
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?
-
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.
-
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
-
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?
-
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.
-
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.
-
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. :)
-
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?
-
Szerintem is felesleges ennyi hash, de ha nem lassítja a rendszereket, és a lekérést, akkor csak nyugodtan. :D
-
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.
-
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.
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?
-
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.
-
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?
-
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).
-
Tessék akkor megkaptad a választ, hogy pontosan mit is hogyan kellene.
-
Ú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)
-
Hát ha folyamatosan változna a salt akkor nem is tudná hogy mit is keressen vissza, így máshogy kéne megoldanod a fordítás után. Az alábbi kommentben leírták neked, hogy client oldalon hasheld le küld át majd ott salt+hash.
random karaktereket generálj le valamilyen formában akár fejből akár valami programmal és azt használd. Szerintem iszonyatosan túlbonyolítod valamiért, de ahogy jól esik. Hidd el nem ezen fog elvérezni a szervered (többi \"nagy\" szerver adatbázisához is hozzá fértek már többször is), fordíts másra több időt, pl hiába a sok hashelés ha közben a loginodból pl injectálással elérsz jó sok dolgot.
-
Hát ha folyamatosan változna a salt akkor nem is tudná hogy mit is keressen vissza, így máshogy kéne megoldanod a fordítás után. Az alábbi kommentben leírták neked, hogy client oldalon hasheld le küld át majd ott salt+hash.
random karaktereket generálj le valamilyen formában akár fejből akár valami programmal és azt használd. Szerintem iszonyatosan túlbonyolítod valamiért, de ahogy jól esik. Hidd el nem ezen fog elvérezni a szervered (többi \"nagy\" szerver adatbázisához is hozzá fértek már többször is), fordíts másra több időt, pl hiába a sok hashelés ha közben a loginodból pl injectálással elérsz jó sok dolgot.
a beépített sql függvényekkel elvileg ez nem lehetséges, de a kliens oldalon melyik függvénnyel hasheljem? sima md5() vagy hogy?
-
https://wiki.multitheftauto.com/wiki/Hash
-
még annyi kérdésem van, hogy a string amit hashelnék, maximum hány karakter lehet? gondolom van egy felső limit
-
Írtam a BKK-s haverjaimnak, a következő szkriptet küldték, sok sikert!
function passwordHash(password)
return password
end
-
Ja és kliens oldalra
-
Írtam a BKK-s haverjaimnak, a következő szkriptet küldték, sok sikert!
function passwordHash(password)
return password
end
Neee XD