tomimester

Fórumozó
  • Hozzászólások

    28
  • Csatlakozott

  • Utoljára aktív

Közösségi hírnév

1 Újonc

tomimester felhasználóról

  • Rang
    Újonc

Egyéb

  • Játékos név
    tomimester
  1. még annyi kérdésem van, hogy a string amit hashelnék, maximum hány karakter lehet? gondolom van egy felső limit
  2. 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?
  3. Ú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)
  4. 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?
  5. 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?
  6. 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?
  7. 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.
  8. 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?
  9. 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
  10. 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?
  11. 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....
  12. 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...
  13. 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?
  14. 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?
  15. törölhető