Pasfoto in cloud met enkele hash te benaderen

[c-nan]

Tegenwoordig is het mogelijk om online je rijbewijs te verlengen. Een pasfoto kan je laten maken bij een door de RDW erkende fotograaf of door de RDW goedgekeurde fotocabine.

Afgelopen zaterdag heb ik een fotograaf bezocht, pasfoto gemaakt en alles in orde gemaakt, werkt allemaal prima.

De fotograaf heeft mijn pasfoto ook "naar de cloud" (Secure Cloud Storage) geupload. Ik heb een geprinte pasfoto meegekregen + een link om mijn pasfoto digitaal te downloaden. De url bevat enkel een hash van 8 tekens, verder hoef je helemaal niks in te vullen om de pasfoto te downloaden. Mag dit überhaupt op deze manier?

Het voelt toch niet helemaal goed dat een hele database met fotos online staat wat te benaderen is door een hash te raden.

[Lelletje]

Bedoel je niet zo'n verkorte URL die naar een langere URL doorstuurt?

[Ernemmer]

Alleen een foto heeft natuurlijk geen waarde zolang er verder geen gegevens bekend zijn.

[eLScha]

Hoe ziet die hash eruit? Kleine letters, hoofdletters en cijfers geeft je al 62 opties per positie.

62^8 = 218.340.105.584.896

Ik hoop dat er ergens bij de Cloud Storage een rate limiter afgaat als iemand zoveel requests probeert te maken.

[c-nan]

Lelletje schreef op maandag 27 februari 2023 @ 08:48:
Bedoel je niet zo'n verkorte URL die naar een langere URL doorstuurt?

www.domein.com/<hash> verwijst je naar www.domein.com/admin/photo/<hash>, vervolgens kan je de pasfoto downloaden.

[ Voor 23% gewijzigd door c-nan op 27-02-2023 08:57 ]

[c-nan]

eLScha schreef op maandag 27 februari 2023 @ 08:56:
Hoe ziet die hash eruit? Kleine letters, hoofdletters en cijfers geeft je al 62 opties per positie.

62^8 = 218.340.105.584.896

Ik hoop dat er ergens bij de Cloud Storage een rate limiter afgaat als iemand zoveel requests probeert te maken.

0-9 en a-z. Geen hoofdletters. Zet je er zelf bewust een hoofdletter in wordt er automatisch een klein letter van gemaakt.

[Croga]

Dat zijn dus alsnog 2.821.109.907.456 mogelijkheden. En als je dan een foto tegen komt heb je alsnog geen idee van wie die dan is.

Er zijn eenvoudigere manieren om een digitale foto van iemand te bemachtigen....

[eLScha]

c-nan schreef op maandag 27 februari 2023 @ 08:57:
[...]

0-9 en a-z. Geen hoofdletters. Zet je er zelf bewust een hoofdletter in wordt er automatisch een klein letter van gemaakt.

36^8=2.821.109.907.456

Uitgaande van 100.000 foto’s in die database heb je elke 3 miljoen requests een keer raak.

Dat is geen extreem hoog getal, maar als de infra juist is ingericht dan zou er na een X aantal foutieve requests een blokkade moeten optreden.

[ID-College]

Ik weet niet hoelang ze blijven staan, maar vaak is het maar 7 dagen.. In principe kan je "raden" maar het kan ook goed zijn dat ze na een week (of 2 weken alweer weg zijn). In principe kan je elke URL raden en verwacht ook niet dat er miljoenen foto's worden gemaakt per dag, waarmee de slagingskans eigenlijk zeer klein is dat je toevallig een combinatie raadt waar ook nog een foto achter zit

[Rukapul]

Het probleem met dit soort mechanismen is niet de theorie, maar de praktische uitvoering.

Als alle partijen in de keten de 'hash' als 'secret' behandelen, de 'hash' voldoende entropie bevat om niet geraden te worden, dan kan het goed gaan. In de praktijk gaat het vaak alsnog fout.

eLScha schreef op maandag 27 februari 2023 @ 09:00:
[...]


36^8=2.821.109.907.456

Uitgaande van 100.000 foto’s in die database heb je elke 3 miljoen requests een keer raak.

Ik kom op 28 miljoen uit, maar dat doet er niet aan af dat de hash te kort is. Je wil juist dat de resterende kans even groot is als dat van een sterk wachtwoord. De lengte van de hash plus marge bepaal je aan de hand daarvan.

Dat is geen extreem hoog getal, maar als de infra juist is ingericht dan zou er na een X aantal foutieve requests een blokkade moeten optreden.

Dat ligt subtieler bij dit soort guessing aanvallen. Dan moet de hele infrastructuur globaal een rate limiter hebben omdat er in principe een oneindige hoeveelheid parallele requests van verschillende bronnen kunnen plaatsvinden.

Beste los je dit gewoon op door een geschikte 'hash' lengte, of om het concept heel zuiver te houden: voeg een 'photo id' toe in combinatie met de huidige hash die je vervolgens 'password' of 'code' noemt. Mag je technisch vervolgens nog steeds concateneren, maar dan weet je waar welke veiligheid aan ontleend wordt. Usable security FTW.

[F_J_K]

8 tekens is kort - maar bij 26+10 karakters nog steeds 2821 miljard mogelijkheden. Er zijn 11,6 miljoen rijbewijzen. Stel 1x per 5 jaar vervangen (grove overschatting), zeg 2 miljoen per jaar. Dat is een kans van 1 op een miljoen dat een hash resulteert in een random hit. Als je wordt geblokkeerd na 10 keer, kans zo goed als nul. (Als...) Neemt niet weg dat je zou verwachten dat je na openen van de link nog een keer bijv je mailadres moet opgeven. En dat de hash te kort is.

-

Ik deed het toevallig dit weekend. Hier geen mail gekregen voor de digi foto's. Is het een dienst van de fotograaf zelf? Een stuk erger vond ik dat de foto's gewoon naar Mijn Documenten gingen en daar honderden foto's stonden.

[laurens0619]

Als ik het goed begrijp wordt er dus een "magic link" ipv authenticatie gebruikt.
Wat zijn de risicos tov secure login?

1. Link wordt gebruteforced << complex genoeg
2. Linkje wordt doorgestuurd inclusief "authentication token" << een beetje site haalt de hash weg uit de url nadat je erop geklikt hebt om dit risico te verkleinen.
3. Pasfoto kan bekeken worden na toegang mailbox <

Eigenlijk is het enige reeele risico is dat de pasfoto bekeken kan worden als die uit je mailbox gevist wordt of als de link lekt. Voor dit type data lijkt het mij een prima oplossing.

Beter dit dan dat ik weer ergens een account moet aanmaken waarvan de gegevens alleen maar gelekt kunnen worden

[Dido]

Voor mijn beeldvorming, maar stel dat ik een werkende hash raad.

Dan heb ik toegang tot een pasfoto van een willekeurig persoon.

Wat is het probleem hiermee?

Als het zou gaan om een ontwikkelservice waar je je "vakantiefoto's" laat afdrukken snap ik het nog wel, maar dit?

Als ik het aan google vraag krijg ik ook genoeg pasfoto's voorgeschoteld.

[downtime]

c-nan schreef op maandag 27 februari 2023 @ 08:39:

De url bevat enkel een hash van 8 tekens, verder hoef je helemaal niks in te vullen om de pasfoto te downloaden. Mag dit überhaupt op deze manier?

Het voelt toch niet helemaal goed dat een hele database met fotos online staat wat te benaderen is door een hash te raden.

Is het wel een hash? Waarom denk je dat?

Ik gok dat het gewoon een random gegenereerde link is.

[kodak]

Het lijkt vooral een probleem dat niet duidelijk is waarom je het mag zien als veilige opslag, terwijl er een gezichtsfoto dus zeer persoonlijke gegevens in opgeslagen worden.

De beveiliging gaat niet alleen over een vermoeden dat er risico is, maar ook dat de eigenaar en verwerkers aantonen dat het veilig is. Ik weet niet wat de fotograaf kan doen, ik zie niet wie er toegang (gehad) hebben tot de pasfoto, ik zie geen testresultaten dat het alleen werkt zoals de bedoeling is.

Laat de eigenaar en de verwerkers dus vooral open zijn dat ze het veilig ontworpen hebben, welke keuzes gemaakt zijn, getest is en ze genoeg controleren. En de broncode mag hierbij ook wel publiek verwacht worden. Anders heeft het vooral de verwachting van gemak, niet dat het werkelijk een veilige opslag is.

[djwice]

Bij schoolfoto's vergelijkbaar gehad, zat ook een code bij die ik in moest vullen.
Op de pagina zelf had de foto url gewoon een opvolgend nummer, dus konden die zo opgevraagd worden.
En in het bestel proces werd dat nummer gebruikt, dus kon ik ook foto's van anderen bestellen.

Dus ondanks de theoretische veiligheid maakte de implementatie het onbeschermd.

De foto's hadden ook meta data, zoals moment en lokatie van opname.

Het betaalsysteem gebruikte ook een opvolgend ID en bevatte additionele data zoals alle gegevens behorende bij eerdere aankopen.

De ontwikkelaar heeft dit na melding 'gefixt' met een md5 (2019).

Dus samengevat: context is everything.
Als je een lange hash ziet zegt dat nog niets.