Menjava CMS - migracija uporabnikov (da/ne?)

4 naročniki

Pozdravljeni,
zanima me vaše mnenje glede sledečega.
Imam 3 aktualne projekte (spletne trgovine), kjer se menja CMS. Stara CMSa uporabljata različno zgoščevalno (hash) funkcijo, kot jo uporablja novi, zato gesla niso prenosljiva. V novem pa se z enim email naslovom lahko naredi samo 1 račun.
Torej imam 2 opciji:
1. migriram uporabnike, le-ti pa morajo pred naslednjim nakupom nastaviti novo geslo (s pomočjo funkcije "pozabljeno geslo").
2. migriram podatke uporabnikov samo v tabelo naročil (torej njihove podatke se zapiše k naročilom, tako da evidenca naročil ostane enaka) in pustim opcijo, da si vsi nadaljni uporabniki naredijo nov račun.

Ne vem, kateri način je boljši. V obeh primerih bo nekaj slabe volje...

V tabelo uporabniki dodaš polje isold_hash in normalno migriraš.

Potem pa v CMSju preverjaš, če je isold_hash nastavljen in če je, uporabiš staro funkcijo.

Nobene slabe volje s to rešitvijo. Seveda pa vse nove registracije delaš po ta novi hash funkciji.

Ja to bi nekako šlo. Samo pri tem imam pomislek glede varnosti, saj stari sistemi uporabljajo večinoma sha1 (ali celo md5), kar je precej zastarel/pomanjkljiv koncept preverjanja pristnosti (rainbow tabele). Ena od trgovin (oscommerce 2) je bila pred časom tudi shekana.

No, potem pa tistim ki imajo isold_hash == true, ob loginu predstaviš okno z opcijsko nastavitvijo novega gesla (zraven pač napišeš da za voljo varnosti naj si zamenjajo geslo). Pomembno pa je, da ne nadleguješ strank s tem - vse mora bit opcijsko.

Ko to naredijo jim daš isold_hash na nulo in jim hashiraš po novem algoritmu.

In motiš se, da sta sha1 in md5 pomanjkliva - za to kar jih ti uporabljaš sta še vedno ne zlomljena. Pri md5 vem da je zlomljen samo colision resistance, to pa pri tebi ne pride v poštev.

Se strinjam, bom implementiral tako kot si opisal.

Glede sha1, mislil sem na to, če je bila (ali bognedaj v prihodnosti bo) tabela uporabnikov odtujena lahko z rainbow tabelami dobijo string, ki ima enak hash rezultat.
Kakorkoli, preprosta hash funkcija je pomanjkljiv pristop.

Ravno te dni to delam. En lep notification pokazes in zahtevas password reset. Odvisno odplatforme, nekje lahko za to uporabis kar forgot password formo, samo v temi spremenis izpis. Nic hackanja cora, juzer dobi nov pass in vse je lepo secure.

Spinx, ti torej ne bi naredil podpore za kompatibilnost hashov ampak raje prislil uporabnike, da ponastavijo gesla?

To, da sta MD5 ali SHA1 pomankljiva se zdalec ni res.

Pomankljiva je varnost tvojega CMS sistema in pa uporabnikovega gesla.

Ce uporabniku zatezis za dovolj mocno geslo (npr. da vsebuje simbol) naredis ze dober korak.

Da se malo pokomentiram nacine shranjevanja gesel se mi najbol neumen zdi nacin pass+salt, ker se ga itak brez problema dobi iz baze.Zdaj pa tudi 90% novih crackerjev vsebuje salt support.

Idealn nacin za mene bi bil, da v config.php datoteki pustis nek daljsi master password(ki je drugačen na vsakem sajtu) in vsak password kriptiras z md5($master.$pass);

Torej ce se ze napadalec dokoplje do baze prek SQL Injection-a ne bo mogel dešifrirati passworda brez master passworda, ki ga ni v bazi.

Seveda bi se dalo zadevo zaobidet npr z load_file ampak verjamem, da je bolj varno kot pa plain md5.

LP

Problem pri nas je še ta, da nimamo dostopa do baze in kode prejšnje platforme, vsak uporabnik pa ima svoj salt za geslo. Nimam kaj podpirat.

Prosim da boljše prebereš in da ne obsojaš česar nisi niti videl.

Nisem rekel, da sta MD5 ali SHA1 pomanjkljiva algoritma ampak sama po sebi pomanjkljiva pristopa za avtentikacijo.

Rezultat zgoščevalne operacije, kljub vsem čira čara in byte shiftanju, bo vedno alfanumeričen string, katerega protivrednost dobiš s pomočjo rainbow tabele.

To je offtopic, sprašujem zaradi uporabniškega vidika, zato tema ni v forumu "Programiranje".

Tudi rainbow tabela ni nek čirulečarule. Še vedno če je geslo dovolj dolgo bo kul.