social.stefan-muenz.de

Search

Items tagged with: luca

#bawü #luca Land Teil 3: Wir sind hier derzeit in der #Bodensee Region. Übergang von Haupt- zu Nebensaison. Letzte Woche war das Wetter super und alles war total voll, diese Woche ist das Wetter durchwachsener und nicht mehr ganz so voll. Jedenfalls eine Gegend, die zum beträchtlichen Teil vom Tourismus lebt.

Typischer Umgang im Restaurant/Museum: "Habt's ihr die Luca App?"

Bei "Ja" wird man auf den QR-Code an Tischen oder Eingang verwiesen. Ob man dann auch eincheckt prüft keiner.

Bei "nein" bekommt man - teils nach längerem Warten - einen Zettel für die Adresse zur Kontaktverfolgung. Mehrfach schon passiert dass der erst auf Nachfrage eingesammelt wurde.

Auch das Prüfen von 3G passiert nur oberflächlich. Ich habe in der #cwa den Impfstatus von - in dieser Reihenfolge - mir, Sohn 2 (der nicht mit ist) und Frau. Kein einziges(!) Mal wurde der Code bisher gescannt. Meist wird nur flüchtig draufgeguckt - wenn man 2 Codes sieht reicht das eigentlich schon, ich hab mir nach dem 3. mal abgewöhnt, noch über den Code des Sohnes hinaus zu dem meiner Frau zu scrollen.

Löbliche Ausnahme; Das Freilichtmuseum in Neuhausen ob Eck: Hier wurde der QR-Code zwar auch nicht gescannt und auch nicht mit dem Ausweis abgeglichen, aber die Dame am Einlass hat sich auch den Impftermin(!) zeigen lassen (und so nebenher geprüft dass man ihr keinen Screenshot zeigt) um festzustellen, ob die 2. Impfung auch schon 2 Wochen her ist. Das Freilichtmuseum kann ich übrigens empfehlen.
 
#bawü #luca Land Teil 2: Gestern endlich jemanden einchecken sehen. Älteres Pärchen, 60+. Ich frage, ob sie denn auch die #cwa haben? Antwort - sinngemäß und nach Erklären, was denn die CWA sei: Nein, wir haben doch die Luca App.

Wenn ich von da aus extrapoliere, dann dürfte der Großteil der Leute hier lediglich Luca haben und somit die Kontaktverfolgung per CWA ad absurdum führen.

Gut gemacht, Luca. Ein ganzes Bundesland ohne CWA.
 
Wo ich hier in #bawü überall die ganzen #luca Aufkleber sehe... Das, was man Luca - neben der völlig unnötig zum Fenster rausgeworfenen Steuerkohle - wirklich vorwerfen muss ist, dass dadurch die Adaption der Corona Warn App #cwa vermutlich abgebremst wurde und es deutlich mehr/bessere Warnungen hätte geben können, wenn Luca nicht dazwischengefunkt hätte.

Oh, und obwohl hier überall Luca QR Codes auf Tischen etch kleben, sehe ich niemanden, der den scannt.
 
Das @BMI_Bund verbietet dem @BSI_Bund die @_lucaApp und das dahinter liegende Gesamtsystem zu prüfen.
Ein Schelm, wer böses dabei denkt und überlegt, wessen wirtschaftliche Interessen da wohl geschützt werden...
#lucafail #Luca #Lucaapp @derspiegel
https://www.spiegel.de/netzwelt/netzpolitik/luca-app-innenministerium-lehnt-sicherheitspruefung-ab-a-a6dba9ed-6d12-4ead-945a-bf06d6fc0795
 
Das allererste mal, dass ein Laden die echte #CWA anbietet und nicht diesen #Luca Dreck.

Mach ich dann doch gerne ☺️
Bild/Foto
#CWA #Luca
 
Tja, all das hätte mit der Corona Warnapp nicht passieren können. Aber bei der Sache in Bad Doberan sieht man echt alle Schwachpunkte von Luca und generell Kontaktverfolgung:
  • Leute wollen 'Datenschutz' und geben daher falsche Daten an.
  • Luca ist zentral. -> Single Point of Failure
  • Die Firma muss kooperativ sein. -> Single Point of Failure
  • 'Die Verschlüsselung' -> Single Point of Failure.
  • Es gibt wohl nur einen Key für Veranstalter und der kann schnell verloren gehen. -> Single Point of Failure.
  • Gesundheitsämter werden mit der Arbeit überlastet.
Dagegen die CWA:
  • Es müssen überhaupt keine Daten angegeben werden.
  • Dezentral.
  • Man ist nicht auf eine Firma angewiesen.
  • Verschlüsselung ist kein Problem, da ja keine persönliche Daten außer Hashes anfallen.
  • Es braucht daher auch keinen Key, den man verlieren kann.
  • Die Kontaktverfolgung und Benachrichtigung erfolgt ohne die Gesundheitsämter. Diese werden also nicht überlastet.
Es ist eigentlich ein No-Brainer. Doof nur, dass offensichtlich auch No-Brainer dafür zuständig sind, Entscheidungen zu treffen. :/

#luca #cwa #coronawarnapp #nobrainer #covid #baddoberan #mv #corona
 
Tja, all das hätte mit der Corona Warnapp nicht passieren können. Aber bei der Sache in Bad Doberan sieht man echt alle Schwachpunkte von Luca und generell Kontaktverfolgung:
  • Leute wollen 'Datenschutz' und geben daher falsche Daten an.
  • Luca ist zentral. -> Single Point of Failure
  • Die Firma muss kooperativ sein. -> Single Point of Failure
  • 'Die Verschlüsselung' -> Single Point of Failure.
  • Es gibt wohl nur einen Key für Veranstalter und der kann schnell verloren gehen. -> Single Point of Failure.
  • Gesundheitsämter werden mit der Arbeit überlastet.
Dagegen die CWA:
  • Es müssen überhaupt keine Daten angegeben werden.
  • Dezentral.
  • Man ist nicht auf eine Firma angewiesen.
  • Verschlüsselung ist kein Problem, da ja keine persönliche Daten außer Hashes anfallen.
  • Es braucht daher auch keinen Key, den man verlieren kann.
  • Die Kontaktverfolgung und Benachrichtigung erfolgt ohne die Gesundheitsämter. Diese werden also nicht überlastet.
Es ist eigentlich ein No-Brainer. Doof nur, dass offensichtlich auch No-Brainer dafür zuständig sind, Entscheidungen zu treffen. :/

#luca #cwa #coronawarnapp #nobrainer #covid #baddoberan #mv #corona
 
Drei Stunden in München und schon braucht man #Luca. So ein Quatsch. Ich dachte #Luca ist passé. Zum Glück gab es auch eine Papiervariante. Warum nicht @coronawarnapp oder #cctg ?
 
@vilbi @nuron @malteengeler
😅 Ich hoffe nicht.
Natürlich dürfen öffentlich-rechtliche Institutionen keine Werbung für einzelne Marktteilnehmer machen.
Wir haben unsere Empfehlung an die #Landesregierung zu #Luca öffentlich gemacht

https://www.baden-wuerttemberg.datenschutz.de/wp-content/uploads/2021/04/20210331_PM_Stellungnahme-Luca-App.pdf

Und wir haben allen Anbietern dieselbe Prüfung angeboten, bislang hat davon aber keiner (!) Gebrauch gemacht.
 
@ThL @nuron @malteengeler
Danke 🙏

Damit kann man mal anfangen, ein Podcast nur zu #Luca und der Kritik

https://www.baden-wuerttemberg.datenschutz.de/podcast-datenfreiheit-folge-11-luca-app-in-der-kritik/

Wir freuen uns über Feedback 😉
 
Alle Gäste einer Bar in #westerland auf #sylt müssen in Quarantäne, die #luca #app hat "nicht funktioniert", daher weiß man nicht wer da war.

Es bleibt nur der Behördenaufruf und freiwillige Meldung...

Aus dem Artikel geht leider nicht hervor, was der technische Fehler gewesen sein soll.

Artikel ist hinter Cookie-Wall:
https://www.shz.de/lokales/sylter-rundschau/Infizierter-Gast-in-der-Wunderbar-Gaeste-muessen-in-Quarantaene-id33032257.html
 
Würde mich auch interessieren.

RT @xl_ent@twitter.com

Gibt‘s eigentlich schon einen Fall, wo #Luca-App sinnvoll bei der Pandemiebewältigung geholfen hat?

🐦🔗: https://twitter.com/xl_ent/status/1418154838576222211
 
Bild/Foto

09.07.2021 Trotz Kritik mehr Luca-App Nutzer


Dummheit erscheint steigerungsfähig

... denn wie Heise schreibt, wächst trotz der teilweise heftigen Kritik gegenüber der Luca-App, die Zahl der Nutzer täglich und stetig. Pro Woche kommen 1,5 Millionen neue Nutzer und 10.000 neue Veranstaltungen und Check-In-Standorte hinzu.
Ist das noch normal?

Schon 3-mal haben auch wir auf die Kritik an der Luca App hingewiesen.Unzulässiger Umgang mit unseren Daten, (teilweise inzwischen geschlossene) Löcher und Lücken - und trotzdem installieren sich die Menschen diese App. Noch unverständlicher ist das Handeln von Behörden, denn, wie Heise berichtet, haben 13 Bundesländer sich mittlerweile Lizenzen der App gesichert und 318 deutsche Gesundheitsämter sind mit den Luca-Servern verbunden.

Wie können staatliche Stellen die Verbreitung dieser App unterstützen, die in direkter Konkurrenz zu eigenen Corona- Warn App steht?

So geschieht es, dass Menschen bei ihrem Restaurantbesuch faktisch gezwungen sind, sich die App zu installieren, um die Räume betreten zu können. Digitalcourage hatte bei der Verleihung der Big Brother Awards sogar von einer Behörde berichtet, die die Luca App von ihren Besuchern verlangt. Dabei bietet seit April auch die Corona-Warn App eine Check-In-Funktion zur Eventregistrierung an, ähnlich der Luca App.

Das Fazit zur Luca App beschreibt Heise so: Viel Geld für wenig Nutzen und große Risiken – so lässt sich die Stellungnahme zur Luca-App von 70 Sicherheitsforschenden zusammenfassen. Sie fordern eine Rückbesinnung auf die bestehenden, dezentralen Lösungen der Corona-Warn-App.

Wir können darin jedenfalls nur eine weitere Datenkrake sehen, haben aber generell Bedenken gegen jede Form von Zwangsdigitalisierung, also alle Verfahren, die die Menschen zwingen digitale Geräte zu nutzen, um ihren Alltag bestreiten zu können.

Mehr dazu bei https://www.heise.de/news/Luca-App-Die-Nutzerzahlen-steigen-die-Kritik-ebenfalls-6128148.html
Link zu dieser Seite: https://www.aktion-freiheitstattangst.org/de/articles/7699-20210709-trotz-kritik-mehr-luca-app-nutzer.htm
Link im Tor-Netzwerk: nnksciarbrfsg3ud.onion/de/articles/7699-20210709-trotz-kritik-mehr-luca-app-nutzer.htm
Tags: #Corona #Luca #App #DSGVO #Freiwilligkeit #Zwangsdigitalisierung #Lauschangriff #Überwachung #Vorratsdatenspeicherung #Verbraucherdatenschutz #Datenschutz #Datensicherheit #Transparenz #Informationsfreiheit #OpenSource #Verhaltensänderung #eHealth #Hacking
 
Bild/Foto

09.07.2021 Trotz Kritik mehr Luca-App Nutzer


Dummheit erscheint steigerungsfähig

... denn wie Heise schreibt, wächst trotz der teilweise heftigen Kritik gegenüber der Luca-App, die Zahl der Nutzer täglich und stetig. Pro Woche kommen 1,5 Millionen neue Nutzer und 10.000 neue Veranstaltungen und Check-In-Standorte hinzu.
Ist das noch normal?

Schon 3-mal haben auch wir auf die Kritik an der Luca App hingewiesen.Unzulässiger Umgang mit unseren Daten, (teilweise inzwischen geschlossene) Löcher und Lücken - und trotzdem installieren sich die Menschen diese App. Noch unverständlicher ist das Handeln von Behörden, denn, wie Heise berichtet, haben 13 Bundesländer sich mittlerweile Lizenzen der App gesichert und 318 deutsche Gesundheitsämter sind mit den Luca-Servern verbunden.

Wie können staatliche Stellen die Verbreitung dieser App unterstützen, die in direkter Konkurrenz zu eigenen Corona- Warn App steht?

So geschieht es, dass Menschen bei ihrem Restaurantbesuch faktisch gezwungen sind, sich die App zu installieren, um die Räume betreten zu können. Digitalcourage hatte bei der Verleihung der Big Brother Awards sogar von einer Behörde berichtet, die die Luca App von ihren Besuchern verlangt. Dabei bietet seit April auch die Corona-Warn App eine Check-In-Funktion zur Eventregistrierung an, ähnlich der Luca App.

Das Fazit zur Luca App beschreibt Heise so: Viel Geld für wenig Nutzen und große Risiken – so lässt sich die Stellungnahme zur Luca-App von 70 Sicherheitsforschenden zusammenfassen. Sie fordern eine Rückbesinnung auf die bestehenden, dezentralen Lösungen der Corona-Warn-App.

Wir können darin jedenfalls nur eine weitere Datenkrake sehen, haben aber generell Bedenken gegen jede Form von Zwangsdigitalisierung, also alle Verfahren, die die Menschen zwingen digitale Geräte zu nutzen, um ihren Alltag bestreiten zu können.

Mehr dazu bei https://www.heise.de/news/Luca-App-Die-Nutzerzahlen-steigen-die-Kritik-ebenfalls-6128148.html
Link zu dieser Seite: https://www.aktion-freiheitstattangst.org/de/articles/7699-20210709-trotz-kritik-mehr-luca-app-nutzer.htm
Link im Tor-Netzwerk: nnksciarbrfsg3ud.onion/de/articles/7699-20210709-trotz-kritik-mehr-luca-app-nutzer.htm
Tags: #Corona #Luca #App #DSGVO #Freiwilligkeit #Zwangsdigitalisierung #Lauschangriff #Überwachung #Vorratsdatenspeicherung #Verbraucherdatenschutz #Datenschutz #Datensicherheit #Transparenz #Informationsfreiheit #OpenSource #Verhaltensänderung #eHealth #Hacking
 
Ich habe heute übrigens still(!) gegen die #Luca-App protestiert.

Den #QR-Code mit der #CWA gescannt (hätte ja funktionieren können - theoretisch, vielleicht; ok, eher unwahrscheinlich): kam natürlich(?) „mööhp“. Hab ich so getan, als wäre alles ok und bin rein in‘s Geschäft.

Ich glaube, ich habe dem rostocker Gesundheitsamt damit Arbeit gespart und somit geholfen.

Warum es die örtliche Wirtschaft nicht hin bekommt, zusätzlich CWA-kompatible QR-Codes auszuhängen … 🤷
 
Einen Zwang zur Nutzung von #Apps zur #Corona #Kontaktnachverfolgung darf es nicht geben
#Luca #CWA

Solange #Regierungen in den #CoronaVO auf nicht-anonyme Kontaktverfolgung setzen, hat es die Corona #WarnApp schwer und #Luca hat die Nase vorn

In jedem Fall muss immer eine händische Kontaktangabe möglich sein - sonst Beschwerde an @lfdi
https://www.spiegel.de/netzwelt/apps/corona-kontaktverfolgung-chaos-computer-club-kritisiert-quasi-zwang-zur-luca-app-a-a90dee1b-dc58-449d-919a-0f3515ac0808?
 
Distanz Tracker für Innenräume. Jetzt echt @lehr_thorsten@twitter.com ? Nichts gelernt aus dem #Luca Debakel?
Öffnungen innovativ absichern – Distanztracker soll Hygienekonzepte verbessern und Nachverfolgung erleichtern
https://www.stuttgart.de/pressemitteilungen/2021/juni/corona-oeffnungen-innovativ-absichern-distanztracker-soll-hygienekonzepte-bei-verbessern-und-nachverfolgung-erleichtern.php
#Luca
 
Die #CoronaWarnApp wird für mich immer nutzloser. Obwohl schon lange angekündigt ist immer noch kein CheckIn mit #Luca QR-Code möglich. Heute in #MeckPom war also nirgends CheckIn möglich weil kein Schwein ein #cwa qr-code zur Verfügung stellt. Wann soll diese Funktion eigentlich nun wirklich kommen, in der achten Welle der #Corona #Pandemie?

(Nein ich werde das Vorort nicht mit den Angestellten diskutieren!)
 

#Luca QR-Code generieren


https://f-droid.org/packages/digital.selfdefense.lucia

#Lucia lässt einen Check-In Codes erzeugen, die angeblich valide sind. Falls jemand kein Bedürfnis verspürt, seine personenbezogenen #Daten einer shady Werbeklitsche mit kreativem Verhältnis zur Wahrheit und überraschendem Verständnis von #IT-Security zu senden …
 
#luca Verträge rück-abwickeln. Jetzt.
#luca
 
Du benutzt die #LucaApp, dein Name ist Frommer und wohnst in Fromhausen? Du wirst jetzt im CSV-Export fürs Gesundheitsamt "mer" heissen und in "hausen" wohnen. Und Name in nicht-Latin script geht gar nicht.
https://gitlab.com/lucaapp/web/-/blob/d671d978/services/health-department/src/utils/sanitizer.js

#bad #code #luca
 
Code injection - man sollte nicht glauben, dass das heute noch möglich ist.

#luca
#luca
 
@vilbi @sven @kuketzblog @digitalcourage
Der #Datenschutz hindert niemanden daran, Flottenverbräuche etc. zu erfassen. Es ist das Konzept, das immer die Gier nach persönlichen Daten beinhaltet, welches nicht passt.
Bestes Beispiel:
#Luca vs. Covid Warnapp
=
Desaster vs. smarte Intelligenz
 
Letztes Jahr hieß es noch, ein Zwang zur Benutzung der Corona Warn App ginge gar nicht. Nun regt es niemanden auf, dass Ladenketten Eintritt nur mit der Luca-App gewähren und Bundesländer die Benutzung dieser App per Verordnung zur Pflicht machen.

Unstete Zeiten, das …

#CWA #Luca
#CWA #Luca
 
#Luca #app #Datenschutz #Nordfriesland #Restaurant

Ja SCHEISSE! Jetzt hat man die Möglichkeit in Nordfriesland Essen oder Trinken zu gehen - aber NUR mit der verfickten Luca-App.
Daß die CoronaApp das auch kann ist irrelevant. Und Zettel und Stift machen die auch nicht. Tolle Wurst.
 
#Luca #app #Datenschutz #Nordfriesland #Restaurant

Ja SCHEISSE! Jetzt hat man die Möglichkeit in Nordfriesland Essen oder Trinken zu gehen - aber NUR mit der verfickten Luca-App.
Daß die CoronaApp das auch kann ist irrelevant. Und Zettel und Stift machen die auch nicht. Tolle Wurst.
 
Merkwürdig. Ich kenne Golem eigentlich als kritisch berichtend, aber hier wird beachtlich viel offensichtliche PR wiedergegeben. "Keine Sicherheitslücke gefunden". Well.

RT @golem@twitter.com

Digitale Gästelisten: Woher kommt der Hass auf die Luca-App? #Luca-App https://glm.io/156425?s

🐦🔗: https://twitter.com/golem/status/1392376109170372612
 
@sl007 funktioniert das bei jemandem? In meinem fiktiven #Luca Location-Account werden keine Check-ins angezeigt. #Luci zeigt den Namen der Location aber korrekt an. #LucaApp
 
#AnkeDomscheit-Berg sammelt seit Anfang April die Fails der #Luca App. Lesenwerter Thread.
https://nitter.eu/anked/status/1379665492739231744
 
Du wolltest schon immer alle Ministerpräsidenten auf einmal in Deinem bevorzugten Scherzartikel-Laden einchecken?

https://luci-app.de

#luca #luci #lucaApp
 
Die QR-Codes der #CoronaWarnApp und der #luca-App sind nun doch nicht kompatibel. Bedeutet nochmal 2 - 3 Wochen Wartezeit auf das entsprechende Update - und neue QR-Codes für 114.000 teilnehmende Geschäfte. 🙊https://www.golem.de/news/kontaktnachverfolgung-corona-warn-app-laesst-sich-leichter-trollen-als-die-luca-app-2105-156186.html
 
Ich freue mich sehr in einer #Modellregion zu leben! 🤦‍♂️

#luca #coesfeld #corona
Bild/Foto
 
#luca #lucaApp
Gemeinsame Stellungnahme zur digitalen Kontaktnachverfolgung

https://digikoletter.github.io
 
Weiß wer, ob es laufende Prozesse zur #Luca App gibt? Also Personen oder Vereine, die gegen den Einsatz klagen?
#Luca
 
Viele Menschen sorgen sich um ihre Daten – erstaunlicherweise mehr bei der Corona-Warn-App als bei der umstrittenen #Luca-App https://www.zeit.de/digital/datenschutz/2021-04/corona-warn-app-luca-app-datenschutz-sicherheit-smartphone/komplettansicht
 
RT @derfreitag
#Luca: Die Länder geben 20 Millionen Euro für eine überflüssige App aus https://www.freitag.de/autoren/der-freitag/luca-kam-sah-und-spionierte

Von Anne Roth @annalist
#Luca
 
#Luca-App:

Warum im Voraus bezahlte Lizenzen eine schlechte Idee sind.

Die meisten Bundesländer haben bereits Verträge mit Luca unterschrieben. Der IT-Unternehmer Ralf Rottmann fragt sich, warum sie für eine Jahreslizenz der App bereits vorab und pauschal Millionen von Euro an das junge Unternehmen zahlen – statt auf nutzungsabhängige Preismodelle zu bestehen, wie sie in der Branche üblich sind. ...

https://netzpolitik.org/2021/luca-app-warum-im-voraus-bezahlte-lizenzen-eine-schlechte-idee-sind/
 
Was ich noch zu sagen hatte..
#LucaApp

RT @derfreitag@twitter.com

#Luca: Die Länder geben 20 Millionen Euro für eine überflüssige App aus https://www.freitag.de/autoren/der-freitag/luca-kam-sah-und-spionierte

Von Anne Roth @annalist@twitter.com

🐦🔗: https://twitter.com/derfreitag/status/1385560346136616962
 
Heute habe ich #Datenschutzbeschwerde bei den Landesdatenschutzbeauftragten von Berlin und Baden-Württemberg gegen culture4life GmbH, den Machern der #Luca-App eingereicht.
https://www.fam-heidrich.net/datenschutzbeschwerde/
 
Habe ich damit zu #BoykottLuca aufgerufen?

#luca
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

Brahahawaaaaaahhhhhh …!


https://www.reddit.com/r/de/comments/mt73uw/ein_tipp_f%C3%BCr_diejenigen_die_in_der_luca_app_nicht/

Ob diese #Luca App gegen irgendwas nützlich ist, keine Ahnung. Aber ziemlich sicher ist sie gut, um Schreikrämpfe zu produzieren. Was für eine dilettantische Deppensoftware.
#Luca
 
#Luca ist so ein Beispiel von "Wir haben ein Problem, lasst uns ein kompliziertes Tool nehmen um es zu lösen, Stift und Papier ist zu einfach".
#Luca
 
Later posts Earlier posts