Why Does Everything Get Hacked?

To je snake oil, nikome, a pre svega drzavama i firmama, nije u interesu da ljudi zaista budu bezbedni, u to spada koriscenje privacy enhancing tools poput Tor i FOSS iskljucivo jer nijedna firma nece odbiti da radi sa law enforcement zastititi identitet svoga klijenta i dobiti silne kazne, a whistle bloweri i novinari koji se bore za ljudska prava po represivnim drzavama mogu i cesto koriste ista sredstva kao i cyber kriminalci od kojih nas "stite". IoT ce samo povecati deset puta podatke koje represivne drzave imaju o gradjanima, a npr. uopste nije potrebno nista dekriptovati, dovoljno je posmatrati kretanje nekoga da se sa velikom pouzdanoscu identifikuje sto je lako mobilnim telefonima sa GPS i geo-taggingom za fotografije.

Ako ja komuniciram sa nekim drugim, moze biti to osoba, ili glupi IoT uredjaj, zasto bih, ako ne moram, koristio javnu infrastrukturu (javne IP adrese) koje potencijalni protivnik moze koristiti (recimo da me identifikuje zato sto bas vzim BMW koji je IoT uredjaj), zasto ne bih koistio privatne IP adrese da potencijalni protivnik uopste i ne dodje do paketa izmedju mene i te druge osobe/iOT uredjaja? Bolesno, lose koncipirano, bas kako bi represivna drzava i zelela.

Problem je u tome sto ova IoTSF fondacija ne daje nikakve garancije, totalno ih bas briga za sve moguce razloge koje neko moze da navede, vendor-indenpendent, cinjenica je da ce tih kojekakvih IoT cuda da bude sve vise i vise, ovi ljudi makar daju dobronamerne savete koje neko moze a ni u kom slucaju da mora da poslusa ili bilo sta radi po tom pitanju.

Svaku od tih IoT spravica se da "saceka" bad-guy u nekom trenutku i da se posle svi cekaju po glavi u firmi sto se to desilo.

Nisu oni sertifikaciono telo, upravo se radi o "Self-signed" sertifikatu, tek ce da se pojave negde neka sertifikaciona tela ...

Dodatni problem koji se tu javlja je u B2B, na primer neka firma koja radi integraciju i prakticnu implmentaciju nekog sistema u nekakvoj buducoj na primer stambenoj zgradi gde treba da se ugradi nekakav IoT device.

U tom celom lancu vrlo verovatno da se da se jave sledeci problemi po ovom scenariju:

- jedan od dobavljaca i provajdera nekog servisa (hosting, cloud itd) moze da ispuni gore spomenute klasifikacije
- druga firma radi neki drugi deo, recimo nekakvu aplikaciju vezano za to
- treca firma pravi konketano parce HW (ili ista firma radi i SW + tu je i firmware)

Problem nastaje kada recimo firma/team koja radi HW ne moze da ispuni potrebnu klasifikaciju, nebitno je zbog kog razloga ne moze, firma koja se bavi integraciom resenja onda preuzima odgovornost na sebe za necije tudje propuste, sto bi to iko radio.
Dakle zna se da postoje problemi, neko to u svom segmentu svog posla ne zeli ili ne ume ili ne zna (kazem nebitan je razlog) da resi i sad neko drugi da preuzme njegovu odgovornost? :)

@mikikg

Nece biti takvih resenja, recimo samo par velikih firmi ce praviti to, Google Home, Amazon Echo/Alexa i to je to.

Mnogo ce jos petabajta proteci internetom dog stignemo dotle, u medjuvremenu ce poceti da se postavljaju pitanja tipa "sinko jel' tebi ta sprava sigurna?" :) ... ah da jeste ... "dokazi mi" ... pa znas ...

_{[Ovu poruku je menjao mikikg dana 17.02.2019. u 18:24 GMT+1]}

Bice nego sta. Sigurnost ce biti nula, a kolicina podataka koje ce advertiseri poput Googlea dobijati su strahovite, kao i nasrtaj na privatnost. Imas Smart Fridge i Google Home, glavno je tu da mozes da naredis glasom frizideru da ti ohladi vino za veceru na 20 stepeni. I kad to uradi, onda ce da te zatrpaju reklamama za skupa vina. DRM je manje zlo.

@bojan_bozovic da li si za to da nama svima u kompletu bude sigurnost i privatnost 0% i da nas rade koje-kakvi dokoni mamlazi i hakeri, da nam cure licni podaci na sve strane da moze da ih gleda svaka susa kako hoce ili si za to da se pomerimo makar na 1% i da se potrudimo da neke stvari makar predupredimo?

Naravno da nisam, ali takvi se sistemi ne prave na zalost sa sigurnoscu korisnika u prvom planu, i tesko da ce se to promeniti. Uvek ce biti mogucnosti da se takve stvari ne kupe i smanji uticaj na sigurnost, problem je sto ce vecina koristiti IOT, recimo ako tvoj auto bude IOT neke stvari neces moci da izbegnes. A sumnjam da ce polovnjaci imati ikakve security updateove. Uzas.

Bas uzas. Ovi iz IotSF su se bavili upravo i takvim scenariom. Bas si lep primer spomenuo.

Sta se desava sa uredjajem nakon sto promeni vlasnika ili zavrsi radni vek a u njemu ili preko njega tamo vezano brdo nekih informacija, tipa gde je to vozilo islo, koje pumpe je posecivao i sta ja znam sta ce sve da smisle i uvezu u mrezu i sutra neko dodje na "izvolte" takvim informacijama? Ogroooomni problemi ....

Cela ova prica i trenutna situacija sa security bi mogla da se predstavi bukvalno ovako :)

Problem je sto executive funkcioneri u firmama ne smeju da rade na stvarima koje se odnose na security arhitekturu a to rade. Njima je vazno samo da nesto lici na dobru ideju, nije bitno sto je sa aspekta bezbednosti losa, kao IOT, ipak se oni pitaju kakav ce proizvod da se izbaci na trziste, a kupci kupuju sve sto im se servira. Lepo je to iz USA i "zapada" gde policija ne sme da pritvara bez razloga, mlati, ucenjuje, gde postuju tvoja prava, u vukojebinskim diktaturama uopste nije tako. A tu su i cyber kiminalci, zeljni da dodju do licnih podataka da bi mogli da ostvare korist. Samo napraviti uredjaj i staviti softver na njega podrazumeva odgovornost, ali kupci ne zele da plate kvalitetan softver, nisu nikada, i zato je dozvoljeno zakonom da firme nude sa aspekta bezbednosti problematicna resenja i da niko nije odgovoran. U starom Rimu su graditelji mostova morali da budu ispod njih dok legija marsira preko, sta bi bilo da sw/hw danas mora da prolazi takve testove?

Vidi, recimo da je neki StartUp u pitanju, direktoru i developerima je u interesu da sve ove gore spomenute stvari oko security znaju, nevezano za sertifikaciju, to je u njihovom interesu da im servis i proizvod budu fino i uredno odradjeni.
U tom trenutku, nova firma, implementacija samo ovakve logike razmisljanja je ogroman iskorak koji generalno povecava kvalitet i tacno znas gde si dobar a gde si slab i firma bi trebala da se trudi da radi dalje na unapredjenju tog segmenta, svesni su da ne mogu 100% da ispostuju sve, ispostuj koliko mozes a ostalo bar da znas da ti je problem.

IoTSF je koliko vidim stvarno vrlo ozbiljan pokusaj i vidim da su samo za WEB segment bazirali metodologiju na O.W.A.S.P.
Moze da prica ko sta hoce, mene su ti OWASP testovi nebrojeno puta spasili na raznim WEB projektima!
Iskreno, najsikrenije, WEB developer koji ne koristi ili nije upucen oko O.W.A.S.P. bolje da mi se "ne pojavljuje na oci" :)

Samo sto je nesto hardware based, ne znaci da je bolje od softverskog resenja. Nije moguce patchovati security flaw osim ako nije u mikrokodu/firmwareu! Mozda ovo bude dobar primer https://motherboard.vice.com/e...ves-have-really-bad-encryption



I to je gigant Western Digital.



https://www.iotsecurityfoundat...-1.2.1-December-2018_final.pdf

Ako hacker moze da dobije root privilegije, mora i korisnik. Sta cu ja kao korinik da radim ako je IOT uredjaj kompromitovan i root fs izmenjen, ako mi je onemoguceno da ga menjam? A to je samo vrh ledenog brega. Sta konkretno zahtev [7] cini i od koga "stiti" uredjaj, od hackera ili korisnika?



Problem je s ovim veliki, zasto?
Sertifikacija development procesa ne moze da garantuje da nece biti security propusta. Samo testiranje softvera ne moze da garantuje da nema bagova [Dijkstra]. Potrebna je zakonska regulativa koja ce od IOT vendora da trazi da zakrpe security rupe izvestan broj godina nakon sto je uredjaj povucen iz prodaje



Ayatollah of Iran approves. Nakon sto se ID uredjaja poveze sa korisnikom (moze prilikom kupovine npr. automobila), bice ga moguce uvek prepoznati dok se ne proda, pa tako i pratiti, ili instalirati rootkit na njega. Tacno ce "sluzba" da zna gde rootkit treba da se instalira. Nesto kao IMEI za telefon.



Mnogo problema ima ovde, to je borba protiv FOSS a ne protiv dovoljno sposobnog napadaca. Ako postoji security flaw i napadac dobije root privilegije, nece mu trebati koriscenje oficijalnog update mehanizma da instalira sopstveni maliciozni payload na sistem. Traze zatvoreni a ne otvoreni sistem, proizvodjac moze odbiti da se na IOT uredjaj instalira alternativni softver koji nema security flaw. Korisnik nece moci sam da vrsi update. Vlasnik takvog zatvorenog sistema u sustini nije korisnik vec proizvodjac uredjaja.

Sa https://www.iotsecurityfoundat...-1.2.1-December-2018_final.pdf




Samo sto je nesto hardware based, ne znaci da je bolje od softverskog resenja. Nije moguce patchovati security flaw osim ako nije u mikrokodu/firmwareu! Mozda ovo bude dobar primer https://motherboard.vice.com/e...ves-have-really-bad-encryption



I to je gigant Western Digital.




Ako hacker moze da dobije root privilegije, mora i korisnik. Sta cu ja kao korinik da radim ako je IOT uredjaj kompromitovan i root fs izmenjen, ako mi je onemoguceno da ga menjam? A to je samo vrh ledenog brega. Sta konkretno zahtev [7] cini i od koga "stiti" uredjaj, od hackera ili korisnika?



Problem je s ovim veliki, zasto?
Sertifikacija development procesa ne moze da garantuje da nece biti security propusta. Samo testiranje softvera ne moze da garantuje da nema bagova [Dijkstra]. Potrebna je zakonska regulativa koja ce od IOT vendora da trazi da zakrpe security rupe izvestan broj godina nakon sto je uredjaj povucen iz prodaje



Ayatollah of Iran approves. Nakon sto se ID uredjaja poveze sa korisnikom (moze prilikom kupovine npr. automobila), bice ga moguce uvek prepoznati dok se ne proda, pa tako i pratiti, ili instalirati rootkit na njega. Tacno ce "sluzba" da zna gde rootkit treba da se instalira. Nesto kao IMEI za telefon.



Mnogo problema ima ovde, to je borba protiv FOSS a ne protiv dovoljno sposobnog napadaca. Ako postoji security flaw i napadac dobije root privilegije, nece mu trebati koriscenje oficijalnog update mehanizma da instalira sopstveni maliciozni payload na sistem. Traze zatvoreni a ne otvoreni sistem, proizvodjac moze odbiti da se na IOT uredjaj instalira alternativni softver koji nema security flaw. Korisnik nece moci sam da vrsi update. Vlasnik takvog zatvorenog sistema u sustini nije korisnik vec proizvodjac uredjaja.

Evo bas o cemu se radi.

>>> Samo sto je nesto hardware based, ne znaci da je bolje od softverskog resenja. Nije moguce patchovati security flaw osim ako nije u mikrokodu/firmwareu! Mozda ovo bude dobar primer https://motherboard.vice.com/e...ves-have-really-bad-encryption

To su predlozili iz iskustva, u mnogim slucajevima je problem iskljucivo bio vezan zbog toga sto je kompromitovan PRIVATNI kljuc (ne sto je falicna enkripcija), u SW domenu je mnogo lakse doci nekako do kljuca, posebno ako je zlonamerni user dobio root privilegije.
Ako imas TPM ili nesto slicno tome sto se iskljucivo bavi nekom crypto funkcijom, u tom HW je smesten i PRIVATNI kljuc, jednom je isprogramiran negde/nekako i stavljen FUSE katanac za iscitavanje, ne moze vise da se iscita kljuc (operise se sa JAVNIM), ajd da budem realniji, izuzetno tesko moze da se iscupa PRIVATNI kljuc iz takvog parceta HW cak i ako user ima root privilegije u OS!!!

Moram da idem, pisacu kasnije oko ostalih tacaka ...

Ako je napadac dobio root privilegije, najmanji je problem da instalira rootkit i payload bez obzira na potpisani firmware/os.

Evo recimo da korisnik ima IOT automobil. Napadac recimo uspeva da posalje paket na ranjivi servis na IOT uredjaju, vrsi izvrsenje svog malicioznog koda. S obzirom da ne moze da zameni potpisani OS i boot loader, preko svoga servera instalira executable loader (za izvrsavanje nepotpisanih fajlova) i sopstveni maliciozni payload. Njgov command & control server ce izvrsiti periodicnu proveru, i ako ne postoji rootkit na IOT uredjaju, instalirati ga opet. Na taj nacin iako ne moze zameniti potpisani bootloader i OS IOT uredjaja, skoro uvek omogucava izvrsenje svog malicioznog payloada, koji na primer periodicno uploaduje podatke o kretanju automobila na njegov server.

Dalje, kako je u TPM privatni kljuc? Recimo proizvodjac auta ima svoj mali CA, i RSA key pairs, jedan za IOT, i recimo drugi za entertainment system od drugog proizvodjaca.

RSA funkcionise ovako, recimo, sa GNU PG proizvodjac koristi svoj privatni kljuc da enkriptuje update tarball i javni kljuc od Mercedes-Benz S Class. Hardver koristi kljuc, to su javni kljuc (Mercedes-Benz AG) i svoj privatni kljuc (recimo kljuc Mercedes-Benz S class) da dekriptuje update. Tim kljucevima GNUPG (RSA) ne moze da enkriptuje update za drugi Mercedes-Benz S Class. To moze samo proizvodjac svojim privatnim kljucem.

Ako haker vec hakuje IOT auto, najmanji mu je problem iskoristiti sam hakovani IOT Mercedes-Benz S Class i njegov TPM da dekriptuje sta vec zeli od enkriptovanih updatea.

Imam GNUPG na kompjuteru i koristim RSA.

Ima i ja neke crypto HW i experimenttisem sa njim i ECDSA, dosta jednostavniji user case ...

Caka je tome da se resi i bootloader, i provera potpisa firmwera i ono najbitnije da se tokom rada programa koji recimo da salje neke podatke na udaljen server, svaki blok podataka da se potpise sa tim nekim TPM i njegovim super-tajnim privatnim kljucem (ja koristim Maximomv neki I2C device za to) i sa druge strane na serveru da se provera taj potpis sa javnim kljucevima.
Svaki device bi trebao da ima svoj jedinstvern privatni kljuc, nikako da se ponavlja isti na drugim primercima, svi Javni kljucevi od tih device stoje na serveru i tamo se proverava integritet poruke, IoT HW je potpisao razne podatke u bloku "datum, IP-ako-ima, neki seriski broj uredjaja, nesto trece, nesto cetvrto pa onda npr JSON sa podacima/payload", sve to na gomili potpisano.

Dakle poruka je vrlo tvrdo potpisna, nije zasticena nista (drugi mehanizmi se time bave ako treba), dakle server u najgorem slucaju moze da dobije nekako spufovane podatke, nije na primer izmerena vrednost tamo na A/D konverteru 123 nego haker jedino uspeo to da prebaci da pise 456, sve proslo kroz crypto i potpisano, tacno stoji koji device, koji IP, vreme itd samo su podaci "cudni".
Moramo priznati da je to malice sigurnije, opet ne savrseno ali smo se malo pomerili na bolje, bar mogu sa velikom verovatnocom da tvrdim da su stigli podaci bas sa tog nekog device koji ima taj neki moj modul i da je neko dosao u posed toga i pocinje da hakuje.
Kompromitovana je samo ta jedna sprava, nikako deo ili slucajno ceo sistem, drugi sad neki mehanizmi trebaju da prepoznaju "cudno ponasanje" pa da ti alertuju i da Administrator malo to detaljnije analizira.

Nista ne moze da se resi u jednoj tacki, to treba da bude integralno resenje, po svim nekim tackama da se ishendluju zahtevi.

Opet kazem, sa ovim smo se vec mrdnuli sa mrtve tacke, to je daleko sigurnije nego da nista od toga nije ni bilo implementirano.

Nije uopste to sigurno, jer neko prikuplja podatke koje, u sustini, ne bi trebao, i drzi ih na svom cloudu. Ako podataka nema ne mogu biti zloupotrebljeni. Problem je sto smo mi na internetu navikli da podaci nikad ne nestaju, i neko nas je ubedio da je tako dobro i ispravno.

Odlicni komentari, sve stoji, tu smo da probamo da ih prevazidjemo :)

PS: Meni je drago da ima sagovornika u temi za pocetak, nesto se desava, pre ove temo niko nista ... bukvalno kao sa klipa http://www.elitesecurity.org/p3882372 :) security=lopta

Sta su alternative?

Hajde onda da postavimo sistem da mora za pocetak makar da anonimizuje korisnicke podatke ako ih koristi, da se zna u koju svhu se koriste i da USER moze da explicitno da dozvolu ili ukine u bilo kom trenutku, to je njegovo (MOJE) pravo, kada ima dozvole sistem radi tako, kada nema radi tako, mnogo prosto.
Hajde makar hipoteticki da postavimo tako pricu da ce biti kompletan vidljiv Open Source code i da se sve vidi sta se u SW radi :)

_{[Ovu poruku je menjao mikikg dana 18.02.2019. u 20:53 GMT+1]}

Onda dolazimo do toga da IOT ne treba da otezava korisnikov update ili modifikaciju sistema, neka je IOT auto, paint job, tuning, custom IOT software, to je isto...

Resenja se vrte negde oko "necega" sto pravi mali "GAP u vremenu", dakle otkriven je propust, developeri hitno zakrpili, korisniku se daje do znanja da ima update i da treba da ga prihvati jer je takva situacija (kasnije ce biti obljavljen i tacan sadrzaj propusta), hoce/nece njegova stvar - stvarno dalje od toga ne moze bar sto se te odluke tice, preduzeto je sve da cak i ako nece kao sto spomenuh sa jedinstvenim kljucevima incident ce biti (ili bar pokusaj da bude) izolovan!

Dokument sa pocetka teme recimo u jednom segmentu se bavi temom samo oko toga da li firma treba ili ne treba da ima otvoren pristup obljavljivanja sigurnostnih propusta, dakle kada se nadje propust da obaveste o tome javnost najcesce sa nekim delay ali obajave ili da firma kada naidje na propust "cuti i kulira" i da uospte nikoga nigde ne obaveste o tome i da se prave blesavi pa sta bude????

Extremno interesatna pitanja! :)

Po istazivanju 90% su trenutno oni iz druge grupe, "cute i kuliraju" ali ima i ovih drugih!

Evo jedan dokument ovde:
http://static.elitesecurity.or...curity_webcast_august_2018.pdf



To je Texas Instruments i Amazon sa AWS smislio, dajem kao primer samo i nebitan je termostat, sve to moze da bude u mikro okruzenju, slicno tome samo na svojim serverima, dakle nebitan je Amazon, bitno je sta ima od modula u tom chipu raspolozivo (inace skoro svi novi ARM-ovi drugih proizvodjaca imaju to sve slicno, fokus samo na Crypto sub-module) i kako je osmisljena cela postavka.

Ti me moduli interesuju kako pametno ukljuciti u ovu pricu!

---

Sto se tice "ima nov update informacije", dovoljno je da neka LED blinka "brzo" i da to znaci da ima update i da je user svestan toga, sad na proizvodjacu je da osmilsi zgodnu i poudzanu proceduru za updejt koja tera korisnika makar da pritisne neki taster cisto da bi se uveo jos jedan faktor prilikom te operacije i smanjio rizk od neke automatske zlouptrebe toga.

Update mora da ide automatski. Korisnik mozda ima tuce IOT uredjaja, nece moci svaki da updateuje manuelno. Zaista, taj dodatni faktor da user manuelno potvrdi update, koliko doprinosi sigurnosti ako se koristi rsa? Bespotrebno davljenje korisnika nista drugo, ja sam napisao kako bi izgledao napad na takav uredjaj, niko nece ni da pokusa da falsifikuje update od proizvodjaca, i koristi oficijelni update mehanizam.

Zato sam i napisao da je njihov security dokument snake oil, recimo zalazu se za encrypted file system, on ne sprecava remote exploit i preko njega image celog diska ako napadac hoce, samo je oduzimanje vremena sw inzenjerima od vaznijih stvari.

Kazem sve stoji, pokusavam i ja da smislim neki dobar workflow.

Na primer, evo jutros ovo osvanu:
https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/

Dakle ovo je bruka sta su uradili, ajd glupa remote sijalica u pitanju, ali vidi sta su sve momci uspeli da odrade!!!

I RSA kljuc vratili, i ceo firmware, ovi nisu nista ni pokusavali da zastite, sa alatkama sa "trafike" sve odradili ...

Fizicko obezbedjivanje kompjutera je posebna prica. Mislim da to i nije tema ove rasprave.



Ali tako je korisnik hteo, korisnik koji je to platio. Zasto bi ga trebalo sprecavati u tome?

Vidi, racunari koji nisu tako "zasticeni" pa korisnik moze da instalira softver po zelji na njih mogu nadziveti i firmu koja ih je proizvodila. Primeri neka budu linux/amiga-68k i netbsd/vax.

Taj TPM vise stiti od samog korisnika u korist nebuloznih korporativnih i drzavnih interesa.

Hajde da ja pokusam, mada ko me slusa.

Prvo, potrebno je definisati koji hardver ce IOT uredjaji koristiti. Hardver moze imati security flaws, ukljucujuci i TPM. To bi smanjilo rizik.
Drugo, potrebno je definisati koji OS ce se koristiti. To bi bio deo sertifikacije, a sa ciljem da se smanje security flaws. Trebalo bi da bude FOSS da ne bude proprietary, da se omoguci nezavisni audit i sloboda od korporativnih interesa.
Trece, potrebno je definisati centralni repository za update, nesto kao linux distribucija. Kada se update server kontaktira, vrsio bi siguran update uz RSA public key cryptography, recimo GNUPG ili na neki drugi nacin.
Cetvrto, bitno je definisati koje podatke ce IOT da prikuplja i gde. Nece svaki proizvodjac imati svoj cloud, vec ce cloud biti pod kontrolom neprofitne fondacije posebno stvorene. Tako nece moci da prate, recimo, sta kuvam preko recepata koje gledam na smart frizideru, i zatrpavati me reklamama.
Mora postojati opt-out uvek. Mora postojati mogucnost da podaci budu na serveru neke drzave, ukoliko to zakon zahteva. Ili lokalno, u okviru firme, recimo za limo servis nekoga hotela.

Ostalo i ne mora da se implementira za sigurnost od remote exploita - ako neko zeli da uredjaj bude tamper proof, to moze, ali nije uopste neophodno. Sve ovo bi povecalo sigurnost podataka, smanjilo pracenje IOT uredjaja od strane advertajzera, omogucilo security update i nakon sto proizvod bude povucen sa trzista.

_{[Ovu poruku je menjao bojan_bozovic dana 19.02.2019. u 12:38 GMT+1]}

RE:
https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/



Kojih vaznijih stvari? :) Kako da remote ukljuce sijalicu on/off? :)

Pa to Tesla i Marconi napravili bez komjutera pre 100 godina :D

Security audit je vaznija stvar. Encrypted file system ne cini da je sistem siguran od remote exploita, samo povecava bezbednost od nekoga ko ima fizicki pristup uredjaju a u vecini slucajeva to je sam korisnik.

Naravno. Oko toga imamo isti stav. To je veoma vazna stavka u celoj prici, bolje da ti "nahvatas" propust nego da to drugi umesto tebe uradi i da se suocavas sa posledicama toga.
Nije jednostavno, mora da se udje ozbiljno u temu.
Ja godinima koristim O.W.A.S.P. metodologiju za WEB, ekipa iz IoTSF bazirali su svoju studiju po vrlo slicnom principu i uveli su upravo O.W.A.S.P. u pricu posto je itekako povezana.

Pogledaj ovaj dokument, to nije sala!!! Radi se samo o top 10 tipova napada, koliko ih jos ima sve ...
http://static.elitesecurity.or...OWASP_Top_10-2017_(en).pdf.pdf



Sve je to usko povezano, enkripcija sama za sebe ne znaci nista ako nije dobro implementirana. Ovi ljudi upravo objasnjavaju kako da se to sve ispravno iskoristi.
Vidjao sam gomilu aplikacija gde developeri jednostavno neke stvari iskuliraju, komplikovano im da tamo nesto urade i vezu secure-key storage gde proizvodjac lepo predvideo mesto i crvenim slovima u dokumentaciji napisao da tako urade, ma kaki, developer uzme harcoduje sifru u skripti i resi to jer ga gazda pritiska da zavrsi to sto pre ...



_{[Ovu poruku je menjao mikikg dana 19.02.2019. u 16:25 GMT+1]}