U situaciji kada ti neko ukrade te lozinke, onda ih bruteforce-uje i nakon toga opusteno pristupa tim nalozima kao da se radi o regularnim korisnicima. A pri tom to ne znaju ni admin ni vlasnik naloga.
To je jedan od slucajeva npr.

Hm, kad je neko admin, sve mu je dozvoljeno, ovaj scenario koji si naveo je skroz realan.
Cuvanje hesh vrednosti u ovom slucaju ne dopirnosi sigurnosti, ali samo onemogucava adminu da bas sazna koja je lozinka.

Aha, ovako bi morao svaki put da fizički pristupa računaru i kopa po kućištu, a recimo da nema uvek tu priliku. Prilično mala vajda od heševa.



Koja mu nije ni potrebna.

Ako potencijalni napadač nema pristup računaru i verujemo administratoru, šta će nam onda uopšte lozinke?

Ok, za pocetak premisa ti je malo iskrivljena.

Ako za trenutak zanemarimo fizicki pristup, u svakom iole ozbiljnom OSu takvo unistavanje dokaza je neizvodljivo bez pisanog traga. Admin u takvom sistemu ne moze tek tako da usnimi stari hash u sec bazu jer ista njemu nije logicki dostupna za pisanje nista vise nego sto je dostupna drugom useru. Obicno se to implementira kao exclusive lock u kernelu i centralizovani upis/zapis kroz neki API. Dakle jedini nacin da admin ubaci stari hash umesto novog koji je napravio promenivsi lozinku je da ZNA plaintext stare lozinke )cto ceo proces zamene passworda cini nepotrebnom). Ako se secas svojevremeno je postojala alatka zvana l0phtCrack cija je to bila namena (iz WIndows NT SAM baze je cupao DES hasheve i onda bruteforceovao lozinke da otkrije plaintext). A cak iako zna stari plaintext audit pamti sve akcije i jedini nacin da admin sakrije sta je radio je da obrise logove (za sta opet postoji pisani trag). A jedini nacin da admin napravi neko sra*je a da se to ne moze povezati sa njim ni na koji nacin je da ZNA unapred tvoju plaintext lozinku i zato se ona ne pamti. Dakle HASH zato sto NE VERUJEMO adminima na rec kao generalno pravilo.

E sad, fizicki pristup, to je posebna kategorija, lock vise ne vazi (i za l0phtcrack si morao da rebootujes sistem van windowsa i da mountujes sistemski disk i da napravis kopiju SAMa). Svako ce ti reci da jednostavno taj nivo sigurnosti ne postoji sem sa nekom preboot kriptografijom (tipa truecrypt, ali i sa true crypt ne sprecavas admina koji zna preboot password da disk mountuje na drugoj masini, sprecavas samo nekog ko ukrade/iskopira sa strane). Sve ostalo se moze uz manje ili vise umesnosti iscupati iz sistema, cak i signing algoritmi tu ne rade jer negde mora da bude i signing kljuc, itd, itd. Tu leka jednostavno nema i zato je vazna kontrola fizickog pristupa AD/LDAP/DC masinama. Nista se nije promenilo na tom polju decenijama, cike sa puskama su i dalje najbolji firewall

Nema fizički pristup računaru, ali može da pokuša da se loguje na njega kao udaljeni računar preko mreže.

Isto to bi bilo primenljivo i kada bi se pamtila sama lozinka umesto heša. Sistem neće nikome, pa ni adminu da kaže lozinku koju (sistem) zna. Nema pristupa niskog nivoa disku nisakakvim privilegijama zato što je takva logika sistema i to je sve.

U tom scenariju opet ne vidim funkciju heša.

Pa imas i taj aspekt masovne keadje lozinki pri fizickom pristupu. Ti polazis od stanovista da napadac ima visestruki pristup da moze da odradi tvoj scenario. A ako ima one-time priliku za fizicki pristup nece raditi to sto si naveo vec ce marnuti SAM bazu. Uz dobar password reset policy dok napadac bruteforce-uje lozinke one ce sve vec biti promenjene. Ako su plaintext ima ih odmah na raspolaganju.

upravo tako

generalna ideja je da , ako dodje do proboja sigurnosti, napadac ne moze direktno da povrati sifru
koju korisnik potencijalno koristi na jos n mesta (svi to rade), vec mora da bruteforce-uje , ako vec moze da "digne" hash-eve , moze i da ih promeni , ali to se da primetiti
ali cak i u tom slucaju , napadac je ogranicen na iskoriscavanje proboja sigurnosti samo na datu aplikaciju/sistem , u slucaju plain text sifri , napadac "dignute" sifre moze da koristi za druge aplikacije/sisteme na kojima je korisnik koristio istu sifru (realno cest slucaj kod manje opreznih korisnika, koji su u vecini)



inace, l0phtcrack je vaskrso , sada ga naplacuju ... mada mi nikada nije bio jasan hype oko te alatke ...

evo jos jednog interesantnog pitanja za razmisljanje,

svi browseri enkriptuju sifre koje im kazete da zapamte pri logovanju na neki sajt
ali nema nikakve tajne za dekripciju (osim ako ste postavili master password u firefoxu recimo)
ko god dodje do baze sa enkriptovanim siframa , dekriptuje bez bruteforce-a
koja je ovde poenta?

jednostavno , dodatni nivo (doduse tanak kao palacinka) sigurnosti


edit:
hmm , interesantno , chrome to radi pomocu CryptProtectData win APIa
znaci vezuje ga za masinu i user-a slicno kao enkriptovanje datoteka na NTFSu
ne znam za ostale

Pa, može. Vraćanjem starog heša u bazu stara lozinka postaje važeća.

da, moja poenta je bila zastita lozinki , koje se cesto koriste na vise mesta ...
cuvas klijenta od sopstvene gluposti

Da.

A + je dobro koristiti password salting. Ako na neki način napadač dođe do hash-a passworda, bruteforce će ići "malo" teže.
Naravno, podrazumeva se da napadač nije došao u posed samog salt-a.

Koliko ja kapiram, salt ne pomaze nesto posebno kod bruteforce napada vec iskljucivo sprecava koriscenje rainbow tabela.
Za dodatno otezavanje bruteforce moze da se koristi key stretching. Jedan od najboljih algoritama je bcrypt razvijen od OpenBSD ekipe.

Da, u ovom slucaju salt ne pomaze jer kako napadac pokrade hasheve pokrasce i saltove. Salt ima veoma specifican scenario koriscenja koji podrazumeva da user zna lozinku a da se hash koristi u "divljini" (npr web cookie, state i slicno)

Ako npr. kompromituje bazu sa hashevima, a salt se nalazi u fajlu do kojeg ne može doći (tek tako), onda nema 'leba.

I master pass mora da se ukuca da bi se koristili ostali, tako da ako neko vec ima pristup ostalim, nije mu problem ni da pomocu npr. keylogger-a otkrije master...

A kada je to u praksi slučaj?

nikad veroavtno,

kao sto je vec receno , salt je tu da stiti samo od rainbow tabela ,ne sprecava bruteforce



ne mora da znaci, mozda je db s lozinkama pokupio sa diska van sistema
ako ima keylogger, ni ne treba mu da skuplja sifre zar ne?

Pa, eto, meni se desio jedan takav "incidenat", pa otud i pišem.
Da sam saltovao, ne bi bilo proboja, ovako je ispao problem.

Ne znam koliko je verovatno, ali eto, događa se :\

ne, cekaj

na koji nacin mozes da zasitis salt , ako su hash-evi vec kompromitovani?
zasto na isti nacin nebi stitio i hash-eve?

Problem je u dizajnu LCMS-a Moodle.
On omogućava po defaultu da nastavnici bekapuju svoje kurseve, ALI uz to i podatke o korisnicima!! Znači, hasheve passworda korisnika!
Nezgodno, je l' da?
I onda taj ko je bekapovao može da brutforsuje lepo. Do salta teško može doći, ali je damp baze dobio.

Jeste to propust softvera (ali i administratora, naravno), i možda marginalna dobit od salta generalno, ali naveo sam primer koji se zbilja dogodio.

pa da je koriscen slat, i on bi bio u backupu
jer je neophodan za funkcionisanje sistema nakon restorovanja sa backupa, zar ne?

Sad, možda ja nešto ne kontam :\
Bekapuje se npr. kurs, znači potrebni fajlovi iz nekog tamo direktorijuma + određene tabele. Salt se nalazi u nekom config fajlu na veb-serveru koji se ne bekapuje.
Bekap celokupnog servera je obaška, pričam o delu koji samostalno može da izvrši neko sa ulogom nastavnika, a on ne obuhvata salt.
Salt ostaje, a posle ako treba da se vrati, vrate se samo hashevi, to se posle opet "spaja" i koristi.
Glupo je ispalo (a možda su i ispravili u 2.0) što se bekapuju ne samo ID-evi korisnika sa kursa, nego i password polje. Ne znam zašto, to i jeste pitanje.

to je propust u dizajnu aplikacije definitivno

Salt je siguran najviše koliko i baza heševa lozinki. Kao što je rečeno, on štiti od rainbow tabela, jer niko nema rainbow tabelu za tvoj salt. Tada salt može komotno biti i javan. Takođe, može se za svakog korisnika generisati poseban salt, koji se može menjati prilikom promene lozinki. Tada pravljenje rainbow tabele za taj salt nema nikakvog smisla, jer se odnosi samo na jednu lozinku.

Kako god. Samo sam izneo svoje iskustvo ... tako se zalomilo


Tačno tako.

Ok to za van sistema, to jeste prednost. Ali ako je npr. pokupio iz sistema, nema nekog znacaja taj master pass (u slucaju da je sistem ugrozen nakon unosa sifri u FF - keylogger ne pomaze za vec zapamcene, ali od tog trenutka pomaze otkrivajuci master)

Manje vise isto (sa i bez), aj' da se kaze da je malo bezbednije s master pass-om

Pa ako neko ima potpuni read/write pristup bazi - zaista ne vidim zašto bi se uopšte maltretirao sa mjenjanjima hash-eva i slično kada u tom slučaju može direktno pristupiti podacima u bazi i mjenjati ih...

Hash nije ni projektovan da štiti od takvih suludih slučajeva, ali je i dalje dobro osiguranje za mnoge druge sigurnostne slučajeve... Ako neko dobije dump baze i dalje ne zna plaintext lozinku i ne može da se uloguje i mjenja podatke ili da im pristupa u budućnosti...

Bruteforce uopšte ne ide brzo i lako kako neki ovdje misle - uz dovoljno dugačku i raznovrsnu šifru (npr "12 kArakt€r4") - bruteforce nije praktičan ni na najjačim kompjuterima (bruteforce kalkulator - http://lastbit.com/pswcalc.asp)...




Inače - ako ti je cilj da postaviš neke podatke na server - ali da niko - pa čak ni administrator tog servera ne može da im pristupi - postoji i rešenje za to... lastpass npr koristi neko takvo rešenje... Svi tvoji podaci su enkriptovani lokalno (plugin ili javascript ako se koristi sajt)... Za logovanje - serveru prosledjuješ lokalno napravljen hash(username@password) (koji onda vjerovatno i server još jednom hashuje pre upisivanja /poredjenja sa onim u bazi), a za enkripciju - lokalno nešto tipa hash(password@username@password) (namjerno drugačije od onoga što prosledjuješ serveru)... Ima nekoliko članaka na netu gdje su ljudi snifovali pakete, pregledali javascript kod i zaista otkrili da je sve sigurno i enkriptovano...

@Nedeljko

Recimo, svaki covek vremenom razvije svoj sistem za definisanje lozinki (da ne pominejmo najcesci slucaj, kada koriste jednu za sve). Taj sistem je jasan za prisecanje u glavi, ali je najcesce vrlo providan kada bi se stavio crno na belo. Administrator koji bi pred ocima imao listu alfanumerika, bez puno muke bi provalio i ostale lozinke za javne servise, forume i sl. A nije administrator na njima.

Mozda taj scenario poboljsava sigurnost?

Sto bi se vlasnik/autor jednog sistema brinuo za lozinke na drugim sistemima? :)

Mozda bi zloupotrebio/prodao :) Nekako, kada lozinke nisu bas na izvolte ocima (adminovim ili njegovih gostiju), to je samo po sebi jedan vid zastite.

bruteforce ide odlicno brzo za hash-eve jer su i hash f-je dizajnirane da budu brze
sta mislis koji procenat ljudi ima tako "jake" sifre?




javascript crypto? molim vas, budimo ozbiljni

Ne, hteo sam reci, zasto bi onaj ko pravi jedan sistem trudio da zastiti password-e zbog nekog drugog sistema. Sta ga briga :)

@earthquake - pa npr. 500 000 pokušaja u sekundi i jeste strašno brzo - pa bi opet bile potrebne hiljade godina da se probiju jake šifre duže od 10ak karaktera...
To što mnogi koriste mnogo slabije šifre (prema jednoj analizi provaljene baze šifara - najčešće korištenih 1000 šifara koristi 20% ljudi) nije tema ovdje...
Javascript sasvim odlično obavlja posao za ovako proste zadatke tipa lastpass-a gdje je ukupna količina podataka možda koji kilobajt... Ne bih sad baš očekivao da će mi u real time-u dešifrovati video stream i prikazivati mi ga u browseru... Uostalom - enkripcija se na kompjuterima koristila i pre 30ak godina - a sada i u sporim browserima javascript radi brže nego tadašnje nativne aplikacije...

@Shadowed - vjerovatno se zato još uvijek u mnogim po potrebi napravljenim sistemima još uvijek koriste plain text šifre - ali svi sistemi koji se prave za veći broj korisnika skoro uvijek koriste hashove, jer ne košta ništa a sigurnije je... Uostalom - kao što rekoh - to povećava sigurnost i sopstvenog sistema - jer ako neko dobije neki dump baze - to mu ne omogućava da sistemu pristupa u budućnosti i ne moraš tjerati sve korisnike da mjenjaju šifru (mada je i tada preporučljivo)...

nije mi bila poenta brzina izvrsavanja javascript-a
vec sam javascript kao jezik, za pocetak, nema pravi sigurni PRNG