Bin ja bisher recht still hier in den Foren, zu dem Thema hab ich mir mal ein paar Gedanken und ein paar Zahlen gemacht:
Einen Geochecker bei OC: find ich zunächst keine so blöde Idee, so etwas (natürlich optional) direkt in der Plattform zu integrieren. Bricht einen nicht immer so aus Seite heraus, und mittels OKAPI wär das sogar von Apps aus möglich nutzbar zu machen (was natürlich auch Angriffe vereinfachen würde).
Das Risiko: auf jeden Fall gut, dass hier sofort darüber nachgedacht wird, wie das nach hinten losgehen könnte. Gibt da natürlich verschiedene Angriffsszenarien. Gegen das direkte Abfragen einzelner Lösungen über den normalen Weg bräuchte man natürlich etwas. Auf Seiten geht sowas dann meist mit Captchas, das wird über okapi natürlich schwierig. So groß, wie OC derzeit ist, könnte man das wohl sogar über ganz brutale absolute Beschränkungen machen (sowas wie maximal 60 Anfragen pro Stunde - oder irgendwas, Zahlen kann man feintunen).
Totalausfall: Worüber hier zuletzt spekuliert wurde, ist ein ganz anderer Fall: totale Offenlegung der OC Datenbank. Sollte das passieren, wären natürlich noch ganz andere Probleme akut, aber um die geht es uns hier ja gerade nicht. Das Szenario ist: Eve hat die Tabelle für den geochecker ausgelesen, weil sie die Finalkoordinaten in ihrer bösen Facebookgruppe veröffentlichen will. Damit kann man dann virtuelle Gummipunkte sammeln, nachdem man trotzdem noch den physischen Ort aufgesucht hat. Diesen Angriff kann man natürlich erschweren, indem man nicht die Koordinaten speichert, sondern nur einen kryptografischen Hash selbiger (ähnlich wie beim Speichern von Passwörtern). Dann könnte man die Koordinaten nicht auslesen, sondern müsste die noch bruteforcen oder sonstwie angreifen (bei der gehackten Geocheckerseite waren die offensichtlich im Klartext gespeichert).
Zahlen: ich hab mal versucht, mit Zahlen aus den Fingern zu saugen. Wie viele potentielle Lösungen gibt es für einen Cache? Das ist sehr endlich, das stimmt, aber auch nicht so wenig (da zweidimensional -> wächst im Quadrat). Für meine Abschätzungen habe ich angenähert gesagt: eine Bogenminute Länge entspricht 1km (tatsächlich 1,190km), eine Bogenminute Breite entspricht 2km (tatsächlich in Deutschland ca. 1,850km) (Quelle: http://www.iaktueller.de/exx.php sowie irgenwo in diesem Forum, wo das schon mal jemand so angenähert hat).
Wenn ich nun die Fläche eines Kreises von n Metern Radius berechnen will, muss also die Fläche einer Ellipse berechnen, mit den Halbachsen der Länge n und n/2:
(siehe
https://de.wikipedia.org/wiki/Ellipse#Formelsammlung_.28Fl.C3.A4cheninhalt_und_Umfang.29)
Das gibt mir für folgende maximale angenommene Entfernungen n um die Anfangskoordinaten mögliche Koordinaten (ca):
Maximale EntfernungMöglichkeiten
100m15.700
200m62.800
500m392.700
1km1.570.000
2km6.280.000
Falls ihr Fehler in meiner Mathematik findet, haut sie mir bitte um die Ohren.
Kann man das bruteforcen? Klar! Lohnt sich das? Keine Ahnung. Bei einer ordentlichen Hashfunktion (scrypt wäre meine Wahl, aber PBKDF2 oder bcrypt wären Alternativen), dann kann man das so einrichten, dass eine Berechnung auch auf spezialisierten Maschinen noch recht lange dauert (und entsprechend hohe Kosten hat). Das würde natürlich auch das "legale" Prüfen in der Software relativ rechenaufwändig machen. Ich würde dann sogar dazu tendieren, die typischen falschen Koordinaten, die einem einen weiteren Hint geben (wunderschöne Funktion, wenn es den Checker gibt, dann bitte damit), im Klartext zu speichern. Außerdem hätte man sonst als Owner auch bald keine Übersicht mehr (schließlich bedeutet verschlüsseltes Speichern, dass die Software die Koordinaten nicht anzeigen kann).
Fazit: falls noch jemand bis hier mitgelesen hat: ich persönlich halte das Risiko bei einer vernünftigen Hashfunktion (skalierbar) für überschaubar. Wir kommen da in Bereiche, wo es ähnlich aufwändig ist, einfach die Rätsel zu lösen, und dann die Koordinaten untereinander auszutauschen. Und wem seine Finals so wichtig sind, der kann ja auf den Geochecker verzichten. Einen ausführlichen Text dazu kann man ja bei dieser Funktion verlinken (ich halte die Funktion sowieso für ein leicht advanced feature, wenn man sowas richtig verstehen will, muss man sich da eh Zeit für nehmen).
Sidenote: in dem Zusammenhang ist mir aufgefallen, dass sich bei den Logpasswörtern anscheinend noch niemand solche Gedanken gemacht hat. Die werden offensichtlich im Klartext gespeichert. Sollte die DB mal fallen, wären alle Virtuals mit Logpasswort für den Angreifer logbar, ohne die Möglichkeit eines Abgleichs mit dem (ja nunmal nicht vorhandenen) Logbuch. Müsste man dann nicht auch da mal was machen?
