Biztonságosabb bejelentkezés
2009-04-22T12:30:20+02:00
2009-04-27T16:26:59+02:00
2022-07-25T14:42:48+02:00
  • Felebarátaim az Úrban: -szégyellem magam a 2.-es kérdés miatt. Az alábbi kódot a php.net-en találtam:
    //This works in 5.2.3 //First function turns SSL on if it is off. //Second function detects if SSL is on, if it is, turns it off. //==== Redirect... Try PHP header redirect, then Java redirect, then try http redirect.: function redirect($url){ if (!headers_sent()){ //If headers not sent yet... then do php redirect header('Location: '.$url); exit; }else{ //If headers are sent... do java redirect... if java disabled, do html redirect. echo '<script type="text/javascript">'; echo 'window.location.href="'.$url.'";'; echo '</script>'; echo '<noscript>'; echo '<meta http-equiv="refresh" content="0;url='.$url.'" />'; echo '</noscript>'; exit; } }//==== End -- Redirect //==== Turn on HTTPS - Detect if HTTPS, if not on, then turn on HTTPS: function SSLon(){ if($_SERVER['HTTPS'] != 'on'){ $url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; redirect($url); } }//==== End -- Turn On HTTPS //==== Turn Off HTTPS -- Detect if HTTPS, if so, then turn off HTTPS: function SSLoff(){ if($_SERVER['HTTPS'] == 'on'){ $url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; redirect($url); } }//==== End -- Turn Off HTTPS

    Üdv!
    Árpád
    Mutasd a teljes hozzászólást!
  • Ok. Arról, hogy a felhasználó milyen jelszót választ nyilván mindenkinek van anekdótája, ajánlása. Viszont van még 2 pont a történetben amiben a segítségeteket kérem:

    1.) Kliens oldal biztonsági megoldásai -jó a tisztán html alapú form-tól még én se várok semmit, de talán a javaScript-es DOM guruk esetleg tudnának adni egy-két tippet/ajánlást adni.

    2.) A másik nyitott kérdés https-átvitel:
    -egyrészről érdekelne, hogy kb. milyen karakterű szerver terhelés növekedésre számítsak (lineáris: 2x-3x? stb.);
    -másrészt az volt az alapkoncepciom hogy csak a bejelntkezés menyjen https protokollal, ha bejelntkezett (a $_SESSION-ben benne a 'user' paraméter) elegendő a sima http. Ehhez Árnyéktól kaptam egy induló tippet:
    Programozási feladatod csak akkor van igazából, ha csak a bejelentkezésnél akarod használni, mert akkor php-ból nem árt ellenőrizni, hogy tényleg https-en keresztül próbálnak belépni (súgok: $_SERVER-ben nézz körül!), de apache-nál .htaccess-ben is megoldhatod, hogy a bejelentkezés csak https-en keresztül működjön.

    Ok, leellenőrzöm: $_SERVER['HTTPS'] paraméter 'on'-e? De ha nem az, akkor hogyan tovább? És ha már elküldte cleartext-ben a bejelentkezési adatait már nem mindegy? Kérjem meg, hogy küldje el https-sel is?
    (Attól tartok, hogy végképp láma kérdéseimmel sikerült kiszivárogtatnom, hogy az apache front áll a legtávolabb tőlem). Minden esetre be kell vallanom .htaccess-ről annyit tudok, hogy hogyan kell elérhetetlenné tenni a web felöl könyvtárakat
    -Szóval kicsit több induló segítségre lenne szükségem!

    Köszi!
    Árpád
    Mutasd a teljes hozzászólást!
  • erre írtam, hogy olyan jelszava senkinek sincs.
    A jelszó akkor ér valamit, ha a tulajdonosa nem felejti el.

    Dehogy nincs. Én is ilyen jelszavakat használok ott, ahol lényeges. Ha jobban megnézed, akkor Benjy egy nagyon jól megválasztott jelszót használt: a radiátor szót írta kicsit megkeverve. Ezt könnyen meg lehet jegyetni, mégis elég bonyolult a szótár alapú töréshez.
    Mutasd a teljes hozzászólást!
  • Akkor az életben nem fejted vissza.

    És a sózás nem csak ebben segít. Lehet, hogy egy véletlen folytán találsz egyező hash-t valami ismert szóval, de a sót akkor sem ismered. A találatot meg nem használhatod fel mint jelszót, mert az is sózásra kerül (így más lesz a hash) ergo egy sózott hash visszafejtésével sem mész sokra, csak ha ismered a kódszót is.
    Mutasd a teljes hozzászólást!
  • De ha van jobb ötleted örömmel veszem.

    Nincs.

    Én valószínűleg úgy csinálnám, hogy 5 próba után a jó belépésig captcha minden alkalommal, valamint percenként nem engednék 1-2 kísérletnél többet ezután.
    A robotokat igencsak lelassítod/ellehetetleníted vele.

    Ugyanakkor nem áll fenn az általam vázolt manuális szívatás lehetősége sem.
    Mutasd a teljes hozzászólást!
  • Erre írta Benjy, hogy
    "Azok adatbázisból fordítanak...
    Sózótt értékre semmit sem érnek"


    Ha az a jelszavam, hogy cica, de pl. minden karakter után beszúrok valamit, mielőtt hash-elem:
    cFiwc9a%

    Akkor az életben nem fejted vissza.
    ill. ha vissza is fejted, hogy cFiwc9a%, nem fogod tudni, hogy mi ebből a tényleges jelszó.
    Mutasd a teljes hozzászólást!
  • erre írtam, hogy olyan jelszava senkinek sincs.
    A jelszó akkor ér valamit, ha a tulajdonosa nem felejti el. Múltkor megnéztük a cégnél, a főnököm összes jelszavát visszafejtette.
    Mutasd a teljes hozzászólást!
  • Azok adatbázisból fordítanak...
    Sózótt értékre semmit sem érnek.
    Van egy (több) bazinagy adatbázis ahol megvannak a sűrű hashek,
    kutya, cica stb..

    Próbáld ki, sztem a kutya tuti benne van, viszont hogy r4d1axt0r sztem tuti nem.
    Mutasd a teljes hozzászólást!

  • MD5
    -Igen, a topic nyitása óta okosodtam: tehát ez az hogy a felhasznalok táblába nem a jelszót hanem annak md5 lenyomatát tárolom. Bejelentkezéskor pedig a form-ról bejövő jelszót is md5-tel elkódolt értékét vetem össze a táblában lévő hash-el.


    A google ebben is jó. Szépen visszafordítgatja. Persze a bonyolultabbakat nem. De olyanokat meg nem használ senki. Ha jól tudom itt a prog.hu-n se szórakoznak ezzel. Szépen megküldik a saját jelszavadat, ha kéred. Én jobban is szeretem az ilyet. Aki meg a pin kódját adja meg valahol, meg is érdemli...
    Mutasd a teljes hozzászólást!
  • Hogy tudod meg a nicket?
    Ha bizalmas dolog az oldal akkor miért adná meg?
    Ha mondjuk játék, vagy fórum akkor 2 név kell egy ami megjelenik az oldalon, és egy belépési.
    Mutasd a teljes hozzászólást!
  • Igen. Ez benne van a pakliban.
    Mutasd a teljes hozzászólást!
  • Beírkálom 25-ször, mert mondjuk épp nem cseréltél velem matchbox-ot és vagyok, te pedig máris le vagy tiltva, pedig a környéken sem jártál...


    Szerintem ilyen esetben stl ír egy mail-t nekem, én pedig felszabadítom. A Te mérged mondjuk még mindig nem szállt el és újra megszivatod szegényt. Így a következő körben már felhasználó nevet is váltunk.

    Én is jobban szeretném munkaállomás szinten kitiltani a rosszindulatú klienseket, de abba maradtunk, hogy ez nemigen lehetséges, hiszen az IP cím -azon felül hogy nem egyedi- még route-olható/lecserélhető is. De ha van jobb ötleted örömmel veszem.

    Köszi!
    Árpád
    Mutasd a teljes hozzászólást!
  • Mondjuk 5 rossz kísérlet után egy captcha. Ezzel a robotot kizárod. 5 captcha után felfüggeszted a user 24 órára. Vagy örökre (admin tudja csak visszaengedni). Így is volt 25 lehetősége begépelni a helyes jelszót. Ennyinek elégnek kell lennie.


    Ez kicsit problémás lehet.
    Tegyük fel, hogy tudom a mail címedet (vagy ha csak nick kell a belépéshez, még jobb)
    Beírkálom 25-ször, mert mondjuk épp nem cseréltél velem matchbox-ot és vagyok, te pedig máris le vagy tiltva, pedig a környéken sem jártál...
    Mutasd a teljes hozzászólást!

  • Az emberi találékonyság határtalan.
    Mutasd a teljes hozzászólást!

  • captcha-törésről olvastam egy szellemes megoldást: robotunk átadta a képet a gazdája pornó oldalának, ahol a felhasználó akkor kapta meg a következő zaftos képét ha megfejtette a feliratot...
    Mutasd a teljes hozzászólást!
  • Rendben, de akkor hogyan azonosítsak egy munkaállomást?

    Sehogy. Egy - majdnem - biztos dolog van: egy session tuti, hogy egy munkaállomás. A session megszűntével azonban megszűnik ez a kapcsolat is (és maradhat a sütiben tárol infó akár évekig, de erre alapozni valamit nem szabad, mert törölhető, módosítható, stb).

    Ötletelés:
    Mondjuk 5 rossz kísérlet után egy captcha. Ezzel a robotot kizárod. 5 captcha után felfüggeszted a user 24 órára. Vagy örökre (admin tudja csak visszaengedni). Így is volt 25 lehetősége begépelni a helyes jelszót. Ennyinek elégnek kell lennie.

    Ezeket az infókat tárolhatod a users tábládban. Kell egy-két új mező: badlogins(int) és kicked(datetime). A login közben ezt ellenőrzöd:
    - Ha kicked NULL, akkor nézheted a jelszót, egyébként üzenet: "lockolt user, fordulj az adminhoz"
    - Ha jelszó rossz, akkor növeled badlogin-t egyel.
    - Ha ez öttel osztható, akkor egy captcha-t is generálsz a login formra.
    - Ha badlogins 25, akkor kicked = now + 1 day.

    Sikeres logon esetén nullázod a badlogins számlálót.

    a sózás ugye az ...

    Igen. Pontosan.
    Mutasd a teljes hozzászólást!
  • Rendben, de akkor hogyan azonosítsak egy munkaállomást?
    (Ráadásul Dr.House-tól tudom, hogy mindenki hazudik -különösen igaz ez az Interneten.)
    Jó, egy dátum/idő mező beszúrásával felfüggesztéssé szelidíthetem a kitiltást (bár még nem tudom hogyan, de csak rájövök), de egy jóindulatú robot/féreg stb. amikor letelik a felfüggesztése onnan folytatja ahol abbahagyta Ez ellen lehet programból védekezni?

    Köszi az elemzésedet is! -Megfogadom a tanácsaidat.
    Egy láma kérdés ezzel kapcsolatban is ki kivánkozik belőlem: a sózás ugye az amikor a kódolás előt a kódolandó szöveg adott pozícióiba konstansokat szúrunk?

    Köszi!
    Árpád
    Mutasd a teljes hozzászólást!
  • Arra figyelj az ilyen megoldásnál, hogy az IP nem egyedi azonosító. Simán kizárhatsz egy tanuló miatt egy egész iskolát, vagy egy dolgozó miatt egy egész céget. Ezt meg nem biztos, hogy szeretnéd.
    Mutasd a teljes hozzászólást!
  • Flood védelem-

    Akkor ehhez csinálok egy táblát:
    CREATE TABLE `munkaallomas` ( `wsip` VARCHAR( 16 ) NOT NULL , `wsengedely` VARCHAR( 1 ) NOT NULL DEFAULT 'A', `wsfeketepont` SMALLINT NOT NULL DEFAULT '0', PRIMARY KEY ( `wsip` ) ) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_hungarian_ci;

    Adok hozzá egy trigger-t
    CREATE TRIGGER ip_tiltas AFTER UPDATE ON `munkaallomas` FOR EACH ROW UPDATE `munkaallomas` SET wsengedely = 'T' WHERE wsfeketepont > 9;

    a) a php kód elején meghatározom a kapcsolódó munkaállomás IP-jét;
    b/1) ha a munkaallomas táblában benne van és a wsengedely=='T' akkor részére ennyi volt a progim: die();
    b/2) ha nincsen benne INSERT, és generálok egy ugrókódot a $_SESSION-be;
    b/3) ha benne van wsengedely=='A'-val és az ugrókód is megegyezik akkor új ugrókód és minden rendben;
    b/4) ha benne van wsengedely=='A'-val de az ugrókód ne stimmel, akkor wsfeketepont++ és új ugrókód;
    c) ha nincs belépve autentikásció, amennyiben nem jó wsfeketepont++;

    -Ez a biztonsági(ugró)kód jó ötlet, már érzem, hogy a duplaklattyok ellen is tudom majd használni

    Köszi!
    Árpád
    Mutasd a teljes hozzászólást!
  • Arra szeretnék választ kapni, hogy a következő autentikációs folyamat miért nem biztosságos

    Akkor elemezzük.

    1.)HTML Form: felhasználónév/jelszó bekérés;

    Eddig nem nagyon tudsz mit tenni. Jórészt csak ez van.

    2.)Adatküldés a szervernek cleartext (ez biztos necces);

    Azért necces, mert vagy a gépen, vagy az átjárón (cég esetében) vagy bárhol útközben (bármelyik átjárón) kiolvasható. Egy rosszakaró ezt eltárolhatja. A https használata ugye ezt megakadályozza (legalább is nagyon megnehezíti), mert az adatok titkosítva utaznak.

    3.)PHP lekérdezi az SQL szerver felhasznalok táblájából, hogy a felhasználónév/jelszó érvényes-e;

    Ez így önmagában rengeteg biztonsági kérdést vet fel:
    1. ha a jelszavakat tárolod az adatbázisban akkor egy db admin azokat kiolvashatja. E helyett illik salted hash-t tárolni és bejelentkezéskor az újra generált hash-t hasonlítani a tárolttal.
    2. Mivel php-ról van szó a kód nyitott egy admin vagy ügyes hacker számára (aki a szervert töri meg), így a só is meg a hash eljárás is megtekinthető. Ez ellen lehet védekezni egy obfuscator bevetésével (legalább is meg lehet nehezetíteni a csúnya bácsi dolgát)
    3. ha nem korlátozod a rossz belépési kísérletek számát, akkor egy kis utility-vel simán nekiállok és bruteforce-al feltöri bárki a jelszót. (A captcha is hasonlóan jó védelem és hasonló célt szolgál.)
    4. ha azt írod vissza hibaüzenetnek, hogy "Az xy felhasználónévhez megadott jelszó hibás" (és ha nincs ilyen falhasználó, akkor konkrétan közlöd, hogy "nincs ilyen felhasználó"), akkor le lehet kérdezni, hogy pontosan milyen felhasználók léteznek. Csak idő és okos kis utility kérdése (szintén bruteforce).
    5. ha nem figyelsz oda, akkor fenáll az sql injection veszélye, így gyakorlatilag azt csinálnak a rendszereddel amit akarnak. Akár az admin jelszót is felülírják távolról és akkor teljhatalmuk van.
    6. biztos van több is, de most hirtelen ennyi jutott eszembe

    4.)Ha igen a PHP felveszi a $_SESSION-be az autentikációs bejegyzéseket

    A sessionid cookie-ban tárolódik. Elméletileg van rá lehetőség, hogy ezt átírva egy másik session adatához hozzájussak. Gyakorlatban ennek az esélye elég kicsi, hisz szép hosszú ID-ról van szó. Ennél neccesebb lenne ha közvetlenül cookie-ban tárolnád a login infót, mert akkor enyém a világ.
    Azonban a sessionid is nyíltan utazik a kliens és a szerver közt, minden egyes post és get eseménynél. Így a cleartext jelszóhoz hasonlóan ez is olvasható és akár beírható a cookie-ba (elvileg persze).
    Mutasd a teljes hozzászólást!
  • https
    Ehhez gondolom azért programozási oldalon is van teendőm, pláne ha csak a bejelentkezést merem megfékezni.


    Igazából nincs, ez inkább üzemeltetési feladat. Programozási feladatod csak akkor van igazából, ha csak a bejelentkezésnél akarod használni, mert akkor php-ból nem árt ellenőrizni, hogy tényleg https-en keresztül próbálnak belépni (súgok: $_SERVER-ben nézz körül!), de apache-nál .htaccess-ben is megoldhatod, hogy a bejelentkezés csak https-en keresztül működjön.
    Mutasd a teljes hozzászólást!
  • Flood védelem- nem engeded hogy a jelszót próbálgatással törjék fel, pl egy IPről percenként csak 15 próbálkozást engedsz meg, vagy ilyesmi.

    Saját ürlappal menjen- igen, valami biztonsági kódot kell generálni a form-ba, és azt is elküldeni, ha szerepel az adatbázisban akkor jó, amugy nem.

    chapta- helyesen captcha :) ez a kis kép, ellenőrző kód, amit be kell irni bejelentkezéskor. Mondjuk loginkor engem kifejezetten idegesít, regisztrációkor jó.
    Mutasd a teljes hozzászólást!
  • SESSION-nal hogy csak a saját űrlappal menjen.

    -Ha ez alatt azt érted, hogy az index.php generálja a bejelntkező form-ot akkor OK

    Flood védelem

    -Ez nem tudom micsoda, de utána keresek...

    MD5

    -Igen, a topic nyitása óta okosodtam: tehát ez az hogy a felhasznalok táblába nem a jelszót hanem annak md5 lenyomatát tárolom. Bejelentkezéskor pedig a form-ról bejövő jelszót is md5-tel elkódolt értékét vetem össze a táblában lévő hash-el.

    mysql_real_escape_string

    -Ezt már PredMan is javasolta. Köszönöm a jótanácsot: megfogadom.

    https

    Ehhez gondolom azért programozási oldalon is van teendőm, pláne ha csak a bejelentkezést merem megfékezni. Kifejtenéd, hogy hogyan csinálnád?

    chapta

    -Ezt szintén nem tudom, hogy micsoda, de utána nézek.

    Köszönöm a segítséget!

    Egyébként célul tűztem ki, hogy az itt (és máshol) tanultakat a témában összefoglalom és így talán vissza kerülhet a topic a tudástárba. -Moderátor?

    További szép napot!
    Árpád
    Mutasd a teljes hozzászólást!
  • SESSION-nal hogy csak a saját űrlappal menjen.
    Flood védelem
    MD5
    mysql_real_escape_string
    https
    chapta

    Majdnem kapásból
    Mutasd a teljes hozzászólást!
  • Korrekt?

    Úgy tudom, az űrlapok adatai nyíltan, bármiféle titkosítás nélkül mennek a dróton.

    Az lenne a minimum, hogy a bejelentkezés "https://..." URL-en keresztül történjen. A többi is jön majd...
    Mutasd a teljes hozzászólást!
  • sztem ez így korrekt, még ennyi hiányzik: mysql_real_escape_string

    ezt a bekérésnél mindenképp használd.
    Mutasd a teljes hozzászólást!
  • úgy érzem hogy ez társalgó téma lenne :)
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Gondolom a rutinosoknak a következő kérdésem lerágott csont, de én minnél tovább olvasgatom az idevágó topic-okat annál jobban összezavarodom.

    Arra szeretnék választ kapni, hogy a következő autentikációs folyamat miért nem biztosságos, és hogyan lehet növelni a biztonságát:
    1.)HTML Form: felhasználónév/jelszó bekérés;
    2.)Adatküldés a szervernek cleartext (ez biztos necces);
    3.)PHP lekérdezi az SQL szerver felhasznalok táblájából, hogy a felhasználónév/jelszó érvényes-e;
    4.)Ha igen a PHP felveszi a $_SESSION-be az autentikációs bejegyzéseket és ennek megfelelően fut tovább a program.

    Bocs a láma kérdésért, de az idevágó topic-ok legfeljebb a technikákkal (hashelés/sózás) foglalkozik, a folyamat áttekintéséről azonban nem találtam bejegyzést.
    Köszi!
    Árpád
    Mutasd a teljes hozzászólást!
abcd