[kristoaun]

Kuidas ikkagi üks korralik autentimine käib?

kasutaja sisestab input väljadele kasutajanime ja parooli
kui välja väärtus muutub tehakse hidden väljadele sha1 hash javascriptiga.
kui kasutaja vajutab submit, siis puhastatakse kasutajale nähtavad väljad ja alles jäävad ainult username ja passwordi sha1 räsi.
php'ga kontrollin mysql tabelist kas sqlpassword = htmlpassword ja sha1(sqluser) = htmluser.

Ja siit edasi ei oska nagu midagi tarka teha.

Variandid:
htaccessiga turvatud login areasse suunamine. Ei taha, sest see on failipõhine ja .htaccess ei pidanud eriti turvaline kah olema (fail pidi liiga kergesti kättesaadav olema).
$_SESSION['kasutajaonsisseloginud'] = TRUE ja constjah = TRUE ei taga ju seda et loginkaustas olevad failid on kättesaamatud...
Siis on veel ID-kaardiga võimalus, aga see eeldab SSL serdi olemasolu (kui just oma serverit pole). Ja ma pole eriti süvenenud kah kuidas see täpselt käib. Teoorias tean.

Kas peaks mingi kombinatsiooni tegema?
Kuidas teised teevad?

Kahtlustan et siit tuleb ilmselt pikk teemaarendus .

[mikk36]

kui kasutajainfot ei pea turvaliselt üle interneti kandma, siis edastad selle puhtal kujul ja teed serveris vastavad arvutused/tehted sellega, et võrrelda andmebaasis olevaga
kui on vaja turvaliselt, siis kas javascript äärmisel juhul või juba ssl
serveripoolne autentimine siis on muidugi juba eraldi teema, et kindel olla, et keegi kuidagi sisse ei saaks häkkida

[kristoaun]

aga mida ikkagi ette võtta. Kuidas talletada infot et kasutaja on ennast sisse loginud?

[LWD]

Kui kasutajanimi ja salasõna klapib, siis teed suvalise stringi.

$kood = md5($_POST['user'].microtime(true));
Peaks küllalti unikaalne olema, sest süsteemis korduvaid kasutajanimesid ei tohiks olla ja võõrastel pole ka lihtne ära arvata millisekundeid

$_COOKIE['kasutaja'] = $kood;
setcookie('kasutaja', $kood, time()+40000, '/');
session_register($kood);
$_SESSION[$kood]['userid'] = $userid;
$_SESSION[$kood]['ip'] = $kasutajaip;

Ehk salvestad kliendi arvutisse küpsise selle sama unikaalse stringiga. Igakord, kui keegi pöördub serverisse kontrollid if (isset($_SESSION[$_COOKIE['kasutaja']]) && $ip==$_SESSION[$_COOKIE['kasutaja']]['ip']). Süsteemi saab murda, kui ära arvata kood ja muuta oma IP samaks kui oli kliendil, kes logis sisse.

IPd ei saa samaks muuta ja koodi äraarvamise tõenäosus on 0

[linnumees]

[lehm2]

parooli krüptimisel ära kasuta sha1-te ega md5, kasuta sha256 või sha512. Hea on kui lisatud saab ka salt parooli.

[kristoaun]

parooli peaks ikka krüptima. inimesed ju kasutavad samu sõnu igal pool. Siis vähemalt ei saa salasõna teada. Ja teiseks ei ole ka portaali omanikul mingit õigust vaadata, mis salasõna kellelgi on...

ma tegin sellise variandi, et kui sisselogimisandmed klapivad, siis mysql baasis kasutajate tabelis pannakse status = login ja algusaeg. Seega saan ma kasutajat suunata failipuus suvalistesse kohtadesse ja pärast saab kontrollida kas tal ikka on õigusi. ja kontroll käib PHPSESSID järgi...

session_register kaob vist php6's ära ja see pidi olema ebaturvaline...

nüüdon veel 2 küsimust.
Kuidas kaitsta failipuu salajast osa?
- ikkagi htaccessiga tuleks seda teha. phpclasses.com'is ei olnud normaalset koodi htaccessi ja htpasswordi muutmiseks. Peab vist ise kirjutama

Kuidas teada saada, millal kasutaja on välja loginud.
- Kas siin peaks mingi cron kontrollimise tegema?

[linnumees]

[nene]

Kõige olulisem on siiski see, kui kõrget turvalisust su lehekülg tegelikult vajab. Ehk siis kui tundlikud on need andmed, mida sa kaitsed? Turvalisus on alati tradeoff kasutusmugavuse ja andmete kaitstuse vahel. Mida suuremat kaitstust soovid, seda rohkem pead ohverdama kasutusmugavust, ja vastupidi. Aga see kõik oleneb sinu konkreetsest juhtumist.

Üht võin ma aga öelda: JavaScriptiga parooli krüptimine ei muuda su lehte grammigi turvalisemaks, üksnes langetab kasutusmugavust.

[kristoaun]

kui parool on JS'ga krüptitud siis üle neti (jumal teab läbi mitme masina. ja pealtkuulaja võib olla igaüks neist) saadetakse hash mitte parool ise.

Aga ma ei saa aru, mismoodi see kasutusmugavus langeb kui ma JS'ga olen krüptinud. Okei kiirust jah nats, aga see ei ole midagi märkimisväärset, mis kulub arvutamisele/pööramisele

[linnumees]

See ei takista ju mingit pidi sinu lehele sisselogimist.

[zimm]

ma isiklikult ei ole veebilehtede kirjutamisega tegelenud, kuid kliendipoolne hashimine on imho väga korralik turvaauk.
nimelt, kui hash lekib (kas sinu andmebaasist või samade algoritmidega teistest andmebaasidest), siis saab häkker kasutada üksnes hashi edukaks sisselogimiseks (javascripti asemel paneb ise õige jada teele). teada on, et korraliku algoritmi puhul on dehashimine väga-väga pikk ja kahtlane protsess.
kui kasutad serveripoolset hashimist, muutub sinupoolne vastutus väiksemaks kui omad ise korralikult kaitstud serverit. kliendi mure on andmed turvaliselt üle interneti sinuni toimetada. sina saad turvalisust tõsta SSL kasutamisega.

aga nojah, see on minu tagasihoidlik arvamus asjast, pole üldiste tavade ja standartidega tutvunud.

[nene]

[da3rX]

Serveripoolseks paroolide räsimiseks soovitan kasutada phpass'i.
Hoia kasutaja infot serveris (kasuta küpsiste asemel sessioone).
Soovitan kontrollida ka kasutaja IP aadressit ja brauserit (HTTP_USER_AGENT). Vaevalt need kasutaja sessiooni käigus muutuvad.

Vältimaks parooli vabalt üle võrgu saatmist võib kasutada HTTPS'i.

[kristoaun]

kui paljudel on JS keelatud? pakun et 1/10000

[XYZ]

[mikk36]

XYZ, ära nüüd nii pessimist ka pole, tegelikkuses on väga vähestel keelatud
mingid domeenireeglid annavad ju väga minimaalse osa (lisaks siis vähestele paranoilistele inimestele) kogu internetikasutajatest (ja vähestes domeenides on keelatud js)

[nn3_]

[linnumees]

No aga seda mõtteviisi võiks ju siis ka turvalisuse osas rakendada - palju neid ründavaid kasutajaid ikka on...

[lehm2]

jah Eestis on protsent suur, kuna suuremad lehed näiteks pank on põhiliselt paljutki JS peal ehitatud. Kuid selline vaidlus ei vii kuhugi. Minu arust tuleks siiski teha server-side variant

[XYZ]

Saab ka ainult pangale JS lubada ja kõikjal mukal keelatuna hoida. Mida statistika sel puhul asjast arvab ma ei tea.

[d3t]

XYZ, tahaks meelede tuletada et HV kasutajskond ei esinda maailmat ega eestit. On olemas grupp inimesi kes on teistest vähekene rohkem targemad, ent valdav enamus ei vaevu selle javascripti peale mõtlema ka mitte, mis tagabki selle suure kasutatavuse.

[maxorator]

Kui salasõnaga tõesti pääseb ligi salastatud riigidokumentidele, siis tuleks kasutada SSL protokolli. Vastasel juhul on tavaline andmete ülekandmine täiesti piisav. Seda enam, et Javascriptiga krüpteeritud/hashitud andmeid võrgust vahelt pätsates saab lehele sisse ka tegelikku parooli teadmata, saates lihtsalt sellesama info.

[gynterk]

Minu arust on SSL-i kasutamine autentimisel tänapäeval elementaarne, sest turvarisk on ikkagi suur, olenevalt, mis andmetega tegu on. Kasutaja ja serveri vaheline ühendus peaks kindlasti olema SSL-i proto kaudu. Serveris, kas kasutaja on juba sisse logitud või mitte, on asja lihtsam lahendada. Teha MySQL tabel antud kasutaja id-ga ja panna sama ka sessiooni ($_SESSION['id'] või mida iganes), ja visata hunnik kontrolllahtreid (kasutaja id, sessiooni id, ip, browser, +[mingi kindel unikaalne koodisüsteem]). Kindlasti lisada ka mingi time-out variant (a. la kindla aja pärast sessioon lõpetatakse, st kasutaja kustutatakse tabelist)[mul istub see cron-is]+küsija(kasutaja) poolne (st et kui login tabelist küsitakse seda ID-d siis kontrollib möödunud aega, kui eksisteerib tabelis).

[tanzanite]