Facebook: er zijn geen problemen met privéfoto's

Er zijn geen problemen met privéfoto's op Facebook. Dat zegt het hoofd beveiliging van de sociale-netwerksite, Joe Sullivan, tegen Tweakers.net. Een Australische beveiligingsexpert claimde dat hij de url's van privéfoto's kon achterhalen.

De Australische beveiligingsexpert Christian Heinrich veroorzaakte eerder deze week de nodige ophef met zijn onthulling dat iemands privéfoto's op Facebook kunnen worden gedownload door personen die niet met hem of haar bevriend zijn. Joe Sullivan, chief security officer van Facebook, maakt zich echter geen zorgen, blijkt uit een interview dat Tweakers.net donderdag met hem had op de Hack in the Box-beveiligingsconferentie in Amsterdam.

Heinrich zei maandag op een andere beveiligingsconferentie dat hij de structuur waarmee de platte foto's bij de door Facebook gebruikte content-delivery-networks worden opgeslagen, kon achterhalen. Zo zou hij binnen een week privéfoto's van een bepaalde gebruiker hebben kunnen downloaden, zonder dat hij met de bewuste persoon bevriend was. Een deel van de url moest met gokken worden achterhaald; Heinrich gokte 200.000 url's per dag. Volgens Sullivan gaat het om een 'puur theoretische' mogelijkheid om foto's te achterhalen. "We zijn ervan overtuigd dat dit geen kwetsbaarheid is waarmee mensen rekening moeten houden", aldus Sullivan. "Je moet honderdduizenden keren gokken."

Sullivan heeft de presentatie van Heinrich nog niet gezien, maar zegt dat een van zijn collega's met Heinrich heeft overlegd. Die zou hebben erkend dat het om een theoretisch probleem gaat. "Als ik honderdduizenden keren zou gokken, zou ik ook je wachtwoord voor je account kunnen raden", zegt Sullivan. De beveiligingstopman van Facebook zegt niet te kunnen bevestigen dat Heinrich daadwerkelijk op deze manier foto's heeft weten te achterhalen, zoals diverse media melden. "Ik heb begrepen dat hij heeft gezegd dat dat niet is gebeurd." In dat geval is onduidelijk waarom Heinrich claimde van wel.

Volgens Sullivan is een van de redenen dat het verhaal zo veel publiciteit heeft gekregen dat Heinrich foto's claimde te hebben achterhaald van de vrouw van een andere beveiligingsexpert, met wie hij een slechte verstandhouding heeft. Overigens werd een journalist die over het verhaal had bericht, Ben Grubb, gearresteerd omdat hij 'onwettig materiaal' zou hebben ontvangen. Grubb is inmiddels weer vrij, maar zijn iPad is wel in beslag genomen.

Reacties (90)

[UmbraDei]

Dat uitproberen van al die url's is op zich niet zo moeilijk. Facebook-foto's hebben in hun naam bijzonder veel vaste characters (o.a. het FBid dat je sowieso kent van iemand wiens foto je zoekt), en kan dan met behulp van bijvoorbeeld WebSlayer (http://code.google.com/p/webslayer/) gebruikt worden om de andere info ook te vinden. De namen zijn dan ook opgebouwd als:
*ALBUM-ID*_*Timestamp-gebaseerd-op-uploadtijdstip*_*FBid*_*Ander-sequentieel-nummer-dat-volgens-mij-afhangt-van-album-id*_*RANDOM-DIGITS*_n.jpg

Omdat er helemaal geen controle is op het effectief ingelogd zijn door facebook-servers, zou je zo'n brute-force attempt zelfs perfect distributed kunnen uitvoeren.

Je kan trouwens ook gemakkelijk zien hoe mensen uit een geuploadde facebook-foto onmiddellijk de naam van de eigenaar van zo'n foto kunnen bepalen, zoals vaak gebeurt op websites met hoge concentraties aan zogenaamde '/b/tards'.

[Anoniem: 298599]

De naam achterhalen is dan ook enorm simpel, het profile ID is 1 van de nummers in de bestandsnaam.

Even een voorbeeldje geven:
http://www.facebook.com/HowIMetYourMotherCBS

Ik kies een willekeurige foto en dit is dan de directe link:
http://a5.sphotos.ak.fbcd...199381_10150130047427277_7807422276_6193266_5312248_n.jpg

Het vetgedrukte is het profile ID, dit is altijd de 3de rij cijfers.

Dan kan je gewoon het volgende typen:
http://www.facebook.com/profile.php?id=

gevolgd door het profile id en krijg je dus:
http://www.facebook.com/profile.php?id=7807422276

En dat is dus de link van de How I Met Your Mother pagina, deze truc werkt ook met gewone accounts. Het probleem is dat vele mensen denken dat als ze de afbeeldings url kopiëren de account dan niet terug te vinden is.

[Reactie gewijzigd door Anoniem: 298599 op 24 juli 2024 21:55]

[UmbraDei]

Had ik niet letterlijk het *FBid* ertussen gezet in de bestandsnamen? Zal misschien even verduidelijken dat dit inderdaad het FaceBook profile IDentification number is, zoals je ook al zei.

Toch bedankt om ook even te tonen waar je dat ID kan gebruiken, voor hen die dat niet volledige duidelijk was .

[swel]

Lol, niet z'n spotlight credit afpakken hoor

[Tk55]

Omdat er helemaal geen controle is op het effectief ingelogd zijn door facebook-servers...

Dit is overigens erg handig als je foto's wil sturen naar vrienden zonder Facebook of zonder die specifieke vriend. Je pakt gewoon de deep link met rechtermuis>copy link url en stuurt deze vervolgens door.

Het lijkt me inderdaad niet echt een rendabele hack. Als je 200.000 requests per dag stuurt naar een server van Facebook, wordt dat dan eigenlijk niet opgemerkt als een mogelijk aanval of hack?

[robvanwijk]

"Als ik honderdduizenden keren zou gokken, zou ik ook je wachtwoord voor je account kunnen raden", zegt Sullivan.

Uitgaande van hoofdletters, kleine letters en cijfers (62 tekens in totaal) zijn er
1 wachtwoord van lengte 0
62 wachtwoorden van lengte 1
3844 (lengte 2)
238328 (lengte 3)
242235 (lengte 0, 1, 2 of 3 samen)
Dus om iemands wachtwoord met "honderdduizenden" keren gokken te achterhalen mag het geen "rare tekens" bevatten en maximaal drie tekens lang zijn (of het moet in een dictionary voorkomen natuurlijk).
Oftewel: die uitspraak is, in de praktijk, volstrekte onzin. Van iemand die over security gaat zou je hopen dat ie beter weet...

Edit:
@Zer0: Jouw opmerking over de eerste keer goed kunnen gokken is puur theoretisch. Daarom zei ik juist "in de praktijk". Dus als we het over "goed" hebben; zou je dan ook goed willen lezen alsjeblieft?

[Reactie gewijzigd door robvanwijk op 24 juli 2024 21:55]

[pagani]

En 99% van de gebruikers heeft een wachtwoord dat weldegelijk in een dictionary voorkomt (aangevuld met 1-3 leestekens), anders is het namelijk vrij lastig onthouden. Dus om het nu gelijk als onzin af te schuiven... 200.000 is misschien wat weinig, maar onzin, nee. Als je dan ook nog eens de dictionary aanpast aan de gebruiker (vakgebied, hobbies, familie, huisdieren etc.) dan valt een groot aantal gebruikers vrij snel door de mand hoor

[Barleone]

dan valt een groot aantal gebruikers vrij snel door de mand hoor

Spijker op de kop, kijk maar: Basta: wachtwoord alstublieft?

[Anoniem: 91169]

Geweldig!

[humbug]

Even de link hierboven gekopieerd

http://a5.sphotos.ak.fbcd...199381_10150130047427277_7807422276_6193266_5312248_n.jpg

Hier staan 7 "Random characters" oftewel een nummer tussen 0000000 en 9999999. Gemiddeld heb je dus 10.000.000 /2 = 5.000.000 pogingen nodig. En dan moet je dus al alle andere opties weten. Zo niet explodeert het aantal opties verder. Als je enkel het FBid weet komen er nog 30(!) karakters bij.

Voor je pincode (bestaande uit 4 cijfers) heeft men gemiddeld "maar" 5.000 pogingen nodig.

Van iemand die klaagt over de kennis van iemand anders over beveiliging zou ik toch op zijn minst verwachten dat die weet hoe je een verwachting uitrekent en zaken in perspectief kan zien. De uitspraak klopt dus gewoon. Zowel in de praktijk als in theorie.

[robvanwijk]

Even voor de duidelijkheid:
- Ik heb nooit gezegd dat Facebook's foto-urls makkelijk te gokken zijn, ik had het enkel over passwords.
- Ik zie in jouw hele post geen enkele referentie naar wachtwoordje-kraken.
Waarom jouw redenering (waar ik het trouwens mee eens ben, uitgaande van "de uitspraak" ~= "Facebook foto-urls zijn, realistisch gezien, niet te gokken") een fout in mijn post zou aantonen ontgaat me...
Los daarvan, het zou natuurlijk beter zijn om permissies te checken voordat je file serveert, maar ik kan me voorstellen dat dat op efficiëntie-bezwaren stuit.

Overigens, bij pincodes heb je maar drie kansen al zou je twee keer kunnen proberen, dag wachten (hopen dat de eigenaar zijn pas gebruikt, eerste keer goed typt en het countertje reset) en nog twee keer proberen, etc. waardoor dat toch redelijk veilig is. Hoe Facebook zo'n soort check (op een efficiënte manier, zonder het "onterecht resetten van de counter"-probleem) zou kunnen implementeren kan ik je zo een-twee-drie niet vertellen.

[Zer0]

Oftewel: die uitspraak is, in de praktijk, volstrekte onzin

"Als ik honderdduizenden keren zou gokken, zou ik ook je wachtwoord voor je account kunnen raden"

Zijn uitspraak klopt 100 procent, er is wel degelijk een kans dat hij een wachtwoord met een aantal keer gokken kan raden. Sterker nog, zelfs met één keer gokken kan hij het goed hebben.

Als je een dergelijke uitspraak zo technisch wil ontleden om iemand onderuit te halen, doe het dan wel goed...

[exyll]

Het probleem is dat de foto's op content servers komen te staan die niet direct van facebook zijn. Zo zou facebook content bijvoorbeeld op Amazon S3 servers kunnen plaatsen in diverse geografisch andere regio's zodat Aziatische of Europesche gebruikers nog steeds 'snel' bij deze content kunnen. Hierbij is security through obscurity heel erg defacto en dat is omdat deze content lastig te beveiligen *zonder* een dure security check uit te voeren. Want nu haal je hem van server X, dan van server Y en dan weer van Z. Probleem bij facebook is dat deze obscurity te eenvoudig is. De random id's zijn niet groot genoeg om bruteforce te voorkomen. De opmerkingen over 'dat zien ze toch dat er een bruteforce attach wordt uitgevoerd' gaat niet op omdat dezelfde content over honderden servers verspreid wordt en bij bruteforce aanvallen ook nog eens gedistribueerd wordt uitgevoerd.

Security by obscurity vind ik hier niet eens het grootste probleem. Een veel groter probleem is dat deze ook nog eens gewoon over poort 80 worden binnen gehaald dus over een niet versleutelde verbinding. Man-in-the-middle sniffers zijn veel gevaarlijker zoals proxy servers op werk, netwerk sniffers in een internet cafe en spyware op je pc.

[Anoniem: 330244]

pri·vé bn, bw particulier, persoonlijk

Als je een privé-foto op internet wilt zetten, acht je de foto dus eigelijk niet privé. Privé-foto's op internet zetten gaat dus niet. Net als delen door 0. Want privé-foto's houden mensen liever persoonlijk in hun privé-omgeving. Downloaden van privé-foto's gaat dus niet, behalve als de foto's tegen de wil van de eigenaar is ge-upload natuurlijk. Maar dat is een heel ander verhaal.

[Anoniem: 24417]

true.

ik vind het maar gezeur, als een foto super-delicaat is moet je hem gewoon niet op internet zetten. want een gebruiker op facebook die wel een 'vriend' is kan die foto ook downloaden en dan op imgur zetten oid.

storm in een glas water, wat mij betreft

[Bartjezz]

storm in een glas water, wat mij betreft

Vind ik ook, ik ga echt niet zomaar een linkje in mijn adresbalk typen of er misschien een foto achter zit... Ik kan me niet voorstellen dat er veel mensen zijn die hersenloos achter het scherm zitten te wachten tot er een link goed is, om vervolgens één of ander afzichtelijk huisdier te zien ofzo...

[Arnoud Engelfriet]

Je zet zo'n programma aan en gaat een week later kijken welke celebrities naaktfoto's online hadden gezet. Da's een leuke investering hoor, als je die vervolgens te gelde kunt maken bij Privé.

[Anoniem: 24417]

alsof ze die op facebook gaan zetten

[robvanwijk]

Want privé-foto's houden mensen liever persoonlijk in hun privé-omgeving.

Met andere woorden: je vriendenkring. En wat is nou juist het hele idee van Facebook (en andere sociale netwerken)? Juist, in contact blijven met je vrienden, ook als die eens een keertje een jaar (of permanent) op een ander continent zitten en de enige realistische optie voor regelmatig contact via het Internet is. Zolang de access control correct werkt is het dus wel degelijk mogelijk om privë-zooi online te zetten (het is een ander verhaal of het verstandig is).
Overigens, is jouw email via een web-interface beschikbaar? Kun je me even een dump sturen van je hele mailbox; die is via het Internet beschikbaar en bevat dus geen privë-gegevens, toch...?

[pagani]

In feite zeggen ze dus: We hebben geen beveiligingsprobleem want alleen middels brute force is deze informatie te achterhalen.


Riiiiiiiiiiiiiiiiiiiiiiiiiiight.

(daarnaast is het kunnen achterhalen van foto's van willekeurige mensen (hij heeft immers kunnen zoeken in honderdduizenden foto's waarvan ongetwijfeld dus ook veel privé foto's) weldegelijk zorgelijk)

[Reactie gewijzigd door pagani op 24 juli 2024 21:55]

[David Mulder]

Hoeft helemaal niet, stel bijvoorbeeld (werkt zeker niet zo) dat per persoon er een directory is en ieder bestand in die directory een willekeurige naam heeft, dan moet je nog steeds dus alleen van die persoon doorzoeken.

Los daarvan zou Facebook in dit geval vergelijkbare mechanismes moeten gebruiken als die tegen DDOS aanvallen worden gebruikt waar automatisch een ip word geblokkeerd na te veel aanvragen. Maar al met al is dit nou niet echt een groot probleem moet ik bevestigen als developer.

[pagani]

Leuk dat je ook developer bent, ik snap alleen niet wat je nu wilt zeggen.

Feit is dat Heinrich blijkbaar het algoritme achter de opslag (naamgeving/nummering en locatie) weet en daardoor ongeacht of foto's privé zijn of niet op facebook door álle foto's op facebook kan zoeken. Hoe je het ook wendt of keert, het feit dat op deze manier privé foto's van willekeurige mensen alsnog te zien zijn is zorgelijk.

Overigens vermoed ik dat Hyves eenzelfde probleem heeft. Ik kan namelijk zonder problemen van privé foto's van mij op Hyves de URL kopiëren en vervolgens kan iedereen die ik die URL geef de foto bekijken. Ook daar is dus geen controle op of de foto wel in de Hyves site wordt bekeken of middels een van de Hyves apps.

[Reactie gewijzigd door pagani op 24 juli 2024 21:55]

[Herko_ter_Horst]

Als je het algoritme weet, hoef je niet te gokken, dus dat gaat niet op.

Verder heb je gelijk: als het niet de bedoeling is dat mensen die foto's kunnen zien zonder vriend te zijn van de betreffende persoon, is dit gewoon een lek, of meneer de security expert van Facebook dat nou vindt of niet.

Zo als zo vaak: security-through-obscurity is geen security.

Dat Facebook privacy niet hoog in het vaandel heeft staan, is de afgelopen tijd al meer dan eens duidelijk geworden. Maar wat wil je ook van een bedrijf dat zijn geld moet verdienen met de informatie die het over zijn gebruikers heeft...

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 21:55]

[MicGlou]

Security through obscurity is hier helemaal niet ter sprake... of moet iedereen het algoritme van de beveiliging gaan publiceren om het makkelijk te maken? De man van Facebook zegt het toch al, het aantal keren wat je zou moeten gokken om wat relevants te krijgen schiet in de honderdduizenden... jouw pincode is met minder keren te gokken. Hij geeft zelfs toe dat het een theoretisch lek is en dat de methode 'plausibel' is, maar in de praktijk ondoenlijk om te misbruiken omdat het gewoon veel te veel tijd kost. En zijn reactie is volgens mij ook zo lauwtjes, omdat er vrij eenvoudige methodes om een dergelijke methode echt tot een hel te maken... want als ik het goed begrijp doet deze 'hacker' niet meer dan een hele serie random request sturen en dan maar hopen op een (aantal) hit(s).

Buiten dat, bij Facebook zijn ze echt niet gek... die houden de boel daar volgens mij aardig scherp in de gaten. Dat is nou het hele ding met Facebook, al die jongens die erachter zitten zijn echte code-freaks... zelfs die Zuckerberg zit nog steeds dagen en dagen aan regeltjes te werken. Dat Facebook privacy niet hoog in het vaandel heeft veel meer te maken met wat ze bewust laten zien, dan dat Facebook zo lek als een mandje is... dat vind ik toch flink verschillen van elkaar.

[Herko_ter_Horst]

Wis en waarachtig is dit security-through-obscurity: een fatsoenlijke beveiliging zou de toegang tot het plaatje simpelweg weigeren als er niet via de login van een vriend van de eigenaar van de foto om werd gevraagd.

In plaats daarvan is gekozen voor publieke toegang op de "niet te raden" URL van het plaatje. Dat is zo'n beetje de definitie van security-through-obscurity. En honderdduizend keer raden is voor een computer een fluitje van een cent.

En dat mijn PIN code in minder dan honderduizend keer te raden is, doet helemaal niet terzake. Er zijn ongetwijfeld duizenden mensen met dezelfde PIN code als ik. Ik zal hier even de PIN code van duizenden andere mensen posten: 1337. Zo. Ben je er blij mee? Heb je er wat aan? De veiligheid van de PIN zit in de combinatie met de pas (something you have + something you know). Dat is bij een URL naar een plaatje niet van toepassing.

Het kan best zijn dat er bij Facebook echte hackers achter de knoppen zitten, maar dat maakt nog niet dat ze veilige software kunnen maken. En dat foto's bedoeld voor vrienden zichtbaar zijn voor iedereen die (hoe omslachtig ook) de juiste URL weet te raden, is niet bewust, dat is gewoon een lek.

[Reactie gewijzigd door Herko_ter_Horst op 24 juli 2024 21:55]

[OddesE]

Als je het algoritme weet, hoef je niet te gokken

Dit is natuurlijk onzin, want het algoritme kan eigenschappen bevatten die er voor zorgen dat je juist wel moet gokken, zoals:

String fotoName = Integer.valueOf(new Random().nextInt()).toString() + ".jpg";

De fotoName die door bovenstaand algoritme wordt gegenereerd kun je niet voorspellen, ondanks dat je het algoritme kent. Dit kan net zo goed 3.jpg zijn als 1239325288.jpg.

In plaats daarvan is gekozen voor publieke toegang op de "niet te raden" URL van het plaatje. Dat is zo'n beetje de definitie van security-through-obscurity.

Ook dit is natuurlijk onzin. Ik ben het met je eens dat honderduizenden keren raden niet veel is voor een computer, maar de term 'security through obscurity' slaat op de obscurity van het algoritme en niet op de output van het algoritme. Anders is elke vorm van security die vertrouwt op een geheim, 'niet te raden' token een vorm van security through obscurity, waardoor dus ook authenticatie middels gebruikersnaam en wachtwoord onder deze definitie zou vallen.

In principe kun je stellen dat de bestandsnaam van het plaatje fungeert als wachtwoord. Hiermee is op zich niets mis alleen moet je dan dezelfde maatregelen nemen als bij normal login pagina's:

• Zorgen dat de hoeveelheid mogelijkheden groot genoeg is dat brute forcen moeilijk is
• Limiet op aantal raad pogingen om brute force te voorkomen
• Loggen van raad pogingen zodat daders sporen achterlaten
• Monitoren van en melden van raad pogingen
• Peer review van encryptie algoritme om zwakheden te achterhalen

Ik vermoed dat Facebook niet aan deze voorwaarden voldoet en dat is een slechte zaak. Als ze echt ballen hebben dan publiceren ze het algoritme dat de fotonamen genereert. Als dat inderdaad sterk genoeg is dan is de publicatie geen probleem. Is dat algoritme te zwak voor publicatie dan kun je beginnen te spreken van securitty through obscurity, maar dit komt dan puur doordat de veiligheid alleen gewaarborgd wordt doordat het algoritme geheim is, niet doordat de gegenereerde foto namen geheim zijn.

[Herko_ter_Horst]

Security through obscurity slaat niet alleen maar op het algoritme, maar op het feit dat alle zaken m.u.v. de authentieke sleutel als bekend moeten worden verondersteld. Het obscuren van andere elementen werkt weliswaar vertragend en kan als waarschuwing dienen, maar moet niet als onderdeel van de beveiliging als zodanig worden beschouwd.

Het punt is hier dan ook niet de kwaliteit van het gebruikte algoritme, het punt is dat de "security" niet gekoppeld is aan rechten van een gebruiker. Er wordt op geen enkele manier afgedwongen dat de gebruiker de juiste rechten heeft om het plaatje te zien. Er is geen security, er is alleen maar obscurity via een random nummertje.

Wat ze hier gedaan hebben is een geopende kluis in een bank met 1000 (of 100000 of hoeveel dan ook) deuren zetten en alleen de rechtmatige gebruiker het nummer van de enige open deur gegeven. Op geen enkele manier wordt gekeken of het ook echt de rechtmatige gebruiker is, die de deur opent. Iemand met geduld of geluk kan de bank zomaar binnenlopen en de inhoud van de kluis verwijderen.

[humbug]

Eigenlijk vind ik de ophef overdreven.

Laat ik een simpel algoritme nemen.

SimpleDateFormat df = new SimpleDateFormat("yyyyMMddHHmmss");
String fotoName = df.format(foto.getUploadTime())+MD5(salt+String.valueOf(foto.getUploadTime().getTime()))+".jpg";

Veel simpeler kan ik het niet verzinnen.

Tabelletje ernaast waarin aangegeven staat wanneer een foto is geupload, beschrijving, toegangsbeperkingen, enz en klaar.

Maar goed, per seconde krijg je dus een set foto's met een unieke MD5 hash.
Een md5 hash bestaat uit 128 bits en heeft dus 2^128 unieke mogelijkheden.
Laat er nu eens 1.000.000 foto's per seconde naar facebook worden geupload.
Dat betekent dat ik 1 miljoen bestandsnamen heb die beginnen met yyyyMMddHHmmss.
Om 1 foto te vinden moet je dus gemiddeld 2^128/1.000.000/2 pogingen doen. Dat is grofweg 2^128/2^20/2^1 = 2^(128-20-1) = 2^107.

Ik zeg: Succes.

Als ik dan naar jou voorwaarden kijk zie ik dat ik inderdaad genoeg mogelijkheden heb, het loggen van pogingen kan gebeuren door de webserver die 404 errors rapporteert, het monitoren van een webserver ook goed kan gaan en een peer review op het algoritme ook wel kan. Maar het forceren van een limiet op "raad pogingen" lijkt mij eigenlijk onnodig. (gemiddeld 2^107 pogingen per foto....) Waarom bijhouden welk IP een 404 error genereert, en dat na een bepaald aantal keren dichtzetten. En wanneer mag het dan weer open? Lastige discussie en weer extra database werk wat de zaak vertraagd. Mits het algoritme enigszins werkt (en zo heel moeilijk is dat nu ook weer niet) is het aantal pogingen gewoonweg te groot om een praktische hack te zijn.

Wel kan het natuurlijk zo zijn dat Facebook hun foto's "logische" namen geeft met publiek beschikbare data. In dat geval zou je door het algoritme te kennen foto's kunnen zoeken. Dat lijkt hier echter niet het geval. De beveiligingsdeskundige moest tenslotte honderd duizenden keren raden. Ik ben het dus redelijk met Facebook eens. Ja, in theorie kan je alle foto's vinden. In praktijk is dat bij een redelijk ontworpen systeem een onmogelijke klus.

[copi]

Wat probeer je hiermee te zeggen? die 2^107 is totaal irrelevant, het is in een paar honderduizend pogingen te doen PUNT
Heel leuk dat jij een ander algoritme weet te bedenken, maar blijkbaar zijn ze bij Facebook daar nog niet opgekomen.
Als je maar een groot genoeg netwerk hebt (botnet) dan zijn die de URLs zo geraden en ik maak me sterkd dat facebook het doorheeft.

[Patrickkkk]

als ze nou gewoon een guid hiervoor gebruiken is het al aardig lastig te gokken

[David Mulder]

Wow, lange discussie, maar waar het hier dus vooral om gaat is dat je een gigantische overhead hebt zou je bij iedere request dit willen loggen en checken of de gebruiker is ingelogged. Daarom verwees ik al op het begin naar mechanismes in DDOS beschermingen die gewoon alles op merken en min of meer bijhouden hoe vaak een bepaalde gebruiker iets opened en het automatisch gaan limiteren als het te veel wordt, ook al kan dat al in de eerste plaats overkill zijn. Verder heeft OddesE absoluut gelijk dat dit niet security through obscurity is en als het binnen een paar weken te raden is misschien toch de lengte van de random string om hoog halen. _{(OFFTOPIC: En trouwens, mensen, wat hebben jullie er mee om dit algoritmes te noemen... het is natuurlijk per definitie niet incorrect... maar praktisch is dit echt geen algoritme te noemen...)}
En dan is er nog een heel ander voordeel van het huidige systeem, ik persoonlijk vind het heerlijk dat ik aan een vriend even snel een link van een afbeelding kan sturen zelfs als die persoon persoonlijk niet een vriend is van de eerste persoon. Natuurlijk is te beargumenteren dat dat niet hoort, maar sowieso zou ik het kunnen downloaden en op nieuw sturen naar wie dan ook, dus daar gaat het niet om.

[Anoniem: 305829]

[...]

De fotoName die door bovenstaand algoritme wordt gegenereerd kun je niet voorspellen, ondanks dat je het algoritme kent. Dit kan net zo goed 3.jpg zijn als 1239325288.jpg.

erm... de fotonaam die door jou algoritmetje worden gegenereerd zijn vrij makkelijk te achterhalen om heel eerlijk te zijn. De Random die je hier gebruikt is namelijk stiekem helemaal niet random. Computers zijn namelijk niet in staat om een 100% Random te genereren. Om tot de uitslag van deze random te komen gebruikt het achterliggende algoritme een bepaalde seed. Aangezien bij deze Random deze seed vrij statisch is (een algoritme gebaseerd op de tijd) kun je na een aantal resultaten het volgende resultaat voorspellen, en dus ook eerdere resultaten.

[MicGlou]

De personen boven mij leggen het al prima uit... ik wou alleen nog even toevoegen: doe jij die 100.000 request maar via je eigen pc-tje richting facebook met de kans op 1 of 2 hits voor een foto... dat zal je wss zelfs een permanente ip-ban opleveren. Want je bent dan eigenlijk gewoon een kleine ddos-aanval aan het uitvoeren. Plus de vertraging die absoluut tusen de requests in zal zitten. Ik kan mij niet voorstellen dat ze daar bijvoorbeeld toestaan meerdere requests binnen een seconde te kunnen doen.

[Bartjezz]

Dan krijg ik weer de gedachte, waarom een algoritme? Maak gewoon een random name generator die op commando even een bestandsnaam van 18 karakters uitpoept en klaar, geen voorspelbaar algoritme meer

[Zoop]

In theorie zal je dan ook 2x dezelfde naam random kunnen krijgen, in dat geval krijg je problemen, dan moet je eerst een hele db afscannen of de naam al niet bestaat. Iets sequentieels erin is over het algemeen niet te vermijden. Hoe een bestand heet, hoort ook helemaal niks uit te maken. De sessie cookies moeten gewoon gecontroleerd worden of je zoiets mag zien of niet.

Het is leuk dat je het met een simpel voorstel komt, maar zaken als deze moeten gewoon juist goed over nagedacht worden. Terwijl dit ook geen nieuwe technologie is, ofzo. Meer een kwestie van implementeren dan ontwikkelen.

[humbug]

Tsja, je kan bij alles de state controleren. Maar in praktijk willen grotere sites juist zoveel mogelijk stateless doen. Dit schaalt namelijk wezenlijk beter. Het is dus een kwestie van afwegen en in veel gevallen worden statische objecten als foto's gewoon op een aparte server neergezet waar geen state wordt bijgehouden.

In dit geval zie ik zelfs bij de volumes van facebook geen praktische hack optie en is state controleren dus een dure oplossing voor een theoretisch probleem.

[OddesE]

in dat geval krijg je problemen, dan moet je eerst een hele db afscannen of de naam al niet bestaat

Mwoa. Dit simpele algoritme zou al vrij goed werken:

boolean photoNameFound = false;
while (! photoNameFound) {
String photoName = generatePhotoName();
File photoFile = new File(photoFolder, photoName);
photoNameFound = ! photoFile.exists();
}

(er vanuit gaande dat generatePhotoName() een redelijk grote filenaam genereert en dat photoFolder de map is waarin de foto's worden opgeslagen).

Denk er aan dat als je fotoNaam groot genoeg is om veilig te zijn qua raadbaarheid, de kans op botsingen ook heel klein wordt, waardoor gemiddeld deze loop slechts één keer doorlopen zal worden. Slechts die zeldzame keer dat het toch mis gaat kiezen we gewoon een nieuwe naam. De DB hoeft dus absoluut niet gescanned te worden.

[Zoop]

Zoals sysosmaster ook aangeeft ... een filesystem is ook een db.
Mooi loopje, maar als die het bestaan van een naam moet controleren van miljarden items, en dat bij iedere nieuwe foto, kan je zelf ook denk ik wel begrijpen dat het totaal niet efficient is.

[Herko_ter_Horst]

Ik weet nog iets veel beters: controleer gewoon de rechten van de gebruiker voor het benaderen van het plaatje. Hoef je helemaal niet moeilijk te gaan doen met algoritmes.

Check of de gebruiker een vriend is van de eigenaar van het plaatje en klaar ben je...

[Sysosmaster]

um, wat jij doet is een database scannen .
(ieder Filesysteem is tenslotten ook een Database)

en met de schaal van facebook is dit zeker een hele slechte optie. (scan jij maar eens een folder waarin per seconden 10k nieuwe items bijkomen. dan snap je wat het probleem is)

meest practise voor facebook is met een pregenerated tabel werken met filenames, die door een secundair systeem worden geleverd. (op een voorspelbare manier)

of ze het ook gemaakt hebben zou je facbook moeten vragen trouwens. maar ik schat van wel.

op de schaal van facebook telt ieder bitje dat word verstuurd of berekend!

[Gomez12]

Meer een kwestie van kosten dan wat anders.

Met een CDN heb je gewoon dit soort problemen omdat het veelal niet te betalen is om op een CDN een script/htaccess te draaien.

Een CDN verzorgt bandbreedte en ruimte. Geen beveiliging.

Wil je beveiliging dan moet je gewoon geen CDN nemen, maar zelf een zooitje webservers online knallen en beheren

[OddesE]

Waarom een algoritme? Maak gewoon een random name generator

Ook een random name generator is een algoritme.

18 karakters zou inderdaad genoeg moeten zijn om een redelijk veilige bestandsnaam te genereren hoewel het ook hier uitmaakt hoe je dat doet. Bijvoorbeeld spaties mogen niet in een URL, maar elk teken dat je weghaalt uit de set waaruit je kiest verkleint de totale hoeveelheid mogelijkheden en maakt brute force makkelijker.

Overigens zijn de 'honderdduizenden mogelijkheden' waarover het hoofd beveiliging van Facebook spreekt er echt best weinig. Als je uitgaat van 64 verschillende karakters in de set (wat niet onlogisch is, zie bijv. Base64), dan heb je met 3 karakters al 262.144 mogelijkheden (64 tot de macht 3). Toch vinden de meeste mensen een wachtwoord van 3 letters niet echt veilig denk ik!

Oftewel dit hoofd beveiliging spreekt zichzelf eigenlijk tegen en ze zouden er beter aan doen om de kraak wat serieuzer te nemen en te zorgen dat ze de grootte van het bereik wat verhogen en andere maatregelen zoals ik iets hoger al heb genoemd te nemen.

[Sysosmaster]

En hoeveel echte Random Generators ken jij?
want echt random (dus random in de wiskundige zin) bestaad niet in de PC wereld.
het izjn altijd pseudo-random generators, die met een algeritme een waarde terug geven die random lijkt te zijn.

zodra je weet welke random generator word gebruikt zou je kunnen gaan voorspellen welke bestandsnamen er kunnen zijn.

vergeet ook niet de schaal van facebook. 18 karakters lijkt me niet voldoende.

[Anoniem: 91169]

Overigens vermoed ik dat Hyves eenzelfde probleem heeft. Ik kan namelijk zonder problemen van privé foto's van mij op Hyves de URL kopiëren en vervolgens kan iedereen die ik die URL geef de foto bekijken.

Als iemand zijn foto's enkel zichtbaar heeft voor vrienden of vrienden van vrienden dan kun krijg je middels die URL niet te zien als je niet tot die groepen behoort.

[Anoniem: 134117]

Nou, hier lukt dat in ieder geval niet.

[eM.]

Voeg Picasaweb ook maar toe aan het lijstje

[alopex]

De meeste beveiligingssystemen zijn via brute-force te kraken alleen beveiligen de mensen die de systemen maken zich door zo'n lang mogelijke en complex mogelijke wachtwoorden etc. te maken. En dan kan men bijvoorbeeld een time-out van één seconde instellen na 3 keer proberen. Uiteindelijk zal het wel lukken maar het zal lang duren

Het probleem met de url's is dat je via je browser naar de foto surft en dus niet via een ander script moet en dan moet je al via de website gaan controleren wie random links zit in te vullen.

[Kevin-de-Groot]

Kun je niet met htaccess kijken of er een afbeelding wordt aangeroepen, zo ja, dan kijken of er een geldige cookie aanwezig is? A.d.h. daarvan kun je weer checks uitvoeren. Of zeg ik nu iets doms?

[Zoop]

Neuh, lijkt me goed op te lossen op zo'n manier. Het probleem is denk ik dan processorkracht, het feit dat die foto's zo te raden zijn getuigd dat ze dus in een op het web bereikbare locatie staan.

Om dit te beveiligen zou je de foto's op een locatie kunnen zetten die niet via de browser de bereiken is (dus alleen door beheerder van de server). Vervolgens wordt er een verzoek gedaan aan een serverside script voor een foto, de cookie wordt gecontroleerd, en de foto wordt getoond. Dit betekend wel dat het door een server behandelt moet worden ipv dat het plaatje direct uit een map te vissen is. In het geval van facebook met miljarden(?) foto's kan dat best een impact zijn op processorkracht, denk ik.

Kan geen ander excuus verzinnen dan dit (al heb ik geen idee of zoiets ook echt zo'n impact heeft)

[alopex]

Je kan via de htaccess directory's ontoegankelijk maken voor direct(url) gebruik en daar dan je foto's in zetten zodat ze alleen via een script geladen kunnen worden.

De suggestie van Zoop is anders ook wel goed maar de foto's van facebook worden denk ik al van een ander domein gehaald (dat verspreid is over verschillende servers).

[Ellutu]

Het is wat Zoop zegt; de reden dat Facebook een CDN gebruikt is dat het een snel, cookie-loos mechanisme is om supersnel afbeeldingen te serven tegen zo laag mogelijke processorkracht. Sterker nog, het gaat expres naar een ander domein om te voorkomen dat er cookies mee worden gezonden (dat kost immers alleen maar bandbreedte en gaat ten koste van de snelheid). Die machines draaien vermoedelijk niet eens een webserver die capabel is enige vorm van beveiliging, puur een filename -> spuug uit naar browser servertje dat nauwelijks CPU gebruikt.

Om nog enige vorm van beveiliging te hebben gebruiken ze dus (random?) tekenreeksen voor de bestandsnamen, die dan weer wel beveiligd in de user databases staan. Voor een random tekenreeks is 200.000 pogingen tamelijk weinig trouwens (met 6 willekeurige tekens zit je immers al aan miljarden mogelijkheden), dus er zal wel iets niet helemaal goed zitten.

[Precision]

200.000 pogingen per dag
FTFY

[Anoniem: 151857]

dus beetje bruteforcen op foto-id's, en dan random mensen chanteren is wel een mogelijkheid?

[Dykam]

Alleen niet een "beetje".

[ravenamp]

Ach, geen enkele manier op internet is 100% veilig. Als je prive-foto's op internet zet moet je niet gaan lopen miepen als ze toch ergens heenlekken. Je moet ze in de eerste plaats niet op het internet zetten!

[roy-t]

Feit blijft dus dat die fotos niet beveiligd zijn, op geen enkele manier, als je de goede link hebt kun je de foto zien. Lijkt me toch er kwalijk en niet heel erg moeilijk op te lossen. Ook al is het moeilijk om de URL goed te gokken.

[Reactie gewijzigd door roy-t op 24 juli 2024 21:55]

[Gert]

Tja, afweging tussen functionaliteit en beveiliging.
Die foto's beschermen met iets dynamisch als het controleren van gebruikers gegevens levert op de schaal van Facebook een enorme extra belasting op.

[Barleone]

Nou... afweging? Sullivan ontkent dat het een noemenswaardig probleem is. Hij bagatelliseert dus de waarde van privégegevens van klanten. Nice! ku*sarcasm*uch.

[OddesE]

Ja en nee.

Hij erkent dat het een probleem is. Ok. Je kunt zeggen dat hij het probleem bagetalliseert, ok. Maar laten we ook geen denkfouten maken.

Ten eerste is de foto wél beveiligd want je moet eerst de naam weten. Anders kun je net zo goed zeggen dat een account überhaupt niet beveiligd is want je hoeft immers alleen het wachtwoord te raden. Het gaat er dus alleen om hoe moeilijk het is om het wachtwoord te raden.

Ten tweede is informatie die je 'in de groep gooit' om zo maar te zeggen natuurlijk nooit echt goed beveiligd. Je vrienden kunnen wellicht roddelen tegen andere mensen over jou. Ze kunnen een foto van jou weer doorsharen, of gewoon opslaan op hun schijf, printen, doormailen etc. Dus je moet wel perspectief houden.

De stelling dat

Feit blijft dus dat die fotos niet beveiligd zijn, op geen enkele manier, als je de goede link hebt kun je de foto zien.

is dus ook maar ten dele waar. Vervang 'foto's' in bovenstaande voor 'accounts'en 'de goede link' voor 'het wachtwoord' en je ziet meteen dat de foto's wel degelijk beschermd zijn. Nu deel je je wachtwoord nooit met anderen en de link naar de foto wel, maar dat geldt ook voor de foto zelf! Oftewel als je de link hebt naar de foto dan heb je de foto, maar die link krijg je alleen als je een vriend bent en dan krijg je ook de foto. Het enige wat hier belangrijk is is hoe moeilijk je zo'n foto kunt raden, hoevaak je mag proberen enzovoorts.

[Anoniem: 305829]

Echter is een URL op geen enkele manier hetzelfde als een wachtwoord. Niemand zal namelijk zo stom zijn om een systeem te ontwikkelen welke het wachtwoord van een gebruiker expliciet deelt met een deel van de andere gebruikers. Terwijl dit bij de URL voor de foto's wel gebeurd.

[alopex]

Zoals hij al zegt kan je met veel keren raden ook wachtwoorden van personen vinden. Het is een beetje zoals een woordenboek afgaan. Maar ze weten nog wel niet zeker of hij zo te werk is gegaan.

Heinrich had dit beter direct aan Facebook gemeld in plaats van nu te claimen dat hij foto's op zijn manier heeft verkregen. Hij is toch een beveiligingsexpert voor iets, om iets aan te tonen maar niet te misbruiken.

De foto's zijn inderdaad via een url traceerbaar omdat ze gewoon als jpg bestand worden opgeslagen. Ze zouden beter een soort van htaccess maken die directe toegang tot de foto verbiedt en zodat de scripts alleen maar aan de foto's kunnen en die scripts kunnen op hun beurt dan weer beveiligd worden door login-systemen etc.

[Reactie gewijzigd door alopex op 24 juli 2024 21:55]

[jbemmel]

Punt is dat ze op het wachtwoord proces waarschijnlijk een limiet hebben gezet op het aantal keer dat je kunt proberen. Ook kan een account automatisch geblokkeerd worden bij een X aantal keer verkeerd inloggen. Voor foto's kunnen ze dat soort maatregelen kennelijk moeilijk implementeren, waardoor brute force attacks mogelijk zijn

[nick_]

Ik blijf het verdacht vinden dat ze zeggen geen lek te hebben, maar die Grubb is wel opgepakt en zijn iPad in beslag genomen? Dat spreekt elkaar dan wel tegen.

[humbug]

Grubb beweerde een lek gevonden te hebben en is daarna opgepakt. Hierna zijn zijn claims getoetst en kwam Facebook tot de conclusie dat de methode van Grubb in de praktijk niet werkt. En dus is er geen probleem. Maar wel een lek.

[Anoniem: 309835]

Volgens mij is foto's kunnen bekijken zonder vriend te zijn juist een functie van facebook. Zo kun je foto's erop zetten en een speciale link die je dan krijgt via mail ofzo delen met iedereen die je die foto's wil laten zien. Die personen hoeven daarvoor niet eens een facebook account te hebben.

Dat deze functie met brute force te achterhalen is lijkt me logisch.

[robvanwijk]

Naam artikel: "Facebook: er zijn geen problemen met privéfoto's"
Dit heeft niks te maken met foto's die toch al gedeeld worden met "iedereen", het gaat juist om foto's die niet gedeeld worden, maar toch te bekijken zijn! En dat lijkt mij wel degelijk kwalijk.

[MrQuincle]

Ik zou voor elke URL een foto retourneren, gewoon van Google images of zo. :-) Ga dan nog maar eens zoeken welke de "echte" geheime foto's zijn...