jelszó kezelés + http

Internet: PHP, CGI, stb.

Sziasztok!

Ki hogy oldja, oldaná meg http esetén, hogy a jelszavak ne legyenek könnyen ellophatóak a hálózaton pl. nyilt wifi,....
Mer ugye sokszor u.a. a jelszót használják sok helyen.
Jelenlegi elképzelés szerint js md5(jelszo) és azt küldi el.

Van értelme, 2xmd5 kliensoldalon és azt küldeni, vagy session "id" generalni, és azzal együtt hasselni md5(md5(js).id)?

  • 1538 megtekintés

( uid_194 | 2011. 02. 07., h – 19:24 )

redirect https-re :P

Onnantol, hogy barmi jelszobol generalt dolog atmegy httpn, mar gond van. Legfeljebb toldozni-foltozni tudod, de a vegen ugyis https fele kell majd elmenni.

--
|8]

Jó lenne ha lenne, de hozott anyagból keverem a masszát :)
---
Egy anlgaii etegyem ktuasátai szenirt nem szimát melyin serenrodbn vnanak a bteűk egy szbóan, az etegyeln ftonos dloog, hogy az eslő és az ultosó bteűk a hölyeükn lneegyek. A tböbi bteű lheet tljees össze-vabisszásagn, mgiés porbléma nlkéül oalvsahtó

( zeller | 2011. 02. 07., h – 20:17 )

Első jelszó megy e-mailen, hash szerveren lerak táblába. Első jelszónál kötelező jelszócsere.

A jelszóbekérő oldalnál megy egy hidden mezőben egy salt string, a password mezőt js-ből rakom össze:
hash(salt+hash(beírt_jelszó)).
A szerveren megcsinálom a fent lévő hash-sel ugyanezt, ha egyezik, jöhet, ha nem, elhajtom.

Jelszócsere esetén meg a régi jelszót bekérni, az abból készült hash-t használva kulcsként lehet titkosítani a felküldendő adatot, ami tartalmazza a régi hash-t meg az újonnan beírt jelszóból generált hash-t is. (Az újat kétszer beíratni, ellenőrizni szintén js-ből, hogy azonos-e, hossz, bonyolultság, egyebek, erre nem térek ki). Ami lényeges, hogy a form elküldése előtt a regi_jelszo meg az egyik uj_jelszo mező értékét js-ből töltsd fel n darab csillaggal, a másik uj_jelszo mezőbe meg "tedd bele" a titkosított adatokat.
Amikor fölér a "csomag, a régi hash-t használva decrypt, ha az első fele azonos a régi hash-sel,a kkor a második fele eltárolandó, mint új hash.

A fentiek kellemes mellékhatásaként az user hiába menteti el a jelszavát a böngészővel, ott már a hash-selt, illetve titkosított lom fog szerepelni, úgyhogy minden alkalommal be kell írnia a jelszavát...

Van js-ben implementált md5, sha1 meg des/3des, én azt használtam - sajna ezt most mind fejből írtam, lehet, hogy valami nem kerek - régen volt, de remélem elindulni elég.

Ha a szervernek van kapacitása ssl-t számolgatni minden csomaghoz, akkor talán. Anno az adott környezetben nem volt cél ssl-re terelni a teljes többezres felhasználói kört. És még egy feladat volt: a böngészvel NE lehessen elmenteni a jelszót. A workaround az lett, ahogy látszik is, hogy a jelszó tipusú mezők tartalmát elküldés előtt jól megmogyoróztam js-ből, úgyhogy ami elmentésre került, az már a "mogyorózott", és nem a beírt jelszó lett, úgyhogy legközelebb hiába töltötte ki a browser a mezőt, az onsubmit eseménykezelő azt újramogyorózta, és persze, hogy nem stimmelt :-)

Minthogy céges belső, illetve szerződéses partnereknek készült portálról volt szó, így ez is, meg sok egyéb is előírható volt. Az ezt megelőző http-basic auth-hoz képest messze biztonságosabb és többet tudó megoldást raktam le anno az asztalra ezzel a cuccal. A teljes speckót/funkciólistát nem részletezem - elég méretes lett az a pár pl/sql csomagocska, ami ezt csinálta...

A kliensen másra is használni szerettük volna a js-t, ergo az volt az egyszerű, ha be sem tud jelentkezni js nélkül :-) Ráadásul volt még vagy két tucat "must have" funkció/paraméter, amit tudnia kellett a cuccnak - mindezt úgy, hogy a szerver-oldalon eléggé meg volt kötve a kezünk, hogy mit lehet, és mit nem lehet megcsinálni az adott eszközzel.

Kösz ez tetszik, a sózást én session sütivel gondoltam, de ez a hidden data jobb lesz nekem érzem :).
Jelszó csere most nincs, pár user van csak a dinamikus adatok kezeléséhez, majd db-ből átírom ha kell. De tetszik az 5let.

---
Egy anlgaii etegyem ktuasátai szenirt nem szimát melyin serenrodbn vnanak a bteűk egy szbóan, az etegyeln ftonos dloog, hogy az eslő és az ultosó bteűk a hölyeükn lneegyek. A tböbi bteű lheet tljees össze-vabisszásagn, mgiés porbléma nlkéül oalvsahtó

Nincs mit, anno elég sokat törpöltem rajta, mint írtam, eléggé régen volt, és csak emlékezetből írtam - érdemes minden lépést átgondolni, hol, milyen információ van meg, milyen nincs, miből, mit lehet kinyerni, mi van, ha valaki fals adatokkal próbálja megetetni a szervert, a klienst, mi van akkor, ha valaki "újrajátszással" próbálkozik...

( nrgie | 2011. 02. 07., h – 20:35 )

https kötélszakadás esetén ezt ajánlom :

http://www.jcryption.org/

Használtam, használom, jó. Csak ráengeded a login form-ra és a backenden dekódolod, érdemes alacsony RSA-t használni (256 bit), mert elég erőforrás igényes, de a semminél csak titkosabb...

No igen... Ha akkoriban, amikor sok évvel ezelőtt ezzel foglalkoztam, lett volna ilyesmi... Akkor a des.js meg az sha.js, md5.js összevadászása sem volt semmi... Egyébként itt találtam rá a szükséges dolgokra: http://pajhome.org.uk/crypt/md5/ (erre biztosan emlékszem) meg talán itt: http://www.tero.co.uk/

Azóta biztos fejlődött a google is. Mindig abból indulok ki, hogy már valaki megírta azt ami kell nekem, csak megkell találnom. 99%-ban meg létezik is.

1 kivétel volt eddig amire konkrétan nem találtam választ a neten, de saját implementációt csak sikerült összehozni. (Egy ajax-os site reload (F5) után visszatöltse az utolsónak megtekintett oldalt.)

( Dacr (nem ellenőrzött) | 2011. 02. 07., h – 21:53 )

Logikai kérdés:
ha már hash-elve küldöm a jelszót a szerver felé (pl.: egy javascript-el előállítva a jelszóból), s azt "kapja" el valaki, akkor ugyanúgy birtokában vannak a belépéshez szükséges adatok, csak egy scriptet kell írnia, ami azon hash-t elküldi a szerver felé. Vagy rosszul logikázok?
Nekem a https inkább biztonságosabbnak tűnik.