mikrocontroller.net

Forum: PC-Programmierung "Absaugen" von Daten aus Web-Datenbank verhindern?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Kunde von uns führt für ca. 90% aller auf Europas Schienennetz 
fahrenden Bau- und Messfahrzeuge (vereinfacht: Alles was Gelb ist), eine 
Datenbank. Das kommt daher, dass für diese Fahrzeuge eine Art 
"Typenschild", die sog. "Anschriftentafel" mit wichtigen technischen und 
rechtlichen Informationen erforderlich ist. Diese Tafeln werden bei ihm 
nicht nur bestellt, gesetzt, gedruckt und versand, sondern auch mit dem 
notwendigen Sachverstand inhaltlich betreut.

Beispiele:

https://www.bahnbilder.de/1024/zweiwegeunimog-mit-saugbaggeraufbau-am-22102011-560260.jpg

https://www.bahnbilder.de/1024/anschriftentafel-zweiwege-schleifmaschine-rrgm-560508.jpg

https://i0.wp.com/hellertal.startbilder.de/1200/nachschuss-auf-drehhobelzug-d-hob-2500-658697.jpg?w=600

Das in der Datenbank enthaltene Wissen soll nun den Kunden (Betreiber 
und Hersteller von Gleisbaumaschinen u.ä.) und 
interessierten/berechtigten Personen auch über das Internet zugänglich 
gemacht werden. Ansich ist das, was auf den Tafeln steht, kein 
Geheimnis, denn das kann jeder, der einer solchen Maschine begegnet, 
sowieso auf der ca. 30x30cm großen Tafel lesen oder gar fotografieren.

Für den Bürobetrieb bekommen die Kunden jeweils ein klassisches Pärchen 
aus Benutzername und Passwort, das ist kein Problem.

Für den Einsatz "im Felde" für Techniker, TÜV-Prüfer, Revisoren etc. 
soll auf der Tafel ein QR-Code angebracht werden, der einen 
entsprechenden Link enthält. Dann werden neben den Informationen die auf 
der Tafel stehen, noch zusätzliche Daten angezeigt (Revisions- und 
Besitzer-Historie, Kontaktdaten, weitere technische Details usw.).

Und hier beginnt das praktische Problem. Das Ausreichen von Benutzername 
und Passwort an diesen Personenkreis ist organisatorisch unmöglich. 
Ebenso die Erstellung und Verteilung einer eigenen App, über die man den 
Zugang freischalten könnte.

Nun ist der Inhalt ansich kein Geheimnis, dennoch soll das massenhafte 
oder automatische Abgreifen der Daten verhindert werden, ohne die 
"normale" Nutzung unnötig zu erschweren. Dafür habe ich mir folgende 
"Hindernisse" ausgedacht und ich wollte mal die Meinung dazu hören. Die 
"Strafe" ist jeweils die Sperrung der entsprechenden IP-Adresse für 
einen gewissen Zeitraum (der noch festzulegen wäre):

- die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit 
einem nicht existierenden Hash führt zur Sperre

- die Anzahl der Zugriffe auf existierende Links pro Zeit ist limitiert. 
Mehr als z.B. 1 Zugriff pro Minute führt zur Sperre

- ein einfaches Captcha wird generell vorgeschaltet

Ist das halbwegs "wasserdicht"? Wir reden jetzt nur über Zugangsversuche 
auf dem offiziellen Weg. Dass so ein System auch "von Hinten" gehackt 
werden kann, ist bekannt und nicht Gegenstand der Frage. Danke für Tips.

: Bearbeitet durch User
Autor: Waffel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das Sperren der IPs ist zweischneidig. IPs sind nicht zwangsläufig 
eindeutig einer Person zugeordnet. Bei einer Fritzbox kosetet es z.B. 
einen mausklick einfach eine neue zu kriegen...

Vorschlag:
Sieh dir an wie Sharehoster öffentliche Downloadlinks erzeugen.

Vereinfach:
Die URL enthält am keine Daten oder IDs, sonder eine "unique id". Eine 
UUID zu erraten ist fast unmöglich. - Und dabei ist es egal wie viele 
man kennt - Jeder der diese UUID aber kennt, kann den Datensatz abrufen. 
Im Code am Typenschild ist nur die UUID hinterlegt, über die man die 
Daten abrufen kann.

Das heißt, im schlimmsten Fall kann ein Benutzer nur alle Datensätze 
abrufen, für die er die IDs kennt.

Autor: Marten Morten (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank E. schrieb:
> Die
> "Strafe" ist jeweils die Sperrung der entsprechenden IP-Adresse für
> einen gewissen Zeitraum (der noch festzulegen wäre):

Meine Vorhersage: Wird nur Ärger geben. Da braucht es nur ein 
Firmennetz, das dafür sorgt, dass legale Anfragen mehrerer Personen 
dieser Firma so erscheinen, als ob sie von der selben IP kommen.

Alles was du einbaust ist Augenwischerei wenn der Zugriff prinzipbedingt 
offen für jedermann ist. Du kannst dich entscheiden, ob du ehrlich mit 
dem Kunden umgehst oder ob du ihm ein bisschen Schlangenöl verkaufst.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bau beim Server doch eine Verzögerung der Antwort von 200ms ein.

Wenn dann nur jede 1 000 000 Nummer gültig ist können praktisch keine 
Daten abgefragt werden.

Es sollte pro IP nur eine Abfrage zur gleichen Zeit möglich sein.

MfG

Klaus

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> - die Links (Parameter am Ende der URL) sind MD5-Hashes.

Wenn Du das Schema kennst aus dem die Hashes errechnet werden, kannst Du 
damit massenweise gültige URLs erzeugen und dann abfragen.

Das sollten daher statt dessen gute Zufallszahlen sein. Die von Waffel 
angesprochenen UUID-Algorithmen könnten das leisten. Eine andere 
Alternative ist sich einfach einen Strom an Zufallsdaten der gewünschten 
Länge zu holen und den als base64 codiert an die URL hängen.

Autor: Jens M. (schuchkleisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Captchas pesten den User an, würde ich nicht machen.
Zudem funktionieren sie nicht.

IP-Sperren sind im Lande der dynamischen IP Kwatsch, denn es gibt hinter 
Routern evtl. mehrere Leute mit für dich gleicher IP die ein 
berechtigtes Interesse haben, die vergraulst du auch.

Der Weg sind große zufällige IDs und eine Zeitverzögerung, die für den 
Menschen unerheblich ist, das Massenabgraben aber zuverlässig verzögert, 
so das es den "Hacker" nervt.
Da reicht ne halbe Sekunde oder so. Kann man ja bei Massenabfragen 
(einer Firma hinter einem Router) langsam anheben, bis 10 Sekunden ist 
für ehrliche Leute knapp nervig, aber akzeptabel, das Internet ist heute 
so lahm...
Und natürlich dauert es auch ne Sekunde, "ID unbekannt" zu errechnen ;)

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Waffel schrieb:
> Das Sperren der IPs ist zweischneidig.

Man sperrt nicht die IP, sondern einfach den Zugriff des 
Benutzer-Accounts für eine Weile, zum Beispiel so:

1. Letzten Abruf eines Datensatzes (T) in der DB pro User speichern
2. Nächsten Abruf desselben Users um T + 1min verzögern.

Es gibt zig Möglichkeiten, den Punkt 2 umzusetzen, angefangen von 
Hinweis: "Sie dürfen erst in 50 Sek, gehen Sie jetzt einen Kaffee 
trinken" bis zum Herunterzählen eines Sekundenzählers bis 0, bevor der 
eigentliche Download beginnt.

Autor: mh (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank M. schrieb:
> Waffel schrieb:
>> Das Sperren der IPs ist zweischneidig.
>
> Man sperrt nicht die IP, sondern einfach den Zugriff des
> Benutzer-Accounts für eine Weile, zum Beispiel so:

Das funktioniert wohl nicht, da:

Frank E. schrieb:
> Und hier beginnt das praktische Problem. Das Ausreichen von Benutzername
> und Passwort an diesen Personenkreis ist organisatorisch unmöglich.

Autor: Maxe (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> Das kommt daher, dass für diese Fahrzeuge eine Art
> "Typenschild", die sog. "Anschriftentafel" mit wichtigen technischen und
> rechtlichen Informationen erforderlich ist.
> [...]
> Ansich ist das, was auf den Tafeln steht, kein
> Geheimnis, denn das kann jeder, der einer solchen Maschine begegnet,
> sowieso auf der ca. 30x30cm großen Tafel lesen oder gar fotografieren.
Also wie ein KFZ-Kennzeichen. Ich sehe bei so einer Datenbank schon 
datenschutzrechtliche Probleme. Vermutlich stimmen die Kunden der 
Datenerfassung zu, die Weitergabe an Dritte ist aber nochmal eine andere 
Sache.


> Für den Bürobetrieb bekommen die Kunden jeweils ein klassisches Pärchen
> aus Benutzername und Passwort, das ist kein Problem.
> [...]
> Und hier beginnt das praktische Problem. Das Ausreichen von Benutzername
> und Passwort an diesen Personenkreis ist organisatorisch unmöglich.
Warum? Es sind ja auch Gruppenzugänge möglich (Benutzer TÜVSüd2019Q3).
Auf diese Weise ist Missbrauch auch leichter zu ermitteln und damit 
gezielte Vorkehrungen zu schaffen oder dem nachzugehen. Es könnten auch 
an die Besitzer Gruppenzugänge ausgeteilt werden, die sie dann selbst 
ihren Vertragspartnern weitergeben. So wäre gewährleistet, dass die 
Beitzer die Kontrolle darüber haben, wer an die weiterführenden Daten 
gelangt.

> [...] ohne die
> "normale" Nutzung unnötig zu erschweren. Dafür habe ich mir folgende
> "Hindernisse" ausgedacht und ich wollte mal die Meinung dazu hören. Die
> "Strafe" ist jeweils die Sperrung der entsprechenden IP-Adresse für
> einen gewissen Zeitraum (der noch festzulegen wäre):
Meine Erfahrung als Internetbenutzer ist, dass solche Mechanismen die 
Nutzung massiv erschweren und ein Benutzername und Passwort eigentlich 
das Einfachste ist.
Wenn jetzt ein Außendienstler vor der Maschine steht, den Code einscannt 
und von dir geblockt wird (bspw. weil er versehentlich im falschen 
Moment ein Reload macht oder ein Kollege über das gleiche Netz und IP 
gleichzeitig eine Abfrage absetzt), dann steht er unter Umständen recht 
blöd da, je nachdem wie wichtig die hinterlegten Daten für ihn in dem 
Moment sind.

Der vorschlag von "Waffel" mit den Unique-IDs würde verhindern, dass 
jemand mit nur einem bekannten Link die Datenbank durchsuchen kann, aber 
wenn jemand eine Liste mit Links hat, kann er alle automatisiert 
abfragen. Um das zu verhindern, könnte die ID ab und zu geändert werden, 
was wohl zu viel Aufwand ist.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vielleicht einfach die ID im Link verschlüsseln/verschleiern, so daß sie 
nicht mehr zu erraten ist.

Du könntest auch über eine zweite Tabelle gehen und dort für jeden User 
andere IDs für die Bilder hinterlegen, die nach einer kurzen Zeit (paar 
Minuten oder Sekunden nach dem Abruf) verfallen. Damit erübrigt sich 
jede Verschlüsselung, ausreichend große Zahlen oder Strings errät man in 
kurzer Zeit nicht und selbst wenn man mal einen errät ist nicht direkt 
klar, welches Bild man bekommt.

Damit wären zumindest die direkten IDs weg.

Wenn ich so ein System angreifen würde, dann würde ich es mit vielen 
Accounts und vielen IPs probieren. Die Frage wäre wer hat ein 
berechtigtes Interesse daran, die Datenbank abzufischen? Wenn jeder 
Account in einer endlichen Zeit jedes Bild abfragen kann, ist das 
praktisch nicht zu verhindern wenn sich jemand genug Zeit lässt.

Autor: Soeren K. (srkeingast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist leider wirklich so, dass fast alle Maßnahmen nichts bis überhaupt 
nichts bringen. Es ist heutzutage kein Problem 10, 100 oder 1000 
Maschinen zu mieten die alle mit anderen IP-Adressen die Datenbank 
crawlen. Das kostet nicht mal viel Geld, und ist mit wenigen Euros 
getan.

Um viele Einträge geht es denn?

Bezüglich der "IDs" oder "UUIDs": Es reicht vollkommen aus einen String 
mit z.Bsp. 8 Zeichen aus der Gruppe A-Za-z0-9 zu verwenden, das sind 
dann schon 620 Milliarden Möglichkeiten, die probiert keiner mehr 
schnell.

Damit werden deine QR-Codes auch lesbarer, du hast mehr Platz für 
Redundanz und die Kästchen werden größer, als wenn du eine URL mit 
mehreren Hundert Zeichen hinterlegst.

Du könntest noch Fake-Daten hinterlegen, die erreichbar sind falls es 
jemand systematisch probiert: https://de.wikipedia.org/wiki/Nihilartikel

Autor: vn nn (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> Und hier beginnt das praktische Problem. Das Ausreichen von Benutzername
> und Passwort an diesen Personenkreis ist organisatorisch unmöglich.
> Ebenso die Erstellung und Verteilung einer eigenen App, über die man den
> Zugang freischalten könnte.

3FA über 
https://de.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithmus 
oder 
https://de.wikipedia.org/wiki/Time-based_One-time_Password_Algorithmus.
Standardprotokoll, fertige Apps gibs in den üblichen Stores (Google 
Authenticator, MS Authenticator, etc. pp.) zum freien Download.

Alternativ bzw. als Fallback Token über SMS oder Email, vgl. SMS-TAN.

Ansonsten: Lass das jemanden machen, der sich auskennt damit. Das 
sicherste Konzept bringt nichts, wenn die Umsetzung kaputt ist.

Autor: Boschi (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Frank E. schrieb:

> Nun ist der Inhalt ansich kein Geheimnis, dennoch soll das massenhafte
> oder automatische Abgreifen der Daten verhindert werden, ohne die
> "normale" Nutzung unnötig zu erschweren. Dafür habe ich mir folgende
> "Hindernisse" ausgedacht und ich wollte mal die Meinung dazu hören. Die
> "Strafe" ist jeweils die Sperrung der entsprechenden IP-Adresse für
> einen gewissen Zeitraum (der noch festzulegen wäre):

Was für ein dämlicher Kokolores. Entweder die Daten sind geheim, dann 
darf sie nur ein berechtigter Benutzerkreis lesen, oder sie sind nicht 
geheim, dann darf sie jeder lesen. Wenn ein Botnet den Server mit 
invaliden Requests zuballert, dann kommt der ruckzuck an den Punkt, wo 
keiner mehr irgendwelche Daten lesen kann. Wenn jemand seine Daten nicht 
im Internet sehen möchte, dann sollte er dafür sorgen, dass sie auch 
nicht im Internet sichtbar sind. Es gibt genau so wenig ein dazwischen, 
wie es ein bisschen schwanger gibt.

Autor: Ntldr -. (ntldr)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> - die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit
> einem nicht existierenden Hash führt zur Sperre

Das ist unsinnig, da man relativ leicht ungültige MD5 Hashes vorher 
aussortieren kann, da man ja immer ein paar Grundinformationen zur 
echten URL besitzt. Beispielsweise kann ich ja davon ausgehen, dass 
keine Sonderzeichen in der echten URL vorkommen. Folglich werfe ich alle 
Hashes raus, deren Klartext Sonderzeichen enthält. Weiterhin kann ich, 
sobald ich einmalig eine echte URL gesehen habe, mir auch andere URLs 
zusammendenken.

> - die Anzahl der Zugriffe auf existierende Links pro Zeit ist limitiert.
> Mehr als z.B. 1 Zugriff pro Minute führt zur Sperre

Das ist eher nervig als hilfreich. Wenn ich wirklich Daten abgreifen 
will, komme ich mit einem großen haufen IPs an und umgehe deine Sperre. 
Andererseits wirst du so normale Nutzer aussperren, die hinter einer 
gemeinsamen Firewall hängen (z.B. zwei Mitarbeiter eines Kundens, oder 
auch zwei Nutzer im gleichen Mobilfunknetz hinter dem gleichen NAT).

> - ein einfaches Captcha wird generell vorgeschaltet

Kann man machen, praktisch kann man das auch recht einfach umgehen und 
diese ganzen Captchas nerven nurnoch.

Autor: Daffy (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ntldr -. schrieb:
> Das ist unsinnig, da man relativ leicht ungültige MD5 Hashes vorher
> aussortieren kann, da man ja immer ein paar Grundinformationen zur
> echten URL besitzt. Beispielsweise kann ich ja davon ausgehen, dass
> keine Sonderzeichen in der echten URL vorkommen. Folglich werfe ich alle
> Hashes raus, deren Klartext Sonderzeichen enthält. Weiterhin kann ich,
> sobald ich einmalig eine echte URL gesehen habe, mir auch andere URLs
> zusammendenken.

Was machst Du, wenn der QR nur die URL https://foo.bar/info/<md5>/ hat? 
Oder eine zufällige 16-stellige Nummer?
Außerdem kanne eine URL sehr wohl Sonderzeichen enthalten.
Weiterhin würde ich kein MD5 mehr nutzen, sondern mindestens SHA256. Ist 
hier eigentlich egal, aber besser nichts mehr mit MD5 anfangen.

Oder folgendes (nur zusammengesponnen):
1. QR hat nur https://foo.bar/validate/<rand-id>/
2. Diese Seite liefert u.a. eine JS Funktion mit bcrypt(<rand-id>)
3. Das Ergebnis geht in JS noch durch salted SHA256
4. Dann macht JS einen Redirect zu https://foo.bar/info/<sha256>/

Dadurch kann man den Client effektiv ausbremsen, denn bcrypt() hat auch 
einen Kostfaktor um die Berechnung weiter zu verlangsamen; damit kann es 
zB 3 Sekunden dauern bis der Redirect erfolgt. Außerdem kann man 
jederzeit die Ziel-URLs ändern, indem man das mitgelieferte Salt 
und/oder die Cost ändert. Bei zB 1200 Zielen hat man in einer Stunde 
(3600s) alle ids durch bcrypt laufen und frisch salzen lassen. Dadurch 
kann eine URL heute ok, nächste Woche aber falsch sein wodurch URL 
Listen nutzlos werden ohne daß jemand die ganzen QR Bapperl ändern 
müsste.

Oder aber man geht das profaner an. Da die Daten nicht geheim und eh für 
jeden einsehbar sind, kann man auch einen DB Dump zB als CSV zur 
Verfügung stellen. Wäre ja ein netter Service.

Aber ganz ehrlich würde ich mir keinen Kopf wegen sowas machen. Wenn 
einer richtig Interesse und Energie hat, holt er sich die Daten 
irgendwie.

Autor: Jan H. (j_hansen)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Boschi schrieb:
> Was für ein dämlicher Kokolores. Entweder die Daten sind geheim, dann
> darf sie nur ein berechtigter Benutzerkreis lesen, oder sie sind nicht
> geheim, dann darf sie jeder lesen.
> [...]
> Es gibt genau so wenig ein dazwischen,
> wie es ein bisschen schwanger gibt.

Was für ein Unsinn. Selbstverständlich ist dieses "dazwischen" ein 
valider Fall. Einerseits gibt es Geschäftsmodelle, die genau darauf 
aufbauen: jeder kann sich Börsekurse oder das Wetter ansehen, aber wer 
Massendaten haben möchte muss zahlen. Andererseits ist es bei gewissen 
Anwendungsfällen auch sinnvoll, völlige Sicherheit aufzugeben um die 
Nutzbarkeit deutlich zu erhöhen.

Autor: oszi40 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Was für ein Unsinn. Selbstverständlich ist dieses "dazwischen" ein
> valider Fall.

Man könnte die Daten hinter dem Link auch etwas verschlüsselt ablegen 
und den 99 Usern einen ZEITLICH befristeten Schlüssel geben? Damit wird 
gleichzeitig ausgeschlossen, daß Leute ewig Zugriff haben, die schon 
lange nicht mehr zuständig sind.

Autor: Klaus P. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> Ist das halbwegs "wasserdicht"? Wir reden jetzt nur über Zugangsversuche
> auf dem offiziellen Weg.

Den gelegentlichen Benutzer, der ein einfaches Skript schreibt, deckst 
du damit schon ab, aber kein geplantes Vorgehen mit einem verteilten 
Angriff.

"Wasserdicht" ist es also nicht, aber auch nicht ganz schlecht.

Die Idee, einen Fehlzugriff mit einer Verzögerung zu bestrafen ist 
grundsätzlich nicht schlecht, sollte aber dynamisch sein und wie schon 
geschrieben sind UUIDs / GUIDs dafür besser geeignet als MD5 Hashes. 
Schon eine UUID ist kaum zu erraten, und du kannst ja auch zwei 
hinterander angeben.

Bei der Sperre solltest du nicht nur die IP Adresse prüfen, weil ja 
mehrere Benutzer über einen Router gehen können (z.B. Prüfer gesammelt 
über ihr VPN). Die kommen dann alle mit der gleichen IP Adresse bei dir 
an.

Mit einem verschlüsselten Cookie könntest du den Zugriff pro Benutzer 
auf 1-2 Abfragen pro Minute begrenzen und immer langsamer machen. 
Allerdings kann ein böser Benutzer den Cookie einfach löschen...

Es kommt auch darauf an, um wieviele Datensätze es sich handelt. 1.000? 
10.000? 100.000 oder noch mehr?

Bei einer großen Anzahl von Datensätzen könntest du auch prüfen, 
wieviele  Daten insgesamt in einem Zeitraum abgefragt werden und die 
Zugriffe verlangsamen, wenn ein Missbrauchsverdacht besteht. Das 
funktioniert aber nur, wenn es sich um relativ viele Datensätze und 
wenige Benutzer handelt.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gib jedem Datensatz eine eindeutige zufällige(!) 256 Bit ID.

Die URL sieht dann so aus

http://example.com/<lange-id-base64>;

Auf jede gültige ID kommen 2 hoch dreistellig ungültige IDs. Wer also 
Daten absaugen will würde alle paar Milliarden Jahre mal zufällig einen 
gültigen Datensatz bekommen.

Wer das absaugen will und dann sieht wie die URL aufgebaut ist wird 
sofort sagen: "ok, das kannste vergessen, Zeitverschwendung auch nur 
drüber nachzudenken"

Fertig.

Captcha würd ich nicht machen, das nervt in dem Falle nur ohne 
irgendeinen Vorteil zu bringen.

Autor: Schlaumayerchen (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jan H. schrieb:

> aber wer Massendaten haben möchte muss zahlen.

Hahaha, ich bepiss mich gleich: MASSENDATEN ...

Wie viele Datensätze stehen denn zur Verfügung? 100.000? 500.000? 1 
Million? 10 Millionen? Nein, wahrscheinlich weit unter 20.000. Selbst 
wenn der Abruf  auf 10 sek. verzögert würde, wäre man automatisiert 
überschlägig in 2 Tagen durch.

Autor: Thomas (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
versteh ich das richtig, der QR-code enthält direkt den link zur 
Datenbank? Also wenn irgendwer das abscannt bekommt man Daten wie 
Besitzer-Historie, Adressen? Habt ihr gar keine Angst vor 
Datenschutzklagen durch zB. die Konkurrenz? Mut kann man nicht kaufen.

Autor: Joachim S. (oyo)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> - die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit
> einem nicht existierenden Hash führt zur Sperre
>
> - die Anzahl der Zugriffe auf existierende Links pro Zeit ist limitiert.
> Mehr als z.B. 1 Zugriff pro Minute führt zur Sperre
>
> - ein einfaches Captcha wird generell vorgeschaltet

Eine zufällig generierte ID mit genügend zufälligen Bits ist völlig 
ausreichend. Eine gewöhnliche UUID v4 z.B. hat 122 zufällige Bits, das 
ist bereits weit mehr als genug.

Solange sonst kein richtig doofer Fehler gemacht wird (z.B. ein 
öffentlicher Index aller existierende IDs oder so), bleibt einem 
potentiellen Datenabsauger dann nur Brute Force. Und das macht in diesen 
Grössenordnungen schlicht keinerlei Sinn. Angenommen, es gäbe stolze 
1.000.000 dieser Schienenfahrzeuge (in Wahrheit sind es vermutlich 
deutlich weniger), aber 2 hoch 122 Möglichkeiten, die man durchprobieren 
muss, dann wäre beim brute forcen durchschnittlich nur jeder 
5.000.000.000.000.000.000.000.000.000.000ste Versuch ein Treffer - und 
selbst dann hätte man erst einen einzigen Treffer, von 1.000.000.

Die Anzahl der Zugriffe pro Zeit limitieren - das ist im Sinne der 
ursprünglichen Aufgabenstellung zwar unnötig, könnte man aber vielleicht 
zur Abwehr von DOS-Attacken oder so trotzdem machen. Dann aber bitte mit 
deutlich mehr als nur 1 Zugriff pro Minute.

Captchas wiederum sind einfach nur des Teufels, die würden nur für Hass 
und Frust sorgen.

Autor: Joggel E. (jetztnicht)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich wuerd ein Login verlangen, und das protokollieren. Auf eine Abfrage 
gibt's einen dynamischen, einmaligen Link zu den Daten. Deren Endung ist 
jeweils eine einmalige 12 stellige Nummer gebildet aus 
BinHex(OpenSSL_GetRandom()). Die Anfrage kommt also als
Produkt123_a42338f6cf12456789aac23a

Mit dieser geht man dann durch eine Tabelle, verifiziert so die 
Gueltigkeit der Anfrage, gibt die Daten zurueck und loescht den Eintrag

Autor: Long Dong Silver (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> - die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit
Ein Hash von was?

Autor: Klaus (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
die Kosten beim Client einzubauen erscheint mir am sinnigsten. Sie den 
Beitrag mit bcrypt.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Thomas schrieb:
> versteh ich das richtig, der QR-code enthält direkt den link zur
> Datenbank? Also wenn irgendwer das abscannt bekommt man Daten wie
> Besitzer-Historie, Adressen? Habt ihr gar keine Angst vor
> Datenschutzklagen durch zB. die Konkurrenz? Mut kann man nicht kaufen.

a) Nein, das verstehst du nicht richtig
b) es gibt keine Konkurrenz bei 90%

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Long Dong Silver schrieb:
> Frank E. schrieb:
>> - die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit
> Ein Hash von was?

... von der sog. "VDM-Nummer", ist mit einem KFZ-Kennzeichen 
vergleichbar. War mal so angedacht, davon bin ich aber inzwischen weg, 
aufgrund der Hinweise hier.

Auch dass MD5 zu kurz ist und damit ein Zufallstreffer zu wahrschenlich, 
habe ich inzwischen verstanden. Und dass die quasi feste Beziehung 
zwischen Eingabewert und Hash-Ergebnis ein Risiko ist ...

Ich neige nun in Richtung UUID oder langer Zufallszahl, die über eine 
Datenbank auf dem Server in den korrekten Link zur Webseite aufgelöst 
wird. Selbst wenn sich jemand diesen Link kopiert, kennt er erstmal nur 
diese eine Seite.

Theoretisch könnte man die Einträge in diesen "Pseudo-DNS" und die Namen 
der HTML-Seiten regelmäßig ändern ... oder über irgendwelche Tricks in 
einer htaccess-Datei verschleiern (z.B. urlrewrite?). Dann noch auf den 
Referrer prüfen, so dass generell nur Zugriffe über die vorgeschaltete 
Landingpage möglich sind ... bin da noch am Grübeln.

: Bearbeitet durch User
Autor: Daffy (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank E. schrieb:
> a) Nein, das verstehst du nicht richtig

Also wenn Hinz und Kunz den QR-Code scannen, die Daten abrufen und da 
dann mein Name mit auftaucht, dann würde ich mich an den 
Datenschutzbeauftragten der Firma wenden. Falls der nicht reagiert, an 
die öffentliche Stelle.

Frank E. schrieb:
> b) es gibt keine Konkurrenz bei 90%

Das dachte die ehemalige Deutsche Post auch mal...

Frank E. schrieb:
> Dann noch auf den
> Referrer prüfen,

Süß. Fast die Hälfte meiner Bots schickt Referer und Useragent mit; oder 
"Auth" Cookies. Wenn Du Dich auf Daten verläßt die vom User kommen, dann 
hast Du schon verloren.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Daffy schrieb:
> Frank E. schrieb:
>> a) Nein, das verstehst du nicht richtig
>
> Also wenn Hinz und Kunz den QR-Code scannen, die Daten abrufen und da
> dann mein Name mit auftaucht, dann würde ich mich an den
> Datenschutzbeauftragten der Firma wenden. Falls der nicht reagiert, an
> die öffentliche Stelle.
>

Wieso sollte dein Name bei einer Gleisbaumaschine auftauchen?

Mir fällt jetzt ein Beispiel ein: Flightradar. Ist zwar von der 
Größenordnung absolut nicht vergleichbar, aber dort kann man auch auf 
das Flugzeg-Symbol klicken und es erscheint der Maschinentyp, 
Strecke/Ziel, Fluggesellschft u.v.a

Warum ist das kein Problem?

Autor: Jens M. (schuchkleisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Warum ist das kein Problem?

Weil man nicht sehen kann wer an Bord ist? Die Frage war doch nicht 
ernst, oder?
nice b8 m8, i r8 8/8...

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Jens M. schrieb:
> Frank E. schrieb:
>> Warum ist das kein Problem?
>
> Weil man nicht sehen kann wer an Bord ist? Die Frage war doch nicht
> ernst, oder?
> nice b8 m8, i r8 8/8...

Bei den Gleisbaumaschinen sieht man auch nicht, wer an Bord ist. Also:

- die Hersteller/Besitzer/Betreiber wollen, dass die Maschinendaten 
online abrufbar sind

- ganz grundsätzliche Daten ohne Passwort, aber mit gewissen 
Einschränkungen, so dass man nicht mal einfach so massenhaft 
herunterkopieren kann. Darum ging es im Eingangspost. Es soll 
unverhältmismäßig Arbeit im Verhältnis zum Ertrag machen und 
andererseits den einfachen Nutzer nicht übermäßig behindern. Es ging nie 
darum, die Daten unerreichbar und unhackbar zu verrammeln.

- weitergehende Detailinformationen sind nur nach Eingabe von User/Pass 
erreichbar

Ich habe hier einige wichtige Infos bekommen, Danke dafür. Leider melden 
sich immer auch die substanzlosen Quakfrösche ... aber das muss man dann 
einfach aushalten.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstens: Wenn die Daten geheim sind, dann mach Accounts. Müssen ja nicht 
persönlich sein, Firmenaccounts reichen auch.

Zweitens: Gegen ein automatisches "ich dumpe mal eben schnell die 
Datenbank" kannst du vorgehen, indem du die Antworten verzögerst. Kommen 
die Anfragen von einem Account schneller, wird entsprechend länger 
verzögert. Kommen die Anfragen noch schneller, wird ein Hinweis 
ausgegeben. Die exakten Grenzen kann man pro Account einstellen.

Drittens: Gegen jemanden, der die Daten wirklich haben will, kannst du 
nichts tun - außer jede einzelne Anfrage mit Kosten beaufschlagen. Die 
ersten drei Anfragen am Tag sind kostenfrei, ab dann kostet jede weitere 
Anfrage 5€ und muss extra bestätigt werden. Auch das braucht Accounts.

Viertens: Wenn die Daten öffentlich sind, sind sie öffentlich. Wenn sie 
privat sind, sind sie privat. Richte die Zugangsbeschränkungen nach den 
Daten. Du kannst auch ein VPN dazwischenschalten... wer Zugang zum VPN 
hat, kommt an die Datenbank ran.

Autor: Daffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Wieso sollte dein Name bei einer Gleisbaumaschine auftauchen?

Frank E. schrieb:
> Dann werden neben den Informationen die auf
> der Tafel stehen, noch zusätzliche Daten angezeigt (Revisions- und
> Besitzer-Historie, Kontaktdaten, weitere technische Details usw.).

Zugegeben, Gleisbaumaschinen werden selten von Privat gekauft, aber eine 
Besizer-Historie hat (mMn) öffentlich da nichts zu suchen. Das wäre ja 
so als ob jeder anhand des Kennzeichens abfragen kann, wer jemals das 
Auto besessen hat; da bekommt man ja nicht mal den aktuellen Besitzer im 
Vorbeigehen.
Und falls dann noch sowas drinsteht wie "2008/10/01; Radreifenwechsel; 
Werk Tüftelhaus; MA Mustermann, Max" ist es nicht mehr lustig.

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> die Hersteller/Besitzer/Betreiber wollen, dass die Maschinendaten online
> abrufbar sind

Warum fragen die eigentlich niemanden, der vom Fach ist?

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Daffy schrieb:
> Frank E. schrieb:
>> Wieso sollte dein Name bei einer Gleisbaumaschine auftauchen?
>
> Frank E. schrieb:
>> Dann werden neben den Informationen die auf
>> der Tafel stehen, noch zusätzliche Daten angezeigt (Revisions- und
>> Besitzer-Historie, Kontaktdaten, weitere technische Details usw.).
>
> Zugegeben, Gleisbaumaschinen werden selten von Privat gekauft, aber eine
> Besizer-Historie hat (mMn) öffentlich da nichts zu suchen. Das wäre ja
> so als ob jeder anhand des Kennzeichens abfragen kann, wer jemals das
> Auto besessen hat; da bekommt man ja nicht mal den aktuellen Besitzer im
> Vorbeigehen.
> Und falls dann noch sowas drinsteht wie "2008/10/01; Radreifenwechsel;
> Werk Tüftelhaus; MA Mustermann, Max" ist es nicht mehr lustig.

Quark mit Soße. Lesen und Verstehen sollten doch eigentlich eine Einheit 
bilden.

Ich hab mehrfach geschrieben, dass nur einige Informationen öffentlich 
sein sollen (das ist erwünscht und erlaubt), die weiteren Details jedoch 
hinter User/Pass. Was ist daran zu diskutieren?

Trotzdem sollte es nicht so ganz einfach sein, die öffentlichen Daten 
mal eben so massenhft zu kopieren. Dass dies mit entsprechendem Aufwand 
möglich ist, habe ich ebenfalls von Anfang an niemals in Frage gestellt. 
Und um genau solche erschwerenden Maßnahmen geht es - nicht mehr und 
nicht weniger.

Es ist mir ein Rätsel, warum es immer wieder Leute fertigbringen sich 
aufzuplustern und irgendwelchen Stuss am Thema vorbei zu fantasieren. 
Einfaches Kopieren erschweren, nicht unmöglich machen, denn sonst kann 
niemand die Webseite lesen.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
vn nn schrieb:
> Frank E. schrieb:
>> die Hersteller/Besitzer/Betreiber wollen, dass die Maschinendaten online
>> abrufbar sind
>
> Warum fragen die eigentlich niemanden, der vom Fach ist?

Weil du ein Dummschwätzer bist und wir die Daten haben. Und zwar nicht 
die eines Herstellers/Betreibers sondern ca. 90% aller.

: Bearbeitet durch User
Autor: hansi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einer Art pseudo-2FA?
Z.B. Wenn der (UUID-)Link über den QR-Code aufgerufen wird muss als 
"Passwort" die zugehörige Fahrzeugnummer (oder was auch immer vor Ort 
lesbar ist) abgetippt werden und erst dann hat man Zugriff auf die 
Daten.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
hansi schrieb:
> Z.B. Wenn der (UUID-)Link über den QR-Code aufgerufen wird muss als
> "Passwort" die zugehörige Fahrzeugnummer (oder was auch immer vor Ort
> lesbar ist) abgetippt werden und erst dann hat man Zugriff auf die
> Daten.

und was soll das bringen?

Die UUID ist doch auch zufällig und nur dem bekannt, der dieses Schild 
liest oder abscannt. Weitere Daten die auf dem selben Schild stehen, 
erhöhen dann nicht die Sicherheit, sondern nerven nur den legitimen 
Nutzer.

Autor: vn n. (wefwef_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Weil du ein Dummschwätzer bist

Mag sein. Zumindest werde ich nicht mit Aufgaben betrauf, von denen ich 
absolut keinen Plan habe, und wo ich mich dann auf Tips aus 
irgendwelchen Foren, die auch noch halb fachfremd sind, verlassen muss, 
sondern bleibe bei meinen Leisten. Die dieses Fachgebiet zufälligerweise 
sind.

Frank E. schrieb:
> und wir die Daten haben. Und zwar nicht
> die eines Herstellers/Betreibers sondern ca. 90% aller.

Und inwiefern ist das nun eine Antwort auf die Frage, warum ihr euch 
nicht jemanden ins Boot holt, der was davon versteht? Achso, das würde 
ja was kosten. Und ihr habt ja die Daten. Also warum nicht selbst 
irgendwas hinpfuschen, ohne absolute Basics zu kennen. Dabei adressieren 
Dinge wie TOTP ja haargenau dein Problem, und auch herkömmliche 
User/Password-Kombis sind nun wirklich kein Problem, auch im großen 
Stil. Andere schaffen das ja auch.

Aber ihr habt ja die Daten, und seid zu stolz (oder geizig), Leute von 
Fach zu engagieren. Stattdessen wird sich halt mal auf irgendwelche 
Forenposts verlassen.

hansi schrieb:
> Wie wäre es mit einer Art pseudo-2FA?
> Z.B. Wenn der (UUID-)Link über den QR-Code aufgerufen wird muss als
> "Passwort" die zugehörige Fahrzeugnummer (oder was auch immer vor Ort
> lesbar ist) abgetippt werden und erst dann hat man Zugriff auf die
> Daten.

Warum keine richtige 2FA? Weils zu gut funktioniert? Zu einfach? Zu 
sicher? Zu "Standard"?

Gerd E. schrieb:
> Die UUID ist doch auch zufällig und nur dem bekannt, der dieses Schild
> liest oder abscannt. Weitere Daten die auf dem selben Schild stehen,
> erhöhen dann nicht die Sicherheit, sondern nerven nur den legitimen
> Nutzer.

+1

User/Password, alternativ oder besser zusätzlich TOTP. Und das ganze 
doch bitte von jemandem implementieren lassen, der das schon mal gemacht 
hat.

Autor: FS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie verstehe ich das Problem nicht so richtig.

Ich würde zum Datenabruf einfach eine stinknormale Web-API zur Verfügung 
stellen, die zur Nutzung zwangsläufig einen API-Schlüssel erfordert. 
Damit verhindert man schon einmal, das ein Unbefugter den Dienst nutzt 
und der Endpunkt von Jedermann mit Requests bombardiert werden kann. An 
diese API-Schlüssel kann man dann auch individuell Quotas binden 
(Aufruflimits etc.) und bei Zweckentfremdung wird einfach der 
API-Schlüssel gesperrt. Von welcher IP die Zugriffe erfolgen ist dabei 
völlig unerheblich.

Dann könnte man die Ausgabe der API so einschränken, dass sensible, 
nicht öffentliche Informationen nur ausgegeben werden wenn man sich 
authentifiziert hat (z.B. über OAuth). Die YouTube Data API funktioniert 
beispielsweise nach diesem Schema.

Als QR-Code reicht dann eine simple Datensatzkennung (z.B. UUID) aus, 
die man einfach als Parameter der Web-API übergibt. Je nachdem, ob man 
angemeldet ist oder nicht, enthält man Datensätze in unterschiedlichem 
Umfang.

Als Client braucht es dann auch keine App, eine schlichte Website, die 
die Web-API nutzt, reicht völlig und ist auf allen Geräten nutzbar, die 
über einen Browser verfügen. Bei anonymen Zugriff kann man dann 
zusätzlich noch die Abfragen einschränken, z.B. ein mal pro Sekunde pro 
IP, ein Captcha-Mechanismus oder was auch immer.

Autor: Sven L. (sven_rvbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vn n. schrieb:
> Mag sein. Zumindest werde ich nicht mit Aufgaben betrauf, von denen ich
> absolut keinen Plan habe, und wo ich mich dann auf Tips aus
> irgendwelchen Foren, die auch noch halb fachfremd sind, verlassen muss,
> sondern bleibe bei meinen Leisten. Die dieses Fachgebiet zufälligerweise
> sind.

Reg dich nicht auf, ist absolut Standard bei Ihm. Er verdient gerne mit 
dem kostenlos von anderen erfragtem Wissen sein Geld.

Das ist hier nicht das erste Mal, das wurde Ihm so auch schon deutlich 
von einigen anderen hier im Forum gesagt, aber es passiert halt immer 
wieder.

Da finde ich es auch ein starkes Stück, jemandem der mal nicht durch die 
Blume die Wahrheit sagt als Dummschwätzer zu betiteln.

Mal ganz davon abgesehen, das hier der Kunde quasi an seiner Lösung mit 
diskutieren kann. Wenn ich als Kunde Daten hätte und der Programmierer 
tritt erstmal in der Weltgeschichte breit was das so ist, dem würde ich 
was erzählen.

Aber "Seine" Daten wird das Eisenbahnbundesamt sicher auch haben, so 
exclusiv wird das alles nicht sein, aber klingt halt wichtig, wenn man 
90% von irgendwetwas scheinbar hat oder betreut.

Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich ignoriere mal bisherige Antworten und plaudere einfach mal so vor 
mich hin... (zu heiss zum lesen)

Zunächst würde ich eine tokenbasierte Authentifizierng basteln für die 
QR Codes,
das ist einfach zu implementieren, dauerhaft gültig, für alle Zumutbar 
verlangt keinerlei Login
und dennoch ist sie nicht übertragbar!

Also QRCODE scannen Link enthält ZWEI Daten:
die ID des gescannten Objects
einen vereinfachten Zugangscode zu diesem Object (CRC32 der dritten 
Spalte in der Datenbank zB irgendetwas was relativ 'unique' scheint und 
nicht zu umfangreich, da es im Setup zum QR Code ersteinmal errechnet 
werden muss)

Die Webseite die aufgerufen wird,
prüft ob vereinfachter Code und ObjektID zusammengehören
und errechnet im Erfolgsfall nun anhand der IP des Nutzers
und des vereinfachten Zugangscode zusammen mit dem Timestamp einen Token
Dieser wird zusammen mit der ObjektID an eine zweite Seite geschickt.
(header redirect reicht)
Und sofern der Token passt werden die Infos zum Objekt angezeigt
falls nicht gibt's n Fehler

Token kann man 1Std gültig lassen, oder einen Tag, sie passen eh immer 
nur zu diesem exakt genau einen Objekt.

Und wenn man einen Cookie setzen kann,
kann der Nutzer die Seite dann auch für besagten Zeitraum erneut 
aufrufen, selbst wenn sich seine IP geändert hat. (history des Browsers 
funktiniert gewohnt)

Wichtig ist nur, dass anhand eines oder mehrerer solcher scans kein 
Zusammenhang zwischen vereinfachtem Zugangscode und ObjektID erkennbar 
ist, so dass ein Script nur über bruteforce objektID und Code matchen 
könnte (bruteforce attacken lassen sich ja relativ leicht aussperren zum 
Glück)

Kunden mit Login sind ja einfach zu verwalten

'sid

Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....achso ganz vergessen..
die Spalte ind er db muss natürlich unveränderlich sein,
ansonsten ist es sinnvoller einen neue Spalte anzulegen mit dem Code
(Random.org 7 Zeichen a-zA-Z0-9 zB) der dann als verinfachter 
ZUgangscode gilt.

... ich sag ja ist zu heiss heute ;)

'sid

Beitrag #5953602 wurde von einem Moderator gelöscht.
Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb im Beitrag #5953602:
> Bleiben lassen! Wer  in der heutigen Zeit nicht mit Passwort und
> Nutzername sich auf eurer Seite anmelden kann, sollte in Rente gehen
> oder gekündigt werden.

Was er sagen wollte ist,
dass es organisatorischer Irrsinn ist,
innerhalb von wenigen Tagen evntl hundertausende von Nutzern anzulegen,
da wird dann gerne mit Bestätigungsmails gepfuscht weil der ISP sonst im 
Kreis springt (ich hab mal für'n Kunden nur 5000 emailadressen überprüft 
und schwupp gab's Post!)
Also bei unbekannter Menge an Neuusern kann sich der Prozess über Wochen 
hinziehen,
und DAS ist was den Vorgang organisatorisch unmöglich macht.. nicht das 
einloggen des Einzelnen.

'sid

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> und DAS ist was den Vorgang organisatorisch unmöglich macht.. nicht das
> einloggen des Einzelnen.

Die Nutzer kommen doch aber nicht über Nacht! Und wenn diese schon da 
sind, gieng zuvor etwas gewaltig schief. Und jetzt ist Panik am Start 
weil man zuvor gepennt hatte...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> innerhalb von wenigen Tagen evntl
> hundertausende von Nutzern anzulegen,

Dann legt man eben einen Account pro Firma an.
"Bosch-Serviceaccount" - "Bertrand-Serviceaccount" - etc.

Die Daten sind doch sowieso nicht wichtig, sonst hätten wir die 
Diskussion nicht.

Autor: Jan H. (j_hansen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
sid schrieb:
> ansonsten ist es sinnvoller einen neue Spalte anzulegen mit dem Code
> (Random.org 7 Zeichen a-zA-Z0-9 zB) der dann als verinfachter
> ZUgangscode gilt.

Das wurde oben schon vorgeschlagen, allerdings mit einer ordentlichen 
Zufallszahl und diese dann im QR-Code als Schlüssel benutzt.

Und das reicht auch, dein Murks mit mehreren Codes, Redirects, Token, 
Cookies etc. bringt doch nichts außer Komplexität.

Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Die Nutzer kommen doch aber nicht über Nacht! Und wenn diese schon da
> sind, gieng zuvor etwas gewaltig schief. Und jetzt ist Panik am Start
> weil man zuvor gepennt hatte...

Naja
wenn man ein "neues System" aufziehen will, ohne dass man auf eine ein 
oder zweijährige Warmlaufphase hoffen kann
(wie in der Umstellung solcher typbeschilderung)
dann muss das neue System an Tag eins zugänglich sein.
In diesem Fall eben für aberhunderte TÜV und Werkstatt techniker, 
dutzende von Geeks und weiss der liebe Herrgott wen alles.
Im besten Fall legt man selbstredend user an,
aber das dauert ewig..

Und frei zugängliche Daten sollen eben NICHT hinter einem Login liegen,
deswegen heissen sie ja so!

Nimm als Beispiel IMDB
Na klar kannst Du da filmdaten abrufen soviele Du willst,
aber ab einer gewissen Anzahl pro Tag/Stunde wird die Amazon an den Hals 
springen und deine IP sperren (naja du bekomsmt n Deathtoken der dich 
interaktiv sperrt... egal)
Eben damit Du NICHT deren Datenbank online kopierst..
(sie bieten sogar offline Datensätze an weil es dennoch viele versuchen 
und so kann man die ehrlichen von den unehrlichen trennen ;))

Und dasselbe gilt eben auch für Frank, wenn ich ihn recht verstanden 
hab:
freier Zugang ja; unbeschränkt nein!
(nur eben ohne den offline Datensatz ala IMDB)

S. R. schrieb:
> Dann legt man eben einen Account pro Firma an.
> "Bosch-Serviceaccount" - "Bertrand-Serviceaccount" - etc.
>
> Die Daten sind doch sowieso nicht wichtig, sonst hätten wir die
> Diskussion nicht.

Oh Betriebs-logins.. die Hölle in Tüten!

Mitarbeiter XYZ vergisst das passwort und klickt auf "Passwort 
vergessen"
und schwupp keiner im Betrieb kann sich mehr einloggen es sei denn er 
ruft die email ab..
zu der KEINER zugang hat im Idealfall (ausser EINEM controlelr!)

tolle Idee!

Noch besser Mitarbeiter ABC ist verärgert und kündigt.. loggt sich nach 
seiner Kündigung ein (Monate später)
ändert zuerst die Emailadresse und dann das Passwort.. tadaaa!

Ernsthaft Freunde,
wer noch nie ne Userverwaltung programmiert hat sollte gaaaaanz 
entspannt zurückgelehnt sitzen und die Füsse hochlegen; denn natürlich 
sieht es einfach aus für das ungeübte Auge,
wer aber die Dynamik dahinter kennt und versuchen muss sich vor Schergen 
Dummköpfen und schlimmer Programmierfehlern zu schützen,
der weiss dass es hinter der banalen "username:passwort" Maske eine 
ganze Menge zu tun gibt.
Und nein auf github kann man sich da leider nicht verlassen.


'sid

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> freier Zugang ja; unbeschränkt nein!
> (nur eben ohne den offline Datensatz ala IMDB)

Dann kann er auch den Uploadspeed vom Server zum Nutzer reduzieren.

Sind die Daten nur Text bzw HTML, eventuell kleine Bilder dabei, reichen 
1kb/s aus damit der TÜV-Prüfer nach nem QR-Codescan die Daten der 
Maschine angezeigt bekommt. Das Kopieren der Datenbank wird dann aber 
extrem lange dauern. Und selbst wenn, sobald mehr als 10 Maschinen 
"geprüft" werden, kann man ja noch ein Delay von 10sek oder so einbauen, 
das sich dann addiert.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Mitarbeiter XYZ vergisst das passwort
> und klickt auf "Passwort vergessen"

Dann wird so eine Funktion schlicht nicht eingebaut, fertig.
Wer was ändern will, ruft an. Als Chef.

MaWin schrieb:
> Dann kann er auch den Uploadspeed vom Server zum Nutzer reduzieren.

Wurde auch bereits vorgeschlagen.

Nicht vergessen: Die Daten sind nicht wichtig.

Wenn man auf eine kompetente IT hoffen könnte, könnte man die Accounts 
auch auf die Firmen-IPs festnageln. Bei uns sitzt z.B. ein Zwangsproxy 
vor dem Internet, wenn man den einträgt, hat die gesamte Firma Zugriff.

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Wer was ändern will, ruft an. Als Chef.

Woher weiß der am anderen Ende ob das der Chef ist?


Und was soll der ganze Zirkus überhaupt? Entweder die Daten sind 
unkritrisch und jeder der vor dem Schild steht darf sie lesen, dann 
einfach so wie oben bereits geschrieben:

http://example.com/langer_zufälliger_schlüssel/

Fertig!

Oder die Daten sind vertraulich, dann bekommt jeder Berechtigte seinen 
eigenen Account, ansonsten URL so wie oben. Die zwei Möglichkeiten 
gibts. Alles andere was teilweise vorgeschlagen wurde ist hanebüchener 
Unsinn. Captcha ist auch Unsinn denn es gibt bei diesem Verfahren 
schlichtweg nichts zum maschinell absaugen.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> MaWin schrieb:
>> Dann kann er auch den Uploadspeed vom Server zum Nutzer reduzieren.
>
> Wurde auch bereits vorgeschlagen.

Warum sollte man das tun, der Nutzer kann doch eh immer nur einen 
Datensatz abrufen, um den nächsten abzurufen muss er physikalisch(!) 
seinen Hintern in Bewegung setzen und zum nächsten Schild gehen und da 
steht dann auch wieder nur der Datenbankschlüssel für genau einen 
einzigen Datensatz drauf.

Autor: Tobi P. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Eine Pin unter dem QR- Code reicht nicht?

Autor: Jan H. (j_hansen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobi P. schrieb:
> Eine Pin unter dem QR- Code reicht nicht?

Wozu? Zum Leute ärgern?

Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobi P. schrieb:
> Eine Pin unter dem QR- Code reicht nicht?

ooder man stopft den Pin direkt mit in die QR
(Stichwort: vereinfachten Zugangscode),
dann ist er nämlich redundant und bleibt lesbar solange der QR lesbar 
ist Leserlichkeit des Pin codes wegen Kratzern, abnutzung und/oder 
Farbstabilität etc..

MaWin schrieb:
> Dann kann er auch den Uploadspeed vom Server zum Nutzer reduzieren.
>
> Sind die Daten nur Text bzw HTML, eventuell kleine Bilder dabei, reichen
> 1kb/s aus damit der TÜV-Prüfer nach nem QR-Codescan die Daten der
> Maschine angezeigt bekommt. Das Kopieren der Datenbank wird dann aber
> extrem lange dauern. Und selbst wenn, sobald mehr als 10 Maschinen
> "geprüft" werden, kann man ja noch ein Delay von 10sek oder so einbauen,
> das sich dann addiert.

Man merkt, dass Du das Internet nur als Nutzer kennst fürchte ich.
die Richtung heisst im Sprachgebrauch übrigens download speed.. auch für 
BackEnd-Entwickler ;)

Downloadspeed Begrenzung ist das dämlichste was man tun könnte,
denn der gemeine Webserver (und damit meine ich die Server software -- 
wie apache, nginx und co) ist Verbindungsbasiert..
das heisst jeder user hat ein oder mehrere Verbindungen offen solange 
ein transfer läuft,
im Besten Fall so KURZ wie möglich da die maximale Anzahl gleichzeitiger 
Verbindungen immer begrenzt ist;
je länger man sie also offen hält, desto grösser die Chance dass der 
letzte User Fehlermeldungen sieht...
begrenzter download speed ist schlicht DUMM aus Sicht des Betreibers;
insbesondere bei kleinen Datenmengen!
(anders bei streaming portalen [Netflix und Co], da ist eine Begrenzung 
manchmal wünschenswert; aber das ist ein gaaanz anderes Thema )

'sid

Beitrag #5954102 wurde von einem Moderator gelöscht.
Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Was er sagen wollte ist,
> dass es organisatorischer Irrsinn ist,
> innerhalb von wenigen Tagen evntl hundertausende von Nutzern anzulegen,
> da wird dann gerne mit Bestätigungsmails gepfuscht weil der ISP sonst im
> Kreis springt (ich hab mal für'n Kunden nur 5000 emailadressen überprüft
> und schwupp gab's Post!)
> Also bei unbekannter Menge an Neuusern kann sich der Prozess über Wochen
> hinziehen,
> und DAS ist was den Vorgang organisatorisch unmöglich macht.. nicht das
> einloggen des Einzelnen.

Ach komm, so schwer ist das auch wieder nicht wenn man nur will, jede 
Firma die in das System rein will/soll, bekommt natürlich einen 
Adminuser und kann sich ihre Serviceuser dann selbst anlegen, damit wird 
der Aufwand deligiert.
Im idealfall bietet man auch gleich Single Sign-on und 
Active-Directory-Anbindung an. Alleine mit Active-Directory erschlägt 
man einen Großteil der Unternehmen.

Beitrag #5954132 wurde von einem Moderator gelöscht.
Autor: sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vn nn schrieb:
> Ach komm, so schwer ist das auch wieder nicht wenn man nur will, jede
> Firma die in das System rein will/soll, bekommt natürlich einen
> Adminuser und kann sich ihre Serviceuser dann selbst anlegen, damit wird
> der Aufwand deligiert.
> Im idealfall bietet man auch gleich Single Sign-on und
> Active-Directory-Anbindung an. Alleine mit Active-Directory erschlägt
> man einen Großteil der Unternehmen.

Schwierig?
Naja kommt auf den Standpunkt an ;)
Tokenimplementierung
weniger als zehn Zeilen Code, schlimmstenfalls eine neue spalte in der 
DB
neue templates: keine!
kosten ~ 200 Euro

Implementierung von SuperUsern inkl Rechte,
Eine zusätzliche Datenbanktabelle (5-6 Spalten)
Umstellug der Registrierungs Oberfläche (je nach template system 2 Std)
Umstellung des auto-mailers zur Anmeldung und Verwaltung von 
ServiceUsern
nochmal etwa 4-5 Stunden
inkl. Eingliederung ins bestehende System
Kosten: minimum 1200 Euro
Dank Datenschutzverordnung ist nämlich echt Essig.. streng genommen darf 
der AdminUser nichtmal die Emailadresse des ServiceUsers kennen...
Ich weiss da stören sich viele Firmen noch nicht dran.. bis die 
Klagewelle ins rollen kommt.

Single Sign-on ist doch wieder gaaanz andere Baustelle,
Und ernsthaft: wer sich mit google oder schlimmer facebook auf 
Drittseiten anmeldet hat eh den Schuss nicht gehört!
Sich seinen Datenschutz selber aushebeln weil man zu doof oder bequem 
ist.. grossartig!
und active directory scheint mir hier leider NULL Zielführend,
(ist auch seit bestimmt zehn Jahren kein wirkliches Thema mehr für html)
Wär meines Erachtens nur interessant wenn jeder User einen eigene 
"Datenbank" anlegen und erweiter können soll, die dann ggf über 
desktop/mobile app abgefragt werden kann (dann machten auch super und 
service user wieder sinn).

Aber klar, man kann alles implementieren wenn man die Zeit das Werkzeug 
und das Geld hat.
Login über Augenklimper-code oder user pfeifen in C-Dur,
knock-codes über Beschleunigungssensor.
automated GPS login...

Die Frage ist: WOZU mehr Mühe machen als notwendig,
wenn alles was man will ist das ein X-beliebiger user in der Lage ist 
EINE relevante Information auszulesen (QR-Code)
nicht aber ALLE anderen gleich mit (ID guessing verhindern)

Und dazu reicht ein recht banaler token.
Eingeloggte Nutzer können ja eh immer mit ZusatzInfos bedient werden,
macht für die also nichtmal n Unterschied,
der casual bystander kommt, kann ein Typschild lesen und sonst nix.

Egal..

'sid

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Schwierig?
> Naja kommt auf den Standpunkt an ;)
> Tokenimplementierung
> weniger als zehn Zeilen Code, schlimmstenfalls eine neue spalte in der
> DB
> neue templates: keine!
> kosten ~ 200 Euro
>
> Implementierung von SuperUsern inkl Rechte,
> Eine zusätzliche Datenbanktabelle (5-6 Spalten)
> Umstellug der Registrierungs Oberfläche (je nach template system 2 Std)
> Umstellung des auto-mailers zur Anmeldung und Verwaltung von
> ServiceUsern
> nochmal etwa 4-5 Stunden
> inkl. Eingliederung ins bestehende System
> Kosten: minimum 1200 Euro

Klar, wenn Geld das einzige ist, was zählt...

sid schrieb:
> Dank Datenschutzverordnung ist nämlich echt Essig.. streng genommen darf
> der AdminUser nichtmal die Emailadresse des ServiceUsers kennen...
> Ich weiss da stören sich viele Firmen noch nicht dran.. bis die
> Klagewelle ins rollen kommt.

So ein Blödsinn, warum soll der Superuser nicht die Mail des 
Serviceusers kennen dürfen? Vor allem, wenn die auch noch im gleichen 
Unternehmen sitzen...
Aber die Daten für jeden, der da am QR vorbeikommt lesbar zu haben, ist 
sicher DSGVO-Konform. Ja ne, klar.

sid schrieb:
> Single Sign-on ist doch wieder gaaanz andere Baustelle,
> Und ernsthaft: wer sich mit google oder schlimmer facebook auf
> Drittseiten anmeldet hat eh den Schuss nicht gehört!
> Sich seinen Datenschutz selber aushebeln weil man zu doof oder bequem
> ist.. grossartig!

Viele Unternehmen nutzen intern schon Office365-SSO, weil bei denen eh 
schon alles über die MS-Cloud läuft... Ob man es gut findet oder nicht 
steht nicht zur Debatte, Fakt ist, AD und Office365 ist de facto 
Standard in größeren Unternehmen. Daran ändert auch meine MS-Abneigung 
nichts.
Wie du in Firmenumgebungen auf Google oder gar Facebook kommst, ist mir 
schleierhaft...

sid schrieb:
> und active directory scheint mir hier leider NULL Zielführend,

Weil?

sid schrieb:
> (ist auch seit bestimmt zehn Jahren kein wirkliches Thema mehr für html)

Äh bitte was hat LDAP mit HTML zu tun?

sid schrieb:
> Die Frage ist: WOZU mehr Mühe machen als notwendig,
> wenn alles was man will ist das ein X-beliebiger user in der Lage ist
> EINE relevante Information auszulesen (QR-Code)
> nicht aber ALLE anderen gleich mit (ID guessing verhindern)

Dass es nicht zielführend sein wird, die komplette Maschinenhistorie 
jedem dahergelaufenen mit QR-Scanner zu präsentieren, wurde bereits 
weiter oben diskutiert.

Autor: vn nn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Eingeloggte Nutzer können ja eh immer mit ZusatzInfos bedient werden,
> macht für die also nichtmal n Unterschied,
> der casual bystander kommt, kann ein Typschild lesen und sonst nix.

Achso, also doch Benutzerkonten auch noch? Ich dachte, das ist sooooo 
doll viel Aufwand?

Autor: Echter Programmierer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sid schrieb:
> Also QRCODE scannen Link enthält ZWEI Daten:

Wozu diese obskure Vorgehensweise?

Ob der Zugangscode im QR-Code als n-Tupel interpretiert wird oder nicht, 
ist völlig belanglos.

Die Anzahl der Weiterleitungen ist ebenfalls völlig belanglos. Ebenso 
die konkreten Zwischenschritte zur Ziel-Ressource.


sid schrieb:
> Man merkt, dass Du das Internet nur als Nutzer kennst fürchte ich.

Man merkt, dass Du Softwareentwicklung nur als Anwender kennst.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich bin keiner, der ein Thema zündet und sich dann nicht mehr 
meldet (meistens jedenfalls). Bin am programmieren, liefere in der 
kommedne Woche mal eine Test-URL für Hackversuche.

Als ID verwende ich in dem QR-Code jetzt einen 64-stelligen HEX-Code 
(also 256 Bit), der keinen Zusammenahng zur Maschinenummer (VDM-Nummer) 
besitzt. Ich hatte ursprünglich Bedenken, dass dadurch der QR-Code zu 
kleinteilig-fizzelig wird (bei ca. 5x5cm), es geht aber ganz gut. Die 
Codes kommen bei mittlerer Redundanz mit 36 Pixel im Quadrat aus.

Durch die 256 Bit liegen die ca. 10000 Einträge im Wertebereich weit 
genug auseinander, um bei Rateversuchen oft genug falsche Codes zu 
treffen und dafür mit immer klebriger werdender Reaktionszeit bestraft 
zu werden ...

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank E. schrieb:
> und dafür mit immer klebriger werdender Reaktionszeit bestraft
> zu werden ...

Das wird gar keiner überhaupt erst versuchen wenn er sieht wie die URL 
aussieht. Und wenn er wirklich so blöd ist hört er nach ner halben 
Stunde von selber wieder auf wenn Mama sich beschwert daß "das Internet" 
plötzlich so zäh geht.

Es setzt sich schließĺich aus dem selben Grund auch keiner hin und 
versucht Bitcoin-Schlüssel zu bruteforcen weil man sofort abschätzen 
kann daß es selbst mit allen Computern der Welt Milliarden von Jahren 
dauern und theoretisch die Energie einer ganzen Sonne verschlingen würde 
die Nummern auch nur durchzuzählen (geschweige denn testen) bis man 
zufällig eine gültige erwischt.

Oder das Session-Cookie hier im Forum um zufällig einen 
Administrator-Account zu erwischen, ich wette gegen den Angriff gibts 
auch keine besonderen Maßnahmen weil der so absurd wäre daß ihn keiner 
überhaupt erst versucht!

Du kannst die üblichen Vorkehrungen gegen DoS Atacken anwenden aber 
wahrscheinlich wird keiner ausgerechnet Deinen Server versuchen in die 
Knie zu bringen.

Um die QR-Codes kleiner zu bekommen könntest Du Base64 nehmen anstatt 
Base16, dann sinds nur noch 43 Zeichen.

: Bearbeitet durch User
Autor: sid (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
vn nn schrieb:
> Achso, also doch Benutzerkonten auch noch? Ich dachte, das ist sooooo
> doll viel Aufwand?
Nur wenn man eine unabschätzbar hohe Anzahl Benutzerkonten in kurzer 
Zeit anlegen muss; im "alltagsleben" ist das banal..
Aber wie bei imbd.com ist eine Schnittstelle für nicht angemeldete 
Nutzer durchaus sinnvoll, und die muss eben auch gegen crawling 
abgesichert sein.

Und wann hab ich gesagt daß die Maschinenhistorie im QR steckt?
ich rede von maschinenID und einem zugewiesenen Code der die Abfrage aus 
der DB erlaubt.
(historie für nicht angemeldete nutzer zB auf aktuellsten Eintrag 
beschränkt, bei angemeldeten Nutzern vollständig... quasi als Bonus)

DAP egal welche sind ne katastrophe als Datenbankzugriff
(um den es nach Eingangspost geht) aber ja, wirf weiter mit Halbwissen 
rum ;)

Echter Programmierer schrieb:
> Wozu diese obskure Vorgehensweise?
>
> Ob der Zugangscode im QR-Code als n-Tupel interpretiert wird oder nicht,
> ist völlig belanglos.
>
> Die Anzahl der Weiterleitungen ist ebenfalls völlig belanglos. Ebenso
> die konkreten Zwischenschritte zur Ziel-Ressource.

Nein, und nein..
man braucht ZWEI unveränderbare werte die direkt zusammengehören zur 
verifikation des "nicht manipulierten" links.
ansonsten würde man wieder ein brute force türchen öffnen
(wieviele logins würd ich zB wohl finden wenn ich nur nach passworten 
bruteforcen würde OHNE dazugehörenden usernamen??)
Und klar kann man die in eine variable schreiben, nur wozu?

Man braucht im Erstaufruf ebenfalls eine weiterleitung
(kann verdeckt sein wenn man will) denn die Alternative hiesse 
asynchrones Javascript oder websocket, beides durchaus möglich, aber 
eben wieder vollendete Ressourcenverschwendung.

Echter Programmierer schrieb:
> Man merkt, dass Du Softwareentwicklung nur als Anwender kennst.
kicher netter Versuch... lässt mich an der Wahrhaftigkeit Deines 
Pseudonyms zweifeln ;)

'sid

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sid schrieb:

> man braucht ZWEI unveränderbare werte die direkt zusammengehören zur
> verifikation des "nicht manipulierten" links.

Nein, ob das als ein Tupel oder als ein einzelner Wert mit insgesamt 
genausoviel Bit übertragen wird macht keinen Unterschied. Im Gegenteil 
sogar: Deine Maschinennummer kann man raten, also ist ein Teil der Bits 
schon bekannt, das verkleinert den Suchraum erheblich, eine reine 
Zufalls-ID kann man aber nicht raten. Im vorliegenden Fall ist es also 
das einfachste einfach eine zufällige eindeutige ID zu generieren und in 
der Datenbank einen Index darauf. Diese ID kommt dann in den QR-Code, 
mehr ist nicht nötig.

> ansonsten würde man wieder ein brute force türchen öffnen

Die ID muss nur lang genug sein um Bruteforce unmöglich zu machen. 256 
Bit sind bei Weitem genug, 128 hätte wahrscheinlich auch schon gereicht. 
Umsomehr wenn er wie er es vor hat bei ungültigen IDs die anfragende IP 
mit einer Auszeit belegt (was IMHO eigentlich nicht nötig wäre denn zu 
Bruteforce wird es nicht kommen wenn dieses sowieso unmöglich ist).

> Man braucht im Erstaufruf ebenfalls eine weiterleitung

Nein, wozu? Das verkompliziert es nur ohne den geringsten Nutzen und es 
erhöht den Traffic auf dem Server. Jede Verkomplizierung die keinerlei 
Nutzen hat sollte unterbleiben.

: Bearbeitet durch User
Autor: vn n. (wefwef_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Nur wenn man eine unabschätzbar hohe Anzahl Benutzerkonten in kurzer
> Zeit anlegen muss;

Ach komm schon, andere schaffen das auch. Denkst du, du bzw. der T bist 
der einzige mit derartigen Problemen?
Sowas versucht man zu eliminieren (ActiveDirectory/Office365-Anschluss 
des Kunden ermöglichen,damit deckt man schon mal viele Firmen ab), 
automatisiert man weg (eine CSV-Liste mit Namen + eMail der Mitarbeiter 
kann dir der Kunde ja leicht zur Verfügung stellen) oder lagert es aus 
(Sekräterin beim Kunden bekommt die Berechtigung, Serviceaccounts für 
ihre Firma einzurichten).
Andere schaffen das auch, und müssen nicht ihre obskuren Ideen in Foren 
präsentieren.

sid schrieb:
> Aber wie bei imbd.com ist eine Schnittstelle für nicht angemeldete
> Nutzer durchaus sinnvoll, und die muss eben auch gegen crawling
> abgesichert sein.

Warum genau muss sie das? Entweder die Daten sind quasi-öffentlich und 
ohne jede Authentifizierung  zugreifbar, dann kann Crawling auch kein 
Problem sein. Oder sie sind es eben nicht.

sid schrieb:
> Und wann hab ich gesagt daß die Maschinenhistorie im QR steckt?
> ich rede von maschinenID und einem zugewiesenen Code der die Abfrage aus
> der DB erlaubt.

Wozu dann irgendeine Pseudoabsicherung, die eh nix nutzt?

sid schrieb:
> DAP egal welche sind ne katastrophe als Datenbankzugriff
> (um den es nach Eingangspost geht) aber ja, wirf weiter mit Halbwissen
> rum ;)

Bitte, erläutere doch weiter. Welches Halbwissen denn?

sid schrieb:
> Nein, und nein..
> man braucht ZWEI unveränderbare werte die direkt zusammengehören zur
> verifikation des "nicht manipulierten" links.
> ansonsten würde man wieder ein brute force türchen öffnen

Bitte, erklär doch mal, welchen Unterschied macht es deiner Meinung 
nach, ob du nun z.B. zwei Schlüssel a 128 Bit hast, oder nur einen mit 
256 Bit?

sid schrieb:
> Und klar kann man die in eine variable schreiben, nur wozu?

Wozu in zwei schreiben, außer um den QR aufzublähen und für Security 
through obscurity?

sid schrieb:
> (wieviele logins würd ich zB wohl finden wenn ich nur nach passworten
> bruteforcen würde OHNE dazugehörenden usernamen??)

Äpfel und Birnen. Wären wir wieder beim
> Halbwissen

sid schrieb:
> Man braucht im Erstaufruf ebenfalls eine weiterleitung
> (kann verdeckt sein wenn man will) denn die Alternative hiesse
> asynchrones Javascript oder websocket, beides durchaus möglich, aber
> eben wieder vollendete Ressourcenverschwendung.

Wofür genau brauchst du deine tollen Weiterleitungen?

sid schrieb:
> Echter Programmierer schrieb:
>> Man merkt, dass Du Softwareentwicklung nur als Anwender kennst.
> kicher netter Versuch... lässt mich an der Wahrhaftigkeit Deines
> Pseudonyms zweifeln ;)

Du kreuzt hier auf, stellst deine absolut obskuren Ideen vor, die daran 
zweifeln lassen, dass du für sowas qualifiziert bist, und ignorierst 
jede Meinung, die nicht deiner eigenen entspricht. Das lässt an 
einigem zweifeln...

: Bearbeitet durch User
Autor: Peter B. (basejump)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank E. schrieb:
> - ein einfaches Captcha wird generell vorgeschaltet

Also wenn gerade das HighSpeed-Datenvolumen aufgebraucht ist und man nur 
8kbyte/s verfügbar sind, dann sollte es auch funktionieren.
Diese Captchas von Google funktionieren dann aber nicht mehr, keine 
Ahnung was im Hintergrund passiert, aber es bricht irgend wann mit einer 
Fehlermeldung ab.

Autor: sid (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Nein, ob das als ein Tupel oder als ein einzelner Wert mit insgesamt
> genausoviel Bit übertragen wird macht keinen Unterschied. Im Gegenteil
> sogar: Deine Maschinennummer kann man raten, also ist ein Teil der Bits
> schon bekannt, das verkleinert den Suchraum erheblich, eine reine
> Zufalls-ID kann man aber nicht raten. Im vorliegenden Fall ist es also
> das einfachste einfach eine zufällige eindeutige ID zu generieren und in
> der Datenbank einen Index darauf. Diese ID kommt dann in den QR-Code,
> mehr ist nicht nötig.
>
Nene.. EBEN NICHT! eine für den Nutzer erkennbare ID ist immer Sinnvoll
insbesondere wenn man dem User einen erneuten aufruf aus der 
Browserhistorie ermöglichen will aber sei's drum.. klar kann man die 
zwei erkennbaren aber GETRENNTEN werte concaten, aber das bringt Dir 
nix, denn den Einzelaufruf über nur eine deindexte tabelle will man ja 
grade vermeiden!

> Die ID muss nur lang genug sein um Bruteforce unmöglich zu machen. 256
> Bit sind bei Weitem genug, 128 hätte wahrscheinlich auch schon gereicht.
> Umsomehr wenn er wie er es vor hat bei ungültigen IDs die anfragende IP
> mit einer Auszeit belegt (was IMHO eigentlich nicht nötig wäre denn zu
> Bruteforce wird es nicht kommen wenn dieses sowieso unmöglich ist).

Denn genau hier hakts.. klar sind 256bit ne Menge Holz..
aber bei einer Datenbank mit ausreichend Einträgen bekommt man dennoch 
eine ausreichend hohe wahrscheinlichkeit "irgendwas" zu treffen und 
damit lesen zu können, wenn man nur Zahlen rät; es macht also Sinn etwas 
wie ein "login:passwort"-Analog zu nutzen, vor allem weil es exakt 
derselbe oder gar weniger Aufwand ist als eine einzelne unique deindexte 
256bit folge.
(Select * from x where id... if (row[32c]!=GET[code]) =>)
oder eben( Select * from x where 256c ...if(!row) =>)
macht keinen nennenswerten unteschied..

>> Man braucht im Erstaufruf ebenfalls eine weiterleitung
>
> Nein, wozu? Das verkompliziert es nur ohne den geringsten Nutzen und es
> erhöht den Traffic auf dem Server. Jede Verkomplizierung die keinerlei
> Nutzen hat sollte unterbleiben.

NULL traffic auf dem Server! das einzige was getan wird ist der 
gegenwert eines file includes.. und im gegenteil eine 404 oder andere 
errorpage ist in der Regel DEUTLICH kleiner als die "korrekte Seite" man 
spart also traffic en masse (im Angriffs-szenario)
Und wenn (=> header("Location: errorpage");
) für Dich schon "verkomplizierend" ist, dann hab ich in der Tat keine 
Fragen mehr ;)
Wozu?
Nun ich für meinen Teil hab auf den errorpages gerne verdeckte Zähler...
wenn ein user 100te mal in denselben fehler rennt mit unterschiedlichen 
Aufrufen (bruteforcing von passcodes) dann werden seine Anfragen auch im 
Trefferfall für eine Weile als Fehler gemeldet um ihn ein bisschen zu 
demotivieren ;) Quasi ein cookieblock anstelle eines IP banns ;)

Aber wie auch immer,
ich mag das mit Euch echt nicht diskutieren...
ich weiss ja dass es so innerhalb von zehn Zeilen php implementiert ist 
und stabil läuft (hab ich ja in betrieb) aber klar.. office365anbindung 
hat das nicht..
ist der office käse denn abwärtskompatibel? was mit libre oder 
openoffice?
nicht? achwas.. jaaa das sind dann die Quatschköpfe deren Produkte so 
nette sachen melden wie "diese webseite ist nur mit chrome 52" 
kompatibel bitte nutzen sie einen anderen Browser...
Super, insbesondere für mobile Anwender immer ein echter Spass!
Und der Support sagt dann sowas wie: "nee also zwei Jahre alte Hardware 
supporten wir nichtmehr.. kaufen sie doch mal 50 neue Tablets für Ihre 
Aussendienstler damit sie unsere versch* internetseite aufrufen 
können..."

Macht mal, und zeigt mir mal wie's dann bei Euch aussieht ich bin 
gespannt.

'sid

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sid schrieb:
> [...]

Ich kann keine Argumente finden in Deinem wirren Text, deshalb muß ich 
zum Glück auch nicht einzeln darauf eingehen. Wie man es richtig macht 
hab ich ja weiter oben schon beschrieben, insofern sind also eigentlich 
alle Fragen schon geklärt.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sid schrieb:
> Denn genau hier hakts.. klar sind 256bit ne Menge Holz..
> aber bei einer Datenbank mit ausreichend Einträgen bekommt man
> dennoch eine ausreichend hohe wahrscheinlichkeit "irgendwas" zu
> treffen

Mathematik ist nicht gerade deine Stärke, oder?

Autor: Joachim S. (oyo)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
sid schrieb:
>> Die ID muss nur lang genug sein um Bruteforce unmöglich zu machen. 256
>> Bit sind bei Weitem genug, 128 hätte wahrscheinlich auch schon gereicht.
>> Umsomehr wenn er wie er es vor hat bei ungültigen IDs die anfragende IP
>> mit einer Auszeit belegt (was IMHO eigentlich nicht nötig wäre denn zu
>> Bruteforce wird es nicht kommen wenn dieses sowieso unmöglich ist).
>
> Denn genau hier hakts.. klar sind 256bit ne Menge Holz..
> aber bei einer Datenbank mit ausreichend Einträgen bekommt man dennoch
> eine ausreichend hohe wahrscheinlichkeit "irgendwas" zu treffen und
> damit lesen zu können, wenn man nur Zahlen rät; es macht also Sinn etwas
> wie ein "login:passwort"-Analog zu nutzen, vor allem weil es exakt
> derselbe oder gar weniger Aufwand ist als eine einzelne unique deindexte
> 256bit folge.

Entweder Du verschätzt Dich hier gerade massivst. Oder aber - was ich 
eher vermute! - hier liegt einfach ein dickes Missverständnis vor, und 
wir reden irgendwie aneinander vorbei.

Daher mal ein konkretes Beispiel:
Angenommen, in dem QR-Code auf dem Schild wäre bspw. folgende URL 
kodiert:
httpx://example.com/fahrzeug/5f6bc4d31474c890db89d5ca8fae4c207a712c28151b310e0cfc632e43acfd4b/

In der URL muss also jedes Fahrzeug durch eine 256-Bit-ID in 
hexazimal-Schreibweise referenziert werden. Diese 256-Bit-IDs werden per 
Zufallsgenerator erzeugt, und sind daher relativ gleichmässig über den 
256-Bit-Raum verteilt. Auf diesen gesamten 256-Bit-Raum verteilen sich 
de facto aber gerade mal ca. 10.000 Einträge (siehe hier: 
Beitrag "Re: "Absaugen" von Daten aus Web-Datenbank verhindern?")

Selbst, wenn ein hypothetischer brute-forcender Angreifer 10.000 IDs pro 
Sekunde überprüfen könnte (und dazu müsste der Webserver ja auch so 
viele Anfragen pro Sekunde bearbeiten können - realistisch dürfte aber 
eher vielleicht ein Zugriff pro Minute sein, warum also sollte man den 
Webserver derart leistungsfähig auslegen?), würde es im Mittel
2^256 geteilt durch 10000 Einträge geteilt durch 10000 Anfragen pro 
Sekunde geteilt durch 60 Sekunden pro Minute geteilt durch 60 Minuten 
pro Stunde geteilt durch 24 Stunden pro Tag geteilt durch 365 Tage pro 
Jahr =
ca. 
36.717.430.630.808.000.000.000.000.000.000.000.000.000.000.000.000.000.0 
00.000.000  Jahre dauern, um per Brute Force auch nur einen einzigen 
Eintrag zu finden - und nochmal 10.000 mal so lange, um alle Einträge zu 
finden.

Angesichts dieser irre hohen Zahl ist brute forcen hier ein völlig 
sinnloses Unterfangen. Man sieht daran auch, dass 256 Bit eigentlich 
völliger Overkill sind, denn selbst bei 128 Bit bräuchte man im Mittel 
noch  107.902.830.708.060.000.000.000 Jahre, um auch nur einen einzigen 
Eintrag zu finden.

Selbst 64 Bit wären in der Praxis völlig ausreichend, denn dann bräuchte 
man im Mittel immer noch 5849 Jahre, um einen einzigen Eintrag zu 
finden.

An Stelle des Threadstarters würde ich bei der Länge der Zufalls-ID 
übrigens wirklich nach dem Motto "so gross wie nötig, so kurz wie 
möglich" verfahren, statt (um auch wirklich auf Nummer sicher zu gehen) 
auf Masse zu setzen und stolze 256 Bit zu nehmen. Das macht zum einen 
den QR-Code kleiner - und wenn aus irgendeinem Grund mal ein Mensch die 
Zufalls-ID kommunizieren muss, ist eine 64-stellige Hexadezimalzahl auch 
deutlich nerviger und fehleranfälliger als eine "nur" 16-stellige 
Hexadezimalzahl.

Man bedenke: Anders als bei der Sicherheit irgendwelcher Hash-Funktionen 
oder Verschlüsselungsalgorithmen ist es hier nicht nötig, mögliche 
Schwachstellen oder die exponentiell steigende Leistungsfähigkeit der 
Computer in der Zukunft bereits im Vorfeld zu berücksichtigen. Denn 
anders als beim Knacken irgendwelcher Hashes oder Verschlüsselungs-Keys, 
wo ein einzelner Computer Milliarden Schlüssel pro Sekunde 
durchprobieren kann, und tausende Rechner parallel arbeiten können, ist 
hier der Webserver ein unvermeidlicher Flaschenhals, und es gibt auch 
keine potentiellen Schwachstellen im Algorithmus, deren Entdeckung die 
Anzahl der durchzuprobierenden Werte in der Zukunft massiv reduzieren 
könnten.

Autor: Echter Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> klar sind 256bit ne Menge Holz..
> aber bei einer Datenbank mit ausreichend Einträgen bekommt man dennoch
> eine ausreichend hohe wahrscheinlichkeit "irgendwas" zu treffen

Du bist ein Dummschwätzer. Einfach mal nachrechnen:

Ausgangsbedingungen:

  - 1 Millionen Datenbankeinträge
  - Zufällige 256-Bit ID pro Datensatz
  - Pro Sekunde 1 Millionen geratene IDs am Webserver(-farm) testbar
  - Wir geben uns mit einer Chance von 1 : 1000000 zufrieden eine ID
    zu erraten.


   2^256 = 1,16e77

   1,16e77 / 1000000 Datensätze = 1,16e71

   1,16e71 / 1000000 Tests pro Sekunde = 1,16e65 Sekunden

   1,16e65 / 3600 Sekunden pro Stunde = 3,22e61 Stunden

   3,22e61 / 24 Stunden pro Tag = 1,34e60 Tage

   1,34e60 / 365 Tage pro Jahr = 3,67e57 Jahre

   3,67e57 * Chance 1:1000000 = 3,67e51 Jahre


Abgerundet sind das ausgeschrieben

   3000000000000000000000000000000000000000000000000000 Jahre

die Du benötigst, um mit einer Chance von 1:1000000 einen 
Datenbankeintrag zu erraten, wenn Du pro Sekunde den Webserver eine 
Million mal kontaktierst.


Als Vergleiche, die Erde hat eine Masse von ca.

   6000000000000000000000000 Kilogramm.


Das Alter des Universum ist ca.

   435000000000000000 Sekunden (13,8 Milliarden Jahre)


Ganz ehrlich, wer bei 256 Bit auch nur eine Millisekunde daran denkt 
irgendetwas zu erraten, ist einfach nur Ahnungslos.


Übrigens, persönliche hätte ich mich mit 80 Bit zufrieden gegeben. Das 
gibt gröbere QR-Codes, die funktionieren in der Praxis bei Wind, Wetter 
und Schmutz besser.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim S. schrieb:
> An Stelle des Threadstarters würde ich bei der Länge der Zufalls-ID
> übrigens wirklich nach dem Motto "so gross wie nötig, so kurz wie
> möglich" verfahren, statt (um auch wirklich auf Nummer sicher zu gehen)
> auf Masse zu setzen und stolze 256 Bit zu nehmen. Das macht zum einen
> den QR-Code kleiner - und wenn aus irgendeinem Grund mal ein Mensch die
> Zufalls-ID kommunizieren muss, ist eine 64-stellige Hexadezimalzahl auch
> deutlich nerviger und fehleranfälliger als eine "nur" 16-stellige
> Hexadezimalzahl.

Für Menschen (und für QR-Codes, je nach Variante) ist es wahrscheinlich 
günstiger, mehr als die 4 Hex-Bits in ein Zeichen der URL zu packen.

Autor: Echter Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah,  Joachim S. hat es ja auch vorgerechnet (etwas schneller).

Autor: vn n. (wefwef_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> klar kann man die
> zwei erkennbaren aber GETRENNTEN werte concaten, aber das bringt Dir
> nix, denn den Einzelaufruf über nur eine deindexte tabelle will man ja
> grade vermeiden!
>
>> Die ID muss nur lang genug sein um Bruteforce unmöglich zu machen. 256
>> Bit sind bei Weitem genug, 128 hätte wahrscheinlich auch schon gereicht.
>> Umsomehr wenn er wie er es vor hat bei ungültigen IDs die anfragende IP
>> mit einer Auszeit belegt (was IMHO eigentlich nicht nötig wäre denn zu
>> Bruteforce wird es nicht kommen wenn dieses sowieso unmöglich ist).
>
> Denn genau hier hakts.. klar sind 256bit ne Menge Holz..
> aber bei einer Datenbank mit ausreichend Einträgen bekommt man dennoch
> eine ausreichend hohe wahrscheinlichkeit "irgendwas" zu treffen und
> damit lesen zu können, wenn man nur Zahlen rät; es macht also Sinn etwas
> wie ein "login:passwort"-Analog zu nutzen, vor allem weil es exakt
> derselbe oder gar weniger Aufwand ist als eine einzelne unique deindexte
> 256bit folge.
> (Select * from x where id... if (row[32c]!=GET[code]) =>)
> oder eben( Select * from x where 256c ...if(!row) =>)
> macht keinen nennenswerten unteschied..

Nochmal: Welchen Unterschied soll es machen, ob der Schlüssel in einer 
Tabellenspalte liegt, oder auf zwei aufgeteilt wurde?

sid schrieb:
> ist der office käse denn abwärtskompatibel? was mit libre oder
> openoffice?
> nicht? achwas.. jaaa das sind dann die Quatschköpfe deren Produkte so
> nette sachen melden wie "diese webseite ist nur mit chrome 52"
> kompatibel bitte nutzen sie einen anderen Browser...
> Super, insbesondere für mobile Anwender immer ein echter Spass!
> Und der Support sagt dann sowas wie: "nee also zwei Jahre alte Hardware
> supporten wir nichtmehr.. kaufen sie doch mal 50 neue Tablets für Ihre
> Aussendienstler damit sie unsere versch* internetseite aufrufen
> können..."

Um Gottes willen, bist du echt so ahnungslos? Ist das dir das echt nicht 
peinlich, ständig über Sachen zu schwafeln, bei denen du dich so 
überhaupt nicht auskennst?
Zu deiner Info, Office365 ist die Cloud-Variante von MS ActiveDirectory, 
einem System, dem System, welches vermutlich 90% der Mittelständler 
nutzen(entweder mit oder ohne Cloud), um die Benutzerverwaltung in ihrer 
IT abzuwickeln (nicht dass mir das gefällt oder ich MS mag, aber es ist 
nun mal Fakt). Das hat nicht, aber auch gar nicht mit Chrome, OpenOffice 
oder LibreOffice zu tun. Es ist einfach nur ein System, in dem du deine 
Benutzer verwaltest, und welches von anderen Enterprise-Anwendungen 
gerne mitgenutzt wird (selbst von Open Source, z.B. Jenkins). Das ganze 
hat auch nichts mit deinem Browser, oder gar deiner Hardware zu tun.
Meine Güte, du bist echt peinlich.

Joachim S. schrieb:
> Entweder Du verschätzt Dich hier gerade massivst. Oder aber - was ich
> eher vermute! - hier liegt einfach ein dickes Missverständnis vor, und
> wir reden irgendwie aneinander vorbei.

Ich tippe eher auf verschätzen.

Joachim S. schrieb:
> würde es im Mittel
> 2^256 geteilt durch 10000 Einträge geteilt durch 10000 Anfragen pro
> Sekunde geteilt durch 60 Sekunden pro Minute geteilt durch 60 Minuten
> pro Stunde geteilt durch 24 Stunden pro Tag geteilt durch 365 Tage pro
> Jahr =
> ca.
> 36.717.430.630.808.000.000.000.000.000.000.000.000.000.000.000.000.000.0
> 00.000.000  Jahre dauern, um per Brute Force auch nur einen einzigen
> Eintrag zu finden - und nochmal 10.000 mal so lange, um alle Einträge zu
> finden.

An der Stelle möchte ich dich insofern korrigieren, dass es für crawling 
ja egal ist, welchen Eintrag man gerade erwischt, und es somit 10.000 
mal kürzer dauert, da man die Chance auf einen Treffer 10.000:2^256 ist.
An der Größenordnung ändert das natürlich nichts, mit der hast du 
grundsätzlich schon recht, nur der vollständigkeit halber.

Joachim S. schrieb:
> Das macht zum einen
> den QR-Code kleiner - und wenn aus irgendeinem Grund mal ein Mensch die
> Zufalls-ID kommunizieren muss, ist eine 64-stellige Hexadezimalzahl auch
> deutlich nerviger und fehleranfälliger als eine "nur" 16-stellige
> Hexadezimalzahl.

Wobei man auch Base64 nehmen könnte statt einfach nur einen Hex-String, 
macht die Sache auch kürzer (allerdings blöder zu buchstabieren übers 
Telefon).

Autor: Joachim S. (oyo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vn n. schrieb:
> Joachim S. schrieb:
>> Das macht zum einen
>> den QR-Code kleiner - und wenn aus irgendeinem Grund mal ein Mensch die
>> Zufalls-ID kommunizieren muss, ist eine 64-stellige Hexadezimalzahl auch
>> deutlich nerviger und fehleranfälliger als eine "nur" 16-stellige
>> Hexadezimalzahl.
>
> Wobei man auch Base64 nehmen könnte statt einfach nur einen Hex-String,
> macht die Sache auch kürzer (allerdings blöder zu buchstabieren übers
> Telefon).

Ja, ich selbst mache das auf meinem Webserver tatsächlich genau so - da 
verwende ich für eine bestimmte Sache 128Bit-UUIDs als ID. Von den 
entsprechenden URLs werden auch QR-Codes erzeugt, und um die möglichst 
klein zu halten, kann die UUID alternativ zur "langen" hexadezimalen 
Schreibweise in der URL auch in kurzer, 22 Zeichen langer, 
base64-codierter Form übergeben werden, und im QR-Code wird diese 
Kodierung verwendet.

Allerdings bringt das (wie ich erst später festgestellt habe) konkret in 
Bezug auf die Grösse des QR-Codes doch nur wenig oder sogar gar nichts. 
Denn bei der Erzeugung eines QR-Codes werden die Roh-Daten erst einmal 
in eine Bitfolge umgewandelt, und da kommt es dann darauf an, welche 
Zeichen in der ursprünglichen Zeichenfolge vorkommen.
Bei hexadezimaler Schreibweise in Grossbuchstaben kann die ID in 
"alphanumerischer Kodierung" kodiert werden (Bei der zwei Zeichen 11 Bit 
benötigen); nimmt man hingegen Base64, dann muss der QR-Encoder "Byte 
Encoding" verwenden, wo jedes Zeichen 8 Bit verwendet:
https://de.wikipedia.org/wiki/QR-Code#Umwandeln_des_Textes_in_eine_Bitfolge

Will sagen: Durch die Base64-Kodierung wird zwar die URL kürzer - der 
zugehörige QR-Code hingegen eher nicht, weil der QR-Code-Encoder 
hexadezimale Zeichenfolgen eh kürzer kodieren kann als 
Base64-Zeichenfolgen. Und: Wenn hexadezimal-Schreibweise in der im 
QR-Code kodierten URL, dann idealerweise durchgängig in Grossbuchstaben.

Und weil sich hexadezimale Zeichenfolgen von Menschen wohl doch 
besser/fehlerfreier kommunizieren lassen als base64-kodierte, macht es 
evtl. halt doch Sinn, hexadezimal-Schreibweise zu verwenden.

: Bearbeitet durch User
Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn zwei getrennte Werte benutzt werden, sollte der eine nicht im Link 
vorkommen. Bspw. ein 4-Stelliger Pin könnte auf dem Schild angebracht 
werden, der dann beim Aufruf der Seite abgefragt wird.

Was bringts?
Eisenbahnfreunde "sammeln" vielleicht die Links in einem Internetforum 
(natürlich mit Passwort), ein Mitarbeiter hat eine Liste mit allen 
Maschinen die ihm mal in die Hände gefallen sind (und wird gehackt).
Ohne PIN-Abfrage kann nun ein Crawler alle Seiten (einfach) abgrasen. 
Mit PIN muss er von selbiger wissen und an richtiger Stelle einfügen. Er 
muss also gezielt auf die Maschinendaten aus sein, es reicht nicht, in 
Crawlermanier alle Links die ihm unterkommen einfach mal abzurufen. 
Deshalb reicht auch ein sehr kurzes Passwort von 3-4 Ziffern. Wenn der 
Crawler in einem von 1000 Versuchen Erfolg hat... seis drum.

Schützt in dem Fall eben nur (zusätzlich) vor den Crawlern, die ihr Ziel 
gar nicht kennen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.