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
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.
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.
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
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.
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 ;)
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> - 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.
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
Frank E. schrieb: > - die Links (Parameter am Ende der URL) sind MD5-Hashes. Der Zugriff mit Ein Hash von was?
die Kosten beim Client einzubauen erscheint mir am sinnigsten. Sie den Beitrag mit bcrypt.
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%
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
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.
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?
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...
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
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.
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.
Frank E. schrieb: > die Hersteller/Besitzer/Betreiber wollen, dass die Maschinendaten online > abrufbar sind Warum fragen die eigentlich niemanden, der vom Fach ist?
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.
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
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.
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.
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.
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.
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.
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
....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.
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
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...
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.
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.
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
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.
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
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.
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.
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.
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.
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
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.
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?
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.
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 ...
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
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
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
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
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.
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
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.
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?
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.
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.
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.
Ah, Joachim S. hat es ja auch vorgerechnet (etwas schneller).
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).
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
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.