Moin,
hat schon wer ein CovPasCheck.PRG für den C64 geschrieben?
Gibts ne Möglichkeit, einen Handscanner zu betreiben?
Es gibt 27 Antworten in diesem Thema, welches 4.386 mal aufgerufen wurde. Der letzte Beitrag (
Moin,
hat schon wer ein CovPasCheck.PRG für den C64 geschrieben?
Gibts ne Möglichkeit, einen Handscanner zu betreiben?
Wäre ja ganz cool. Aber mit den aktuellen Verschlüsselungsverfahren und der Zertifikatsinfrastruktur sind selbst Rechner von Mitte/Ende der 90er Jahre überfordert. Schaut also eher schlecht aus.
Unverschlüsselte QR-Codes scannen sollte aber schon machbar sein. Daten schneller als mit einem 1541er übertragen, wird man damit aber auch nicht. Obwohl deutlich cooler!
ECDSA mit 256 bit, SHA-256 fürs Hashing
RSA-2048 mit SHA-256 fürs Hashing als Fallback (den man sich erstmal sparen könnte, wenn ECDSA während der Pandemie gebrochen wird, haben wir andere Sorgen)
DEFLATE für die Kompression
Base45 kodiert
Daten in JSON verpackt
(Quelle: Bitte melde dich an, um diesen Link zu sehen.)
Also bis auf JSON sieht das alles machbar aus ![]()
Naja, und der QR Code muss noch irgendwie ins System, aber vielleicht hilft da ja der andere Thread mit dem Scanntronik-kompatiblen Video-Digitizer ![]()
Gegen JSON für strukturierte Daten ist deutlich weniger einzuwenden als gegen XML. ![]()
Ist nicht so heillos overengineert.
JSON, das neue XML !
So kann das sagen. JSON hat XML in vielen Bereichen abgelöst.
Sie hätten aber das Datum in JSon richtig festlegen sollen. Man trifft halt doch Leute, die ihren eigenen String zusammensetzen.
Und mit groß/Kleinschreibung von NULL gibt es auch schon mal Stress.
Aber danach geht es gut.
Sie hätten aber das Datum in JSon richtig festlegen sollen. Man trifft halt doch Leute, die ihren eigenen String zusammensetzen.
Und mit groß/Kleinschreibung von NULL gibt es auch schon mal Stress.
Aber danach geht es gut.
Ich nehm an, dass Du von JSON allgemein sprichst. Da ist leider tatsächlich nicht genau festgelegt, wie ein Datum -- bzw. allgemeiner: Zeitstempel -- korrekt aufgebaut werden muss. Ein grober Schnitzer, da geb ich Dir recht.
Im Covid-Zertifikat ist es verhälnismäßig sinnvoll und zum Glück immer gleich aufgebaut.
Momentan bin ich noch auf der Suche danach, wie z.B. das FHIR-Profil dafür funktionieren muss ... aber das ist eine ganz andere Baustelle.
Da ist leider tatsächlich nicht genau festgelegt, wie ein Datum -- bzw. allgemeiner: Zeitstempel -- korrekt aufgebaut werden muss. Ein grober Schnitzer, da geb ich Dir recht.
Sorry für den OT, aber das sehe ich persönlich nicht als Schnitzer.
I.d.R. wird ein Format durch die Software definiert und nicht durch eine Schnittstellendatei. Würde ein festgelegtes Format im JSON abweichend sein, müsste man die Werte ständig hin- und her konvertieren.
So übergebe ich das Format, das auf der Gegenseite benötigt wird und gut.
Also als Schnitzer würde ich das nicht bezeichnen.
Im Covid-Zertifikat ist es verhälnismäßig sinnvoll und zum Glück immer gleich aufgebaut.
Schönes Beispiel. Wenn ich also ein Covid-Zertifikat aus einem JSON erstellen möchte, hat das JSON idealerweise schon das korrekte Format, das für das Zertifikat benötigt wird.
Im Covid-Zertifikat ist es verhälnismäßig sinnvoll und zum Glück immer gleich aufgebaut.
Schönes Beispiel. Wenn ich also ein Covid-Zertifikat aus einem JSON erstellen möchte, hat das JSON idealerweise schon das korrekte Format, das für das Zertifikat benötigt wird.
Würde mich nicht wundern, wenn irgendwann speziell präparierte QR-Codes auftauchen, die den JSON-Parser der CovPassCheck-App exploiten und ohne korrekte Signatur ein "OK!" bewirken. ![]()
Alles anzeigenDa ist leider tatsächlich nicht genau festgelegt, wie ein Datum -- bzw. allgemeiner: Zeitstempel -- korrekt aufgebaut werden muss. Ein grober Schnitzer, da geb ich Dir recht.
Sorry für den OT, aber das sehe ich persönlich nicht als Schnitzer.
I.d.R. wird ein Format durch die Software definiert und nicht durch eine Schnittstellendatei. Würde ein festgelegtes Format im JSON abweichend sein, müsste man die Werte ständig hin- und her konvertieren.
So übergebe ich das Format, das auf der Gegenseite benötigt wird und gut.
Also als Schnitzer würde ich das nicht bezeichnen.
Im Covid-Zertifikat ist es verhälnismäßig sinnvoll und zum Glück immer gleich aufgebaut.
Schönes Beispiel. Wenn ich also ein Covid-Zertifikat aus einem JSON erstellen möchte, hat das JSON idealerweise schon das korrekte Format, das für das Zertifikat benötigt wird.
Naja, entschuldige bitte meine hemdsärmlige Ausdrucksweise. Was willst Du denn jetzt daran ändern, dass JSON so definiert ist? Außerdem, was kann ich dafür?! Dann nenn es halt, wie Du willst. Aber die Bezeichnung ändert nichts am Vorhandensein dieses Fehlers. Ausbügeln lässt sich's eben nicht. Wie immer: Installierte Codebasis verhindert Korrektur.
Es gibt in jeder Programmiersprache und jedem Dokumentenformat solche Schwachsinnigkeiten. Ich weiß auch nicht, was man dagegen tun soll. Ich hab mich damit arrangiert.
Ich denke außerdem nicht, dass es zulässig ist, dass Du (oder einer von uns) ein Covid-Zeritifikat aus einem JSON erstellst. Nichts gegen Deine Person. Sorry. Andersrum funktioniert's.
Die Software, die diese Zertifikate erstellt, macht das immer nach dem selben Schema.
Ich weiß was Du meinst: Das Datumsformat ist nicht festgelegt und kann daher nicht von JSON geprüft werden. Das ist aber in der Natur der Sache. Das ist eben alles nur ein String. Geprüft werden muss in der Software.
Ich weiß jetzt nicht genau, was Du erwartest. Das ist wirklich O/T.
Im Covid-Zertifikat ist es verhälnismäßig sinnvoll und zum Glück immer gleich aufgebaut.
Schönes Beispiel. Wenn ich also ein Covid-Zertifikat aus einem JSON erstellen möchte, hat das JSON idealerweise schon das korrekte Format, das für das Zertifikat benötigt wird.
Würde mich nicht wundern, wenn irgendwann speziell präparierte QR-Codes auftauchen, die den JSON-Parser der CovPassCheck-App exploiten und ohne korrekte Signatur ein "OK!" bewirken.
Das ist vermutlich längst passiert, wenn man sich die Diskussion über gefälschte Zertifikate anschaut. Das liegt aber bestimmt nicht am Datumsformat. Da gehört schon mehr dazu.
Das ist vermutlich längst passiert, wenn man sich die Diskussion über gefälschte Zertifikate anschaut. Das liegt aber bestimmt nicht am Datumsformat. Da gehört schon mehr dazu.
Was Du nicht sagst. (Ich habe mich auch gar nicht aufs Datumsformat bezogen. Und die gefälschten Zertifikate haben womöglich (auch) andere Schwachstellen ausgenutzt. Aber so genau habe ich mir das auch gar nicht angeguckt.)
OT JSon:
Alles anzeigenSorry für den OT, aber das sehe ich persönlich nicht als Schnitzer.
I.d.R. wird ein Format durch die Software definiert und nicht durch eine Schnittstellendatei. Würde ein festgelegtes Format im JSON abweichend sein, müsste man die Werte ständig hin- und her konvertieren.
So übergebe ich das Format, das auf der Gegenseite benötigt wird und gut.
Also als Schnitzer würde ich das nicht bezeichnen.
...
Schönes Beispiel. Wenn ich also ein Covid-Zertifikat aus einem JSON erstellen möchte, hat das JSON idealerweise schon das korrekte Format, das für das Zertifikat benötigt wird.
Ich sehe JSon als Format für Datenaustausch, während ich das Schönmachen für den Anwender als Sache der Anwendung sehe.
Das hin- und herkonvertieren macht mir keinen Kummer, für irgendeinen Kunden muss man das eh machen.
Aber sich "perfekt" auf ein Format mit der Gegenseite zu einigen ist ein Problem. Es sind Programmierer unterwegs, von denen Freddy Krüger träumt...
Nachtlauf: Unix
Tagsüber: Windows-Zeilenumbruch, verschiedene Codepages, je nach Kollege. Außer, das Programm ist ausgefallen, dann wird ein Excel aus SAP gezogen.
CSV "überall ": Trennzeichen Komma, Dezimalpunkt.
CSV Deutschland: Semikolon und Komma.
CSV Excel: Dein Admin muss die Ländereinstellungen Deines Rechners ändern, damit der Kunde Deinen Export verarbeiten kann. Und Tausender-Trennzeichen!!
CSV 1337-h4x0r: In meiner NoSQL-Datenbank ist alles String, da hat man weniger Beschränkungen.
Mein bisheriger Favorit: Ein Kasache aus Schottland mit Russischem(?) Excel erzeugt ein CSV für eine Türkische Anwenderin in Deutschland, die es auf einem Tschechischen Server mit Englischen Spracheinstellungen einspielt. Und am Ende ist dann mein Programm schlecht, weil es Preise von 0,000023 Cent ("...hat er aber so geschickt...") nicht speichern kann.
Das brauch ich irgendwie alles nicht. Im Laufe der jahre und Jahrzehnte hat man sich zwar schon so manches gebaut und die meisten Mätzchen in Text- und CSV-Dateien erledigt, aber ich finde es dennoch schöner, wenn kein Platz für Unklarheiten und unerwartetes Zeug bleibt. WSDL fand ich schön, soweit ich das gesehen habe.
Ich sehe JSon als Format für Datenaustausch, während ich das Schönmachen für den Anwender als Sache der Anwendung sehe.
Da bin ich voll bei Dir. Bezogen auf ein Datum, wird es in der Ziel-Software aber bereits einen Hübsch-Mach-Prozess geben. Maximal kann man da noch an den Einstellungen das Format anpassen.
Aber unabhängig erwartet die Software in den meisten Fällen ein grundlegendes Format, mit dem es arbeiten kann. Dann lobe ich mir doch, dass ich ein Dateiformat für den Austausch nutzen kann, in dem ich dieses Datumsformat schon wie erwartet übergeben kann, anstatt das vor dem Import in die Zielsoftware erst noch darauf anzupassen.
![]()
Da bin ich voll bei Dir. Bezogen auf ein Datum, wird es in der Ziel-Software aber bereits einen Hübsch-Mach-Prozess geben....
...erwartet die Software ... ein grundlegendes Format, mit dem es arbeiten kann.
...anstatt das vor dem Import in die Zielsoftware erst noch darauf anzupassen.
Das hab ich jetzt nicht verstanden...
Wäre das Datumsformat definiert, würde die Zielsoftware es auch so erwarten, und es müsste dann doch nichts angepasst werden?
In meinem JSon-Fall gab es nach ein paar Wochen doch noch ein Datumsproblem, weil meine Seite einstellige Tagesdatumsens zweistellig erwartet hat. Datum war bisher immer eine Sonderlocke, die jedesmal wieder neu angepasst werden muss.
...............
Etwas mehr OnTopic:
Die Covid-App zeigt ja zum Zertifikat einen QR.
Mit anderer Covid-App gescannt: Das Zertifikat wird importiert.
Bisher hab ich nur reine Sichtprüfungen ohne Passkontrolle erlebt.
Warum also ein Zertifikat fälschen? Nimm doch einfach irgendeines von irgendeinem Handy!
Ich hätte nicht erwartet, dass sich das dermaßen Plump verhält. Mindestens hätte sich der QR aus der APP vom Original unterscheiden sollen, noch besser mit Datum oder gar Schlüsseltausch frisch generiert werden sollen.
Das hab ich jetzt nicht verstanden...
Wäre das Datumsformat definiert, würde die Zielsoftware es auch so erwarten, und es müsste dann doch nichts angepasst werden?
In meinem JSon-Fall gab es nach ein paar Wochen doch noch ein Datumsproblem, weil meine Seite einstellige Tagesdatumsens zweistellig erwartet hat. Datum war bisher immer eine Sonderlocke, die jedesmal wieder neu angepasst werden muss.
Genau das meine ich ja, sofern ich Dich richtig verstanden habe ![]()
Nur kurz, um dann den OT wieder zu verlassen:
Du hast zwei Systeme, A und B. Die Daten sollen von A auf B übertragen werden. Als Datencontainer wird JSON verwendet. B setzt aber bei einem Datumsfeld ein bestimmtes Format voraus.
Die Methode mir dem wenigsten Aufwand wäre also ein Middleware, die ein JSON erstellt, das die Daten bereits in den von B angeforderten Formaten enthält.
Jetzt gehen wir aber mal davon aus, dass wir ein Zielsystem C haben, das ganz andere Anforderungen an das Datumsformat hat, wie System B.
Aber wir haben ja Glück, denn ich kann mein JSON je genau so erstellen, wie C es haben möchte.
Das meinte ich eigentlich nur und bezog sich ausschließlich hierauf:
Da ist leider tatsächlich nicht genau festgelegt, wie ein Datum -- bzw. allgemeiner: Zeitstempel -- korrekt aufgebaut werden muss. Ein grober Schnitzer, da geb ich Dir recht.
Hier wird ausgesagt, dass es ein grober Schnitzer in der JSON Schnittstelle sei, dass es kein festgelegtes Datum gibt.
Das sehe ich halt anders, wie oben erklärt.
![]()
64k_or_64bit Die Ruhe bleibt... Ich habe doch gar nicht gesagt, dass Du für irgendwas etwas kannst.
Ich darf aber eine andere Meinung haben und die auch äußern, wenn ich die sogar noch begründen kann. ![]()
Alles anzeigenDa bin ich voll bei Dir. Bezogen auf ein Datum, wird es in der Ziel-Software aber bereits einen Hübsch-Mach-Prozess geben....
...erwartet die Software ... ein grundlegendes Format, mit dem es arbeiten kann.
...anstatt das vor dem Import in die Zielsoftware erst noch darauf anzupassen.Das hab ich jetzt nicht verstanden...
Wäre das Datumsformat definiert, würde die Zielsoftware es auch so erwarten, und es müsste dann doch nichts angepasst werden?
In meinem JSon-Fall gab es nach ein paar Wochen doch noch ein Datumsproblem, weil meine Seite einstellige Tagesdatumsens zweistellig erwartet hat. Datum war bisher immer eine Sonderlocke, die jedesmal wieder neu angepasst werden muss................
Etwas mehr OnTopic:
Die Covid-App zeigt ja zum Zertifikat einen QR.
Mit anderer Covid-App gescannt: Das Zertifikat wird importiert.
Bisher hab ich nur reine Sichtprüfungen ohne Passkontrolle erlebt.
Warum also ein Zertifikat fälschen? Nimm doch einfach irgendeines von irgendeinem Handy!Ich hätte nicht erwartet, dass sich das dermaßen Plump verhält. Mindestens hätte sich der QR aus der APP vom Original unterscheiden sollen, noch besser mit Datum oder gar Schlüsseltausch frisch generiert werden sollen.
Das ist eine der wirklichen Schwachstellen an dem ganzen Thema. Aber ich sag in jedem IT-Projekt: Organisatorische Probleme lassen sich nicht durch Technik lösen.
Bei mir wurde bisher immer der Personalausweis verlangt. Das wird ja auch von der Cov Pass Check App so angezeigt. Der Hinweis ist ja da, nur interessiert es eben in vielen Fällen nicht. Das ist in der Tat ein eklatanter Schwachpunkt, der sich aber so nicht lösen lässt.
Das Ding ist halt: Der Kram soll ja auch offline funktionieren, also z.B. im Funkloch oder vom Papier. Für das Verfahren "Einlasskontrolle" braucht keiner von uns die App. Nur das Papier mit dem QR-Code reicht schon aus und das könnte man auch x-mal durch den Kopierer gejagt haben, es bleibt gültig, solange der Personalausweis dazu vorgelegt wird.
Daher kann das ganze gar nicht jedes mal neu generiert werden. Selbst wenn die App einen anderen QR-Code des selben Inhalts anzeigen würde, müsste dieser mit dem selben Verfahren decodierbar sein. Daher kann man auf diese Weise gar nicht verhindern, dass der QR-Code von einer App durch eine andere App in deren Wallet gescannt wird und als valide anerkannt wird. Außerdem wird dieses Vorgehen sogar noch ausdrücklich erlaubt und dazu ermutigt. Die CWA (Corona Warn App) ermöglicht es ja explizit, Zertifikate unterschiedlicher Personen auf dem selben Gerät zu verwalten. Gedacht ist das für ganze Familien.
Natürlich könnte man sich ein anderes Verfahren ausdenken ... aber wir waren ja nicht gefragt ...
Immerhin ist der Kram besser als das "Besondere Elektronische Anwaltspostfach". Das soll es aber nicht schönreden.
Bisher hab ich nur reine Sichtprüfungen ohne Passkontrolle erlebt.
Warum also ein Zertifikat fälschen? Nimm doch einfach irgendeines von irgendeinem Handy!
Es gibt da in der Praxis ein breites Spektrum von "ja, sieht wie ein QR-Code aus" bis vollständigem Abgleichen von gültigem Zertifikat und Personalausweis. Natürlich ist eigentlich nur letzteres zulässig. ![]()
Ich hätte nicht erwartet, dass sich das dermaßen Plump verhält. Mindestens hätte sich der QR aus der APP vom Original unterscheiden sollen, noch besser mit Datum oder gar Schlüsseltausch frisch generiert werden sollen.
Also der QR-Code des ausgestellten gedruckten Zertifikats ist ein anderer als das, was die App dann draus macht und zum Scannen anzeigt.
Ich hätte nicht erwartet, dass sich das dermaßen Plump verhält. Mindestens hätte sich der QR aus der APP vom Original unterscheiden sollen, noch besser mit Datum oder gar Schlüsseltausch frisch generiert werden sollen.
Also der QR-Code des ausgestellten gedruckten Zertifikats ist ein anderer als das, was die App dann draus macht und zum Scannen anzeigt.
Bei dem Verfahren ist es egal, ob der QR-Code identisch ist oder nicht. Der Inhalt ist identisch. Darauf kommt's an. Den Inhalt zu decodieren ist ja auch kein Hexenwerk. Dann kann man den durch einem QR-Code-Generator schicken und das Ergebnis sollte weiterhin akzeptiert werden. Das hab ich aber nicht ausprobiert. Ich seh aber keinen Grund, warum es nicht funktionieren sollte.
Edit: Nein, es funktioniert tatsächlich nicht. Sprich: Man kann nicht einfach die Inhalte durch einen beliebigen QR-Code Generator jagen. Aber warum erschließt sich mir noch nicht. Ich nehme an, es muss irgendwie mit der Fehlertoleranz des QR-Codes zu tun haben, aber eigentlich ist das ja ... Unsinn, oder?
Auf jeden Fall sind die Inhalte relevant, weil diese ja signiert und "verschlüsselt" werden. Decodierung ist dennoch ein Klacks. Andersrum ist es aber schon schwieriger.