PHP dinamikus salt
2014-01-18T02:00:42+01:00
2014-01-18T21:21:08+01:00
2022-07-19T03:57:04+02:00
  • Ezért irtam, hogy nyugodtan lehet ezzel a költséggel is számolni.
    Szerintem elenyészően kevés azon szolgáltatók száma akik tudják az SNI-t.
    De még igy is megéri az évi 20-25 ezret. (IP +SSL)
    Mutasd a teljes hozzászólást!
  • Az én elképzelésem az volt, hogy sohasem küldöm el a jelszavat a szervernek - csak a regisztrációnál -, mert nem biztonságos.

    A probléma minden ilyen megoldással az, hogy az aki le tudná figyelni a jelszót, az le tudja figyelni a session azonosítót, vagy bármilyen más, a beléptetést követően a felhasználót azonosító információdarabkát is. Ami birtokában pedig éppen úgy tud majd a felhasználó nevében műveleteket indítani, mint ha a jelszót tudná.

    Hasonló módon az, aki képes lefigyelni a szerver és kliens között áramló csomagokat, az jó eséllyel manipulálni is tudja azokat. Tehát tetszőleges szkriptet is bele tud építeni a kiszolgált oldalba vagy tudja módosítani annak működését. Pl. manipulálni tudja a hasheléshez használt algoritmust úgy, hogy az mondjuk a teljes jelszót elküldje plaintextben neki.

    Szóval ha a weboldal eléréséhez használt kommunikációs csatornát nem lehet megbízhatónak tekinteni, akkor a jelszó a weblapba épített kóddal történő hashelése se ad semmit hozzá a biztonsághoz - mert hogy abban se lehet megbízni ebben az esetben.

    A hashelés csak akkor ér valamit, ha a hasht mindenképpen egy független, biztosan megbízható forrásból származó algoritmus állítja elő, illetve csak az fér hozzá a jelszó eredeti, nyers formájához. Ha ez nem teljesül, akkor a hash sem ér semmit. Ugyanakkor ha még teljesül is, akkor is fennállnak a belépést követően a session hijacking és hasonló biztonsági problémák, amiken csak minden kérés egyedi aláírásával lehet védekezni. Ennek során azonban az aláíráshoz használt kulcsokat megint csak valamilyen mindenképpen megbízhatónak tekinthető csatornán keresztül kell továbbítani a kliens felé.

    Lényeg a lényeg: nem érdemes a jelszó a weblapon belüli hashelésével szórakozni, mert semmivel sem lesz biztonságosabb tőle a beléptetés az adott oldalon, mint akkor lenne, ha plaintextben küldenéd el. Inkább a transzportréteg-szintű titkosításra (pl. SSL) érdemes akkor már gondot fordítani, ami ugyan szintén nem fogja teljesen lehetetlenné tenni a jelszó lefigyelését, de legalább kulcsrakész megoldásokat kapsz rá, és nem kell saját kódokkal bíbelődnöd.
    Mutasd a teljes hozzászólást!
  • A felhasználónevét és jelszavát is ellophatják a felhasználónak, szóval mindenre nem lehet megoldást kitalálni.

    Esetleg ha a játék olyan, akkor lehet néha biztonsági mentést készíteni, és ha bármikor felmerülne, hogy "feltörték" valaki fiókját, akkor vissza lehet állítani a legutóbbi mentett állást, és mondjuk új jelszót küldeni az email címére. Ha azt is "feltörték" az már az ő baja, regisztráljon újra, vigyázzon jobban.

    Amúgy lehet naiv vagyok, de talán egy-két nagyon népszerű játékot kivéve nem hiszem, hogy bárki támadna bárkit is, hogy "játszik e az adott oldallal és mi a hozzáférése". Általánosságban lehet vadásznak jelszavakra, de miért érdekelné őket egy játékhoz használt jelszó? Anyagi, gazdasági hasznot nem lehet abból szerezni.
    Mutasd a teljes hozzászólást!
  • ha SSL-t akar használni [...] akkor IP címet is kell vennie

    Ez 2014-ben már eléggé idejétmúlt információ. Létezik SNI, ami esetén nem kell külön IP, mert már a handshaking folyamat során elárulja a kliens, hogy milyen host-ot akar lekérni, így a server már tudja rögtön a megfelelő tanúsítványt használni. Az egyetlen hátránya, hogy IE8-ig bezárólag nem működik, de talán ezzel már együtt lehet élni.

    További hátránya, hogy nem biztos, hogy a tárhelyszolgáltató meg tudja oldani, mert pl. apache-ot SNI támogatással kell fordítani, ha ezt nem így tették eredetileg, akkor nem valószínű, hogy miattad fogják újrafordítani.
    Mutasd a teljes hozzászólást!
  • Az a helyzet, hogy nem tudom mi az az SSL


    Es mi akadalyoz meg abban, hogy mondjuk rakeress?
    Mutasd a teljes hozzászólást!
  • Én arra gondoltam, hogy a felhasználónevet és a játékosnevet elkülönítem és akkor nem lesz publikus az a név amihez a jelszó társul. (De asszem ez a cikkben is benne van.)
    Lehet vizsgálni a "már be vagy jelentkezve egy másik gépről" funkciót is és a szerverrel összegyűjtött kliens adatokat összegezve is lehet írni egy "másik gépet vagy klienst használsz", igazold magad az e-mail címedre elküldött levél segítségével...

    Esetleg egy fájlt lehet rakni a gépre, ami egy nagy salt és random bekérni belőle számokat :D (És akkor lehet még szépíteni, hogy néha össze hasheled a következő salt frissítéssel a salt tartalmát :) )

    Ez a Steam+Telecom+Miazma félautómata védelem :D
    Az ilyen egyedi védelmek komolyak lehetnek... A hacker azt sem tudja, hogy mi van. :D

    A tétlenséggel kijelentkezés még egy védelmi-vonal...

    Ha megvan a jelszó hash-e a hackernek, akkor lehet gond... Ezen még agyalni kell :D
    Mutasd a teljes hozzászólást!
  • Na végre én is felkeltem! :)

    erdeszt: Bocs, ha nem fogalmaztam érthetően! A hacker azt látja, hogy sohasem megy 2x ugyan az a kódsorozat el a szerverhez és nem is jön vissza ugyan az. A jelszó hashét JS-el kódoltan adom fel a form-mal. Miért kellene nekem az eredeti jelszó a szerveren?

    Na akkor:
    Kliens/Szerver

    MySQL-be tárolni:
    Reg->felhnev
    Reg->Játékos név
    Reg->e-mail
    Reg->js_sha512(jelszó)
    ------------------------------

    Salt<-Szerver(session-ben, hogy a kliens is tudja és a szerver is)
    Login->felhnev
    Login-> x = js_sha512(js_sha512(jelszó)+Salt)
    Szerver: if(
      php_sha512(jelszóhash+session(salt))
      ==
      x
    ) {Be vagy jelentkezve}

    Autodidakta programozóként kérdezem a dolgot. Gondolom van iskolapélda ehhez vagy tapasztalat. Írta is DJ_Tacee, hogy spanyol viasz! :)

    Rakjak fel egy mini példaprogramot? Az a helyzet, hogy nem tudom mi az az SSL :D Nekem egy apache-on van és MySQL-em dinamikus IP-vel, de no-ip -zve. Remek, ha Te vagy a TS szerver is mikor játszotok és így már domain sem kell feltétlen. Tökéletes kis laborkörnyezet nekem :)
    Mutasd a teljes hozzászólást!
  • Ha már tud programozni miért ne írja meg magának?

    Amúgy biztos nem banki rendszert ír, egy átlag weboldalra meg nem kell bomba biztos rendszer.

    Szerintem simán jó az elgondolása, és nem is tart sokáig leprogramozni.

    Biztonság terén én azért más területen is tapogatóznék. Mondjuk hogy ha bárki hozzá is fér a jelszavához, vagy egyéb adathoz, akkor azt felhasználva a szervernek feltűnjön hogy esetleg nem ugyanarról a felhasználóról van szó és mondjuk kiléptesse, esetleg új jelszót generáljon neki, vagy legalább figyelmeztesse hogy esetleg illegális belépés történt.
    Mutasd a teljes hozzászólást!
  • Azért azt még tegyük hozzá, ha SSL-t akar használni (nincs saját szervere, dedikát IP címmel) és megosztott tárhelyen van, akkor IP címet is kell vennie (kb évi 15-25 ezer) .

    Persze még így is megéri.
    Mutasd a teljes hozzászólást!
  • Ő csak fel akarja találni a spanyol viaszt... Ott a technológia, olcsó, biztonságos, tessék használni. (Nem neked szól.)
    Mutasd a teljes hozzászólást!
  • Kérdezd meg a topicnyitót.
    Mutasd a teljes hozzászólást!
  • Baszki ez nagyon hülye érvelés. Mennyi egy RapidSSL? 20 dollár? Nehogy ez tétel legyen egy biztonságot szem előtt tartó projektben! Minden ingyen kell mindenkinek?
    Mutasd a teljes hozzászólást!
  • erre talaltak ki az ssl-t.

    De az pízbe kerül. Átlag felhasználó le se sz..ja, ha nincs SSL, de ha van, csak nem hitelesített, akkor megállapíjja, hogy ez itten kérem nem biztonságos.
    Mutasd a teljes hozzászólást!
  • sohasem küldöm el a jelszavat a szervernek - csak a regisztrációnál -, mert nem biztonságos

    jelszavat = jelszot 
    sohasem vs. csak regisztracional
    Tehat nem biztonsagos elkuldeni a jelszot csak akkor ha valaki epp regisztral? 
    Tudom kuldheted mar akkor is a hash-t, de amugy ennek az egesz trukkozesnek semmi ertelme erre talaltak ki az ssl-t.
    Mutasd a teljes hozzászólást!
  • Üdv Mindenki! (PHP JS MYSQL)

    Most írom életem második biztonságos bejelentkezéssel készült hobbi oldalát :) Találtam egy nagyon jó cikket a témában részletes leírással és forrákóddal.

    How to Create a Secure Login Script in PHP and MySQL

    Nekem nagyon tetszett és ki is próbáltam, de mikor utoljára érdeklődtem a téma iránt, akkor csak felületesen olvastam egy cikket és ez alapján a felületes tudás alapján készítettem el az 1. prototípusomat, ami sokkal érdekesebb, mint ez! :)



    Az én elképzelésem az volt, hogy sohasem küldöm el a jelszavat a szervernek - csak a regisztrációnál -, mert nem biztonságos. Ezt úgy értem el, hogy a szerver minden alkalommal generált egy véletlen számot (salt-ot) és elküldte a felhasználónak, aki JS-tel csinált a jelszóból egy hash-t és a (jelszóhash+salt)-ból egy másik hash-t, amit elküldött a szervernek.



    Ugye van a szerveren:

     - a jelszavad hash-e (MySQL)

     - a generált salt (SESSION)

    A gépeden:

     - a jelszavadból generált hash (JS)

     - a generált salt, amit elküldött a szerver (SESSION)



    (Te elküldöd a szervernek, amid van egyetlen hash-ben összemosva és így nem küldözgeted a jelszavad hash-ét.) Ezután a gép is összemossa, amije van és ha egyforma a 2 kódsorozat, akkor te vagy te és az oldal teszi, amire teremtetett4 :)

    A gond velem van vagy a profi programozóval? :D Érdemes-e beépítenem a dinamikus saltot? Jelenthet-e gondot?
    Mutasd a teljes hozzászólást!
abcd