ZFX + Developia

Klingt als würde ich dann Geld für einen Server irgendwo mit einem anderen Produkt ausgeben. Hatten in der Uni mal gitlab. War vollkommen ok.

Es ist halt eben einfach unglaublich wichtig, dass es einen Single-Point-of-Failure gibt!!!

Hab vor zwei Jahren mal mein Handy verloren. Das war halbwegs neu und ein paar hundert € wert, aber das war echt das kleinste Problem. Zuhause kein Festnetz, also musste ich dem Fundbüro ne Mail schreiben statt anrufen zu können. WhatsApp und Signal gingen noch 2 Tage lang über meinen Laptop, aber weil die keine First-Class Desktop Clienten haben hatten die dann irgendwann keine Lust mehr. Bahnticket konnte ich mir ohne BahnApp nicht kaufen, ich weiß gar nicht mehr ob ich mich bei meiner Bank noch ohne 2FA anmelden konnte, und diverse andere Dinge gingen halt auch nicht.

Hat knapp 2 Wochen gedauert bis ich die Ersatz-Sim-Karte hatte und dann wieder anfangen konnte Dinge neu einzurichten. In der Zeit kannste dich echt unter einen Stein legen und tot spielen, ich konnte nicht mehr mit Leuten reden, nicht mehr verreisen, keine Geschäfte mehr machen, etc.

Ich hatte mich damals mal nach Zweit-SIM-Karten erkundigt. Bei ALDI-Talk kann man scheinbar eine neue Karte beantragen, die alte funktioniert noch so lange bis man die neue aktiviert, aber dafür hat man wohl ziemlich lange Zeit. Also am besten schonmal neue Karte bestellen, zuhause irgendwo in den Tresor legen und bei Bedarf schnell ein altes Handy damit reaktivieren, damit man nicht 2 Wochen lang aufhört zu existieren.


(Nur Telegram funktionierte noch, weil die Daten unverschlüsselt auf Servern in sehr fragwürdigen Ländern (erst Russland, dann VAE meine ich) liegen und man sein Handy nicht braucht. Ich will nicht sagen dass Telegram sehr zuverlässig funktioniert weil denen Sicherheit egal ist, aber unwahr ist es auch nicht. Kann man mal drüber nachdenken, wenn man gerade am Desktop versucht Signal zu benutzen aber es unmöglich ist dort seine alten Nachrichten zu sehen weil man die wegen sIcHeRhEiT nicht synchronisieren kann...)

Ich hab schon letztes Jahr oder so zu pushen aufgehört, seit dafür ein Zertifikat nötig war. Security hin oder her - meine Credentials hab ich immer dabei im Kopf. Irgendein Certificate rumzuschicken ist ein Schmerz-Im-Arsch, und ich sehe immer noch nicht ein, warum ich dabei keine Wahl habe. Ist doch *mein* Problem, wenn jemand meinen Account missbraucht.

Aber Microsoft ist schon ne Weile auf diesem Pfad. Ich hab, um so ein Steam-Multiplayer-Survival spielen zu können, einen XBox-Irgendwas-Account anlegen müssen, was halt ein MS-Account ist, und die haben mit ausnehmend dummen Ausreden dann die Telefonnummer erzwungen. Zum Glück gibt's dafür dann Temp-SMS-Numbers, die man sich ergoogeln kann. Und im Gegensatz zu ChatGPT funktionieren sie bei MS noch.

Firefoxupdate installiert jetzt wird auf der Startseite Werbung angezeigt ("empfohlene Inhalte", haha). Hat der Browser wenigstens irgendeine neue Funktion auf die ich gewartet hab? Nö. Wieder ein Update, dass in der User-Experience strikt negativ ist. Wieder ein emotionales Argument mehr, so selten wir irgend möglich Updates zu installieren. Danke Welt.

@Krishty: Du brauchst keine Telefonnummer für GitHub.

tldr; keine Telefonnumer notwendig - User sind dumm - alles ist gut wie sie es machen

Hier die lange Version:

Sie geben dir einen Key, und damit kannst du (z.B.) unter https://totp.danhersam.com?key=<MEINKEY> den zeitabhängigen Code generieren.
Der Key steht in der URL die beim Scan des QR Codes kommt, wenn du 2FA aktivierst.
(Der Link sieht dann so etwa aus: otpauth://totp/GitHub:<MEINUSER>?secret=<MEINKEY>&issuer=GitHub)

Also so wie ein RSA Token früher, das wurde einmal per Key/Secret konfiguriert und generiert dann zeitabhängige Tokens.
Mit einem offenen Algorithmus, also auch die ganzen "Authenticator-Apps" brauchen keinen Internet-Zugang (wenn man auf Apps steht, ich mags nicht)

Es ist nur sicherer beim Login, weil der generierte Key nicht "passwort123" ist.
Aber anscheinend machen das viele User, daher ist das wieder ein Fall von "wir erzwingen es, weil die User zu dumm sind, das ordentlich zu machen".
So wie Windows-Updates, siehe hier:

=> über JAHRE(!) nicht aktualisierte Betriebssysteme waren da verantwortlich, nur mal so nebenbei. Zu dem Zeitpunkt war die Sicherheitslücke in Windows seit Monaten gepatched, das hätte nie passieren dürfen.
Was macht man da als Hersteller? Richtig, die Leute dazu zwingen!
Also immer wenn ihr euch über Auto-Updates beschwert, einfach an das Bild denken. Dort sitzen im Konzern tausende "Profi-IT ' ler" die alle zu doof sind Updates ordentlich zu machen.

Leider verstehe ich immer mehr, warum Microsoft das machen muss. Die haben halt einfach kein Bock auf Support, wenn mal wieder jemand seinen Account hat "hacken" lassen weil sein Passwort "123" ist und sie GitHub-weit alle Änderungen reverten müssen. Auf so dumme User hätte ich auch keine Lust.

Also: man braucht keine Telefonnummer auf die man dann SMS bekommt oder so ein Quatsch, eigentlich ist alles gut.
Und andere werden nachziehen - in ein paar Jahren ist das die beste Lösung, so wie sie es gerade machen. Und wir werden uns wünschen, dass es bei anderen auch so geht, weil dort braucht man dann wirklich eine Telefonnummer.

Danke, das ist mega hilfreich. Ich dachte, der Zweck von 2FA wäre der Nachweis eines zweiten Gerätes (was ja bei Hardware-Token so ist), aber tatsächlich geht es bei Software-Token als nur um den Nachweis eines Schlüssels. Dann mal ran an den Speck …

Edit: Läuft wie geschmiert. Ganz genau das habe ich vor drei Jahren mal gesucht, als es mit Home Office losging, aber nicht gefunden. Jetzt brauche ich nicht einmal mehr das Dienst-Handy! Vielen Dank!

Ich dachte, der Zweck von 2FA wäre der Nachweis eines zweiten Gerätes

Bzw. eines zweiten, unabhängigen Weges, das zu bekommen. Ich habs auch noch nicht ganz verstanden, echte 2FA ist das IMHO nicht :-P

Aber da musste ich auch schon durch. Hätte ich meine Telefonnummer angeben müssen, wäre mein Account jetzt gelöscht (oder Idle).

Krishty hat geschrieben: ↑24.08.2023, 22:04Jetzt brauche ich nicht einmal mehr das Dienst-Handy!

Meeh, die scheiß Authenticator-App will mir nicht mehr das Secret anzeigen. Export gibt es nicht – nur Cloud-Backup. Sie wissen wahrscheinlich schon, wieso :(

„Schön, dass Sie sich jetzt mit Microsoft über Ihr Mobiltelefon einloggen können! Wäre ja schade, wenn Sie mal einen kürzeren Weg nehmen wollten und dafür erst 2FA neu einrichten müssen!”

Du kannst dir über die Recovery-Codes ein neues geben lassen. Ich hoffe du hast die noch... (also bei GitHub. Bei deinem Diensthandy keine Ahnung :-D )

Geht nicht um Github – Firmennetzwerk z. B.

NytroX hat geschrieben: ↑24.08.2023, 22:12Bzw. eines zweiten, unabhängigen Weges, das zu bekommen. Ich habs auch noch nicht ganz verstanden, echte 2FA ist das IMHO nicht :-P

Es ist wirklich nur ein längeres Passwort. Sobald ich die 16 Buchstaben auswendig gelernt habe, ist mein Account genau so geschützt wie vorher, nur eben mit 35 Buchstaben statt 19 🤷

Jetzt kann ich zumindest das Passwort wieder auf 123 setzen, denn der Code ist ja kompliziert genug. Danke, Microsoft 🖕

Also hier im unmittelbaren Bekanntenkreis wurde wie der Zufall es so will gerade ein Facebook Account "gehackt", ich will einen Userfehler nicht ausschließen, aber es ist zumindest nicht offensichtlich wo er lag. Ich habe also, oh the irony, gerade heute 2FA für mein facebook mit Absicht angemacht (dass das überhaupt noch opt-in war ...), wo ihr jetzt hier vom Leder zieht.

Denn ganz so wie ihr sagt ist es natürlich nicht. Es macht schon Sinn wenn der Account mit dem ihr euch einloggt und der OTP nicht auf demselben physischen Gerät sind, weil es für einen Angreifer halt viel schwieriger ist beide Geräte gleichzeitig zu kompromittieren als nur eins von beiden, wenn wir mal davon ausgehen, dass es beim Erzeugen des OTP noch nicht kompromittiert war, sonst ist ja eh alles egal.

Natürlich ist das ein bisschen albern, dass das zweite Gerät ein voll funktionsfähiger Hosentaschencomputer ist auf dem wir alle Accounts sowieso nochmal haben (sodass es selbst zum einen Angriffspunkt wird) und das wir mitnehmen, wenn wir das Haus verlassen (sodass es leicht wegkommen kann).

Aber selbst das kann man noch irgendwie verteidigen, denn anders als der Computer auf deinem Schreibtisch wurde der Hosentaschencomputer konzipiert als es schon Internet gab und er hat einigermaßen vernünftiges Sandboxing und Rechtemanagement.

Am liebsten hätte man natürlich dedizierte Hardware für sowas, wenn du dich von AWS security auditen lässt will es z. B. dass das Äquivalent zu root hinter einem Hardwaretoken ist. Ich selbst hatte solche Hardware noch nicht in der Hand (also not root ... jetzt kommt es raus), Wikipedia hat ein Bild wie sowas aussehen könnte (https://de.wikipedia.org/wiki/Time-base ... lgorithmus), dem Namen nach kannte ich bis heute nur YubiKey (https://de.wikipedia.org/wiki/YubiKey)

Naja und wenn ich dann sowas lese "Im Oktober 2017 wurde bekannt, dass die unter anderem beim YubiKey 4 eingesetzte CCID-Applikation OpenPGP auf der fehlerhaften Softwarebibliothek RSALib von Infineon basiert, wodurch die Erzeugung von RSA-Schlüsselpaaren direkt am Token anfällig für die ROCA-Verwundbarkeit ist.[10] Betroffene Geräte ersetzte Yubico kostenfrei durch neue YubiKeys.[11]" fragt man sich doch ob wirklich nur die User "zu dumm sind es ordentlich zu machen".

Es gibt ja anscheinend niemanden auf der Welt, der theoretisch sichere Krypto nach Stand der Forschung auch sicher implementieren kann. Oder vielleicht nicht "niemanden" aber zumindest nicht genügend, um ein bugfreies openSSL zu haben oder so.

Krishty hat geschrieben: ↑24.08.2023, 22:33

NytroX hat geschrieben: ↑24.08.2023, 22:12Bzw. eines zweiten, unabhängigen Weges, das zu bekommen. Ich habs auch noch nicht ganz verstanden, echte 2FA ist das IMHO nicht :-P

Es ist wirklich nur ein längeres Passwort. Sobald ich die 16 Buchstaben auswendig gelernt habe, ist mein Account genau so geschützt wie vorher, nur eben mit 35 Buchstaben statt 19 🤷

Jetzt kann ich zumindest das Passwort wieder auf 123 setzen, denn der Code ist ja kompliziert genug. Danke, Microsoft 🖕

Du benutzt es falsch! Der ganze Sinn der Übung ist dass du nicht jedes mal das ganze Secret eingibst sondern nur einen ständig wechselnden Wert mit dem ein Angreifer nach 30 Sekunden nichts mehr anfangen kann. Das ganze secret sollst du von dem Gerät isolieren auf dem du das klassische Passwort (also den "ersten Faktor") eingibst sodass nie beide Secrets auf demselben Gerät sind.

Das zweite Gerät muss ein "Gerät sein" weil du nicht im Kopf die Einmalinformation (natürlich ist es kein echtes OTP) aus dem Secret ableiten kannst. Das erste Gerät muss ein "Gerät" sein, weil du mit dem Internet sprechen willst.

Kritik schön und gut, aber alles Poweruser mäßig zu umgehen, was die Sache sicher macht und dann rumzumoppern dass es nicht sicher ist ... not cool!

Alexander Kornrumpf hat geschrieben: ↑24.08.2023, 22:38Am liebsten hätte man natürlich dedizierte Hardware für sowas, wenn du dich von AWS security auditen lässt will es z. B. dass das Äquivalent zu root hinter einem Hardwaretoken ist. Ich selbst hatte solche Hardware noch nicht in der Hand (also not root ... jetzt kommt es raus), Wikipedia hat ein Bild wie sowas aussehen könnte (https://de.wikipedia.org/wiki/Time-base ... lgorithmus), dem Namen nach kannte ich bis heute nur YubiKey (https://de.wikipedia.org/wiki/YubiKey)

Der meiner besseren Hälfte sieht wie ein kleiner USB-Stick mit Anzeige aus. Niedlich.

Ich benutze für meine Bank übrigens einen Kartenleser, der genau das gleiche macht. Nur, dass das Secret halt von meiner Bankkarte gelesen wird, und nicht gespeichert (hoffentlich). Damit wäre es dann echtes 2FA, und das Gerät verfügt auch nicht über Web-Verbindung (weil es selbst bei krimineller Energie nie lange genug an ist, einen echten Login vollenden zu können, LOL!) ❤️ Schade, dass ich meinen Github-Schlüssel nicht dort eintippen kann …

Alexander Kornrumpf hat geschrieben: ↑24.08.2023, 22:38OpenPGP […] openSSL

Ich habe für PGP/GnuPG noch ein paar Rants reserviert, die aber zu leicht die 10.000 Worte reißen könnten.

Alexander Kornrumpf hat geschrieben: ↑24.08.2023, 22:44Kritik schön und gut, aber alles Poweruser mäßig zu umgehen, was die Sache sicher macht und dann rumzumoppern dass es nicht sicher ist ... not cool!

Mein Passwort war aber sicher und mein System ist es auch und damit ist 2FA blanke Schikane. Wenn die es mir so schwer wie möglich machen wollen, mache ich es mir halt so einfach wie möglich.

Krishty hat geschrieben: ↑24.08.2023, 22:49

Alexander Kornrumpf hat geschrieben: ↑24.08.2023, 22:44Kritik schön und gut, aber alles Poweruser mäßig zu umgehen, was die Sache sicher macht und dann rumzumoppern dass es nicht sicher ist ... not cool!

Mein Passwort war aber sicher und mein System ist es auch

Ähm ... lol. OK, Boomer!

Dein System ist nicht sicher. Du weißt es, ich weiß es. Dein System ist wahrscheinlich besser abgesichert als die meisten, ok, aber es ist nicht in irgendeinem binären Sinne sicher.

Die "Schikane" ist dass du github ja nicht gebeten hast deinen account besser abzusichern. Es ist aber nicht wahr, dass TOTP richtig angewendet, nicht auch deinen account weiter abgesichert hätte.

Fun Fact: Github bittet mich eindringlich, doch bitte die Recovery Keys runterzuladen. Mit dem very Gerät, mit dem ich mich einlogge. Kann ich die auch nur zusammen mit einem anderen Gerät benutzen? Oder haben jetzt 90 % der Leute, die 2FA auf Github nutzen, die Recovery Keys auf der Festplatte ihres Arbeitsrechners?

(War vorher ein Edit, aber so passt’s besser)

Krishty hat geschrieben: ↑24.08.2023, 22:56 Fun Fact: Github bittet mich eindringlich, doch bitte die Recovery Keys runterzuladen. Mit dem very Gerät, mit dem ich mich einlogge. Kann ich die auch nur zusammen mit einem anderen Gerät benutzen? Oder haben jetzt 90 % der Leute, die 2FA auf Github nutzen, die Recovery Keys auf der Festplatte ihres Arbeitsrechners?

(War vorher ein Edit, aber so passt’s besser)

Ja, wie ich schon sagte. Die Krypto-Protokolle sind in Ordnung, die Implementierung ist zu Heulen. Und ja, oft - also gerade nicht bei buggy openSSL natürlich - ist der Grund für zweiteres dass du es irgendwie so verpacken musst, dass Menschen ohne Ahnung es noch nutzen können. #allesanzuenden

Einer noch, so lange mein Blut noch kocht: In ihrer Pressemitteilung führen sie Supply Chain Attacks als Grund an, 2FA zu erzwingen. “Sonst kann jeder ein Backdoor in NPM hochladen mimimi etc.”

Ich war immer etwas skeptisch gegenüber fefes Ansicht, dieses Sicherheitstheater sei bloß eine Externalisierung von Kosten. Aber hier sehe ich es gerade richtig krass.

Microsofts Azure und die Hälfte der übrigen Produkte ist mittlerweile komplett „auf Open Source gebaut“ (also ironischerweise auf dem jahrzehntelangen Schweiß der Microsoft-Gegner), und sie haben keine Chance zu überblicken, welcher Code da an- und abfließt. Und selbst wenn – Code kann man nicht trauen, weil jede Zeile ein Backdoor im Stil des Obfuscated C Contest sein könnte.

Also schieben sie das Vertrauensproblem auf Personen ab. „Ja aber dass DA ein Backdoor drin sein könnte, das konnten wir ja nicht wissen! Wir haben sicher gestellt, dass die Commits NUR vom offiziellen libFaggot-Team kommen!! UND dass sie Zwei-Faktor-Authentifizierung nutzen!!! Wenn DER seine Recovery Keys nicht händisch auf einen internetlosen Zettel abkritzelt und im Tresor verstaut (Code muss mindestens Zahlen, Buchstaben, und zwei Sonderzeichen enthalten) sondern gemäß Button runterlädt, können WIR doch nichts dafür!! WIR HABEN DOCH ALLES GETAN!!!“

Als ob es die NSA einen Scheiß kümmern würde, ob irgendwer in irgendeinem Github-Projekt nun 2FA aktiviert hat oder nicht. Die Repositories liegen schließlich auf US-Servern.

Aber aber ... du willst doch nicht etwa sagen Linus' berühmtes "enough eyeballs" Zitat wäre Bullshit? Wo kommen wir denn da hin?

Fefes verdient sein Geld damit eyeballs for hire zu sein. Ich würde das mit in die Bewertung dessen was er sagt einfließen lassen.

Dass wir nicht unsere ganze Infrastruktur darauf aufbauen, dass der Typ der "libFaggot" (what's with the casual homophobia?) wartet auf sein Passwort aufpasst ist common sense. Dass das alleine noch gar nichts löst ist zwar richtig, ändert aber daran nichts. Hier dann die alte Frage einsetzen ob du deine Haustür abschließt ...

Alexander Kornrumpf hat geschrieben: ↑24.08.2023, 23:17Aber aber ... du willst doch nicht etwa sagen Linus' berühmtes "enough eyeballs" Zitat wäre Bullshit? Wo kommen wir denn da hin?

Fefes verdient sein Geld damit eyeballs for hire zu sein. Ich würde das mit in die Bewertung dessen was er sagt einfließen lassen.

Deshalb war ich da recht skeptisch. Kurze Anekdote aus dem Leben: Ich habe mal eine recht verbreitete Bibliothek aus diesem Forum wo eingebaut, und dieses wo ist heute noch in Benutzung.
Ich habe besagte Bibliothek auch mal geeyeballed, und brauchte keine Minute um triviale Buffer Overflows zu finden. Ich habe ein Bisschen was ausgebügelt, aber ultimativ musste ich vor der schieren Menge schlechten Codes kapitulieren. Und von den Abhängigkeiten wollen wir gar nicht erst anfangen. (Heißt ja nicht, dass die Entwickler doof sind – sondern Security ist einfach nicht ihre Kernkompetenz, und da ist ganz viel ganz alter Code.)
Das macht mir bis heute Bauchschmerzen und ich überlege mindestens wöchentlich, wie ich es hätte besser machen können (außer: Bibliothek ganz weglassen und Schafhirte werden).

Ganz sicher weiß ich: 2FA oder Code Signing hätte nicht geholfen. Nicht das kleinste Bisschen.

Ein Re-Write in Rust/Go/whatever hätte wahrscheinlich die Sicherheit vertausendfacht. Mein Ziel fürs nächste Mal: Ich schiebe das ganze Ding in einen separaten Prozess, der nur I/O-Pipes zum Hauptprozess bekommt. Und dann läuft dieser Prozess als separater User mit Null Zugriffsrechten auf Dateisystem oder sonstwas. Als Sandbox quasi, aber bitte mit weniger Komplexität als VM/Hypervisor hinzufügen.

Jedenfalls: solche Lösungen will ich sehen. Memory Correctness in Sprachen; Principle of Least Privilege. Aber kein „Hurr durr 2FA macht unsere Supply Chain Attacks weg”.

(what's with the casual homophobia?)

Keine; mein erster Gedanke war libPoo, aber das geht so schwer über die Lippen. Als ich auf 4chan war, war Faggot schon/noch allgemeine Beschimpfung für alles und jeden. Und libTard ist ja auch schon besetzt 😁

Krishty hat geschrieben: ↑24.08.2023, 23:39 Jedenfalls: solche Lösungen will ich sehen. Memory Correctness in Sprachen; Principle of Least Privilege. Aber kein „Hurr durr 2FA macht unsere Supply Chain Attacks weg”.

Nur dass das natürlich orthogonale Lösungen für völlig verschiedene Probleme sind. Sind wir uns einig was eine Supply Chain Attack ist? Dann schreibst du halt deine Bibliothek in Rust, die ist jetzt korrekt und bugfrei, sie wird erfolgreich, alle ziehen die in ihre CI/CD Pipelines rein, und dann kommt Mallory, verschafft sich Zugriff auf deinen crates.io account und ersetzt deine tolle Lösung durch eine bösartige und alle Pipelines ziehen das schön automatisch in ihre Projekte.

Aber _dein_ Passwort ist ja sicher. Nehmen wir besser nicht dich als Beispiel. Hat der generische Programmierer der alle Buffer Overflows wegmacht aber dessen crates.io Passwort "passwort123" ist die Sicherheit wirklich "vertausendfacht" wie du sagst? Oder hat er einen potentiell aufwändigen Exploit nicht vielleicht doch eher durch einen trivialen Exploit ersetzt?

Das Sicherheitsmodell unter dem es falsch ist den trivialen Exploit "Supply Chain Attack" zu schließen, weil es ja soviele andere weniger trivale Exploits gibt die zu lösen ein interessanteres Ingenieursproblem ist, verstehe ich ehrlich gesagt nicht.

Mmh, geht's bei dem Kram nicht im Grunde um Unachtsamkeit bei Mitarbeitern? Wenn ich Leute von zuhause arbeiten lasse oder die ihr Handy nutzen, um sich die Arbeitsmails anzuschauen, dann will ich nicht, dass ein Keylogger oder Phishing ausreicht, um die Firma zu breachen. OTP ist da auch eher Kacke, wenn da jemand schnell live mittippen kann. Push ist da glaube ich eigentlich sicherer. Lastpass wurde glaube ich trotz 2FA mit nem Keylogger auf nem Privatrechner geknackt, weil OTP ohne Duplicate-Key-Erkennung oder so...

Alexander Kornrumpf hat geschrieben: ↑25.08.2023, 00:03Nur dass das natürlich orthogonale Lösungen für völlig verschiedene Probleme sind. Sind wir uns einig was eine Supply Chain Attack ist?

Ja. Mallorys böse Lösung kann dann nicht deine Festplatte gegen Ransom verschlüsseln, weil meine Web-Portal-Lösung überhaupt keinen Schreibzugriff aufs Dateisystem kriegt.

Natürlich kann ich hier nicht in zwei Sätzen alle Supply-Chain-Attack-Probleme lösen, denn dafür hatte ich heute noch nicht genug Zucker. Ich hatte gehofft, dass die Richtung klar wäre.

Alexander Kornrumpf hat geschrieben: ↑25.08.2023, 00:03Das Sicherheitsmodell unter dem es falsch ist den trivialen Exploit "Supply Chain Attack" zu schließen, weil es ja soviele andere weniger trivale Exploits gibt die zu lösen ein interessanteres Ingenieursproblem ist, verstehe ich ehrlich gesagt nicht.

Weil 2FA nunmal keine Supply Chain Attacks schließt. Statt eines Github-Accounts mit Passwort braucht ein Bösewicht nun einen Github-Account mit Passwort *und* ein Handy. Game Changer!

Ich erkenne ja an, dass es Identitätsdiebstahl schwieriger macht, und jeder Gauner fängt mit Identitätsdiebstahl an. (Denn warum sollte ich ein Verbrechen unter meinem namen begehen, wenn ich deinen dafür benutzen kann?) Ich wiederhole aber nochmal: Wenn wir dem Code schon nicht trauen können, macht es auch nichts besser, dass wir anfangen, stattdessen Identitäten zu vertrauen.

Wenn Leute blind einer crates.io trauen, die von Krishty kommt statt von NorthKoreaIsBestKorea66842215, dann hätten sie einfach nicht Software entwickeln sollen.

Chromanoid hat geschrieben: ↑25.08.2023, 00:05Mmh, geht's bei dem Kram nicht im Grunde um Unachtsamkeit bei Mitarbeitern? Wenn ich Leute von zuhause arbeiten lasse oder die ihr Handy nutzen, um sich die Arbeitsmails anzuschauen, dann will ich nicht, dass ein Keylogger ausreicht, um die Firma zu breachen.

Ja, könnte sein. Aber warum zur Hölle zwingt Github mich dann, das zu benutzen?

Krishty hat geschrieben: ↑25.08.2023, 00:17Ja, könnte sein. Aber warum zur Hölle zwingt Github mich dann, das zu benutzen?

Weil die dich bevormunden, dich für unachtsam halten und sich vor Typen schützen wollen, die behaupten Github wäre Schuld daran, dass sie ihr Github-Passwort bei nem shitty gehackten Onlineshop, der Passwörter in Plaintext speichert, eingegeben haben. So a'la "Achtung der Kaffee ist heiß" mäßig.

NytroX hat geschrieben: ↑24.08.2023, 21:50 Also immer wenn ihr euch über Auto-Updates beschwert, einfach an das Bild denken. Dort sitzen im Konzern tausende "Profi-IT ' ler" die alle zu doof sind Updates ordentlich zu machen.

Ne, die Leute die zu doof sind, sind die Update Hersteller, nicht die, die sie nicht installieren.

Wenn ein Update kommt, ich kurz auf ok klicke, dann 30 Sekunden warten muss und danach alles so ist wie früher nur halt in sicher mache ich das natürlich. Ggf. warte ich damit 2 Tage bis irgendwas fertig gerechnet hat bevor ich einen Neustart machen muss, kein Problem.

Aber in der Realität wird halt nicht zwischen Featureupdate und Sicherheitsupdate getrennt. Als Teenager hatte ich Zeit mit Dingen rumzuspielen, heute ist der PC ein Arbeitsgerät und hat zu funktionieren. Wenn ich mir angucke, wie oft in den letzten 10 Jahren was wegen einem dummen Feature-Update kaputt gegangen ist und wie oft mir irgendwas durch einen Virus kaputt gegangen ist komme ich auf eine Quote von 99 zu 1 oder so.

Mag ja sein, dass das neue Userinterface intuitiver ist als das alte, aber das alte kann ich halt schon, die Klicks sitzen und ich muss nicht nachdenken. Das Neue muss ich erst lernen und das braucht Zeit. Ich will gefälligst selbst entscheiden wann ich Zeit habe meine Abläufe zu optimieren (indem ich z.B. auf neuere Programmversionen umstelle), aber wenn in einer Woche Deadline ist kann es nicht sein dass ich einen halben Nachmittag irgendetwas reparieren muss weil irgendein Wichser ein Zwangsfeature-Update veröffentlicht hat. Ich bin doch kein Zirkustier das für andere springt wenn sie pfeifen, mein Rechner hat für mich zu arbeiten, nicht umgekehrt.

Klar gibt es immer noch Entwickler die vernünftige Updates verteilen, aber das Vertrauen ist halt einfach weg. Deswegen nutze ich auch für alle Dienst wo es geht das Webinterface anstatt irgendwelche bescheuerten Apps zu installieren, weil ich absolut kein Vertrauen habe, dass meine Daten nicht gestohlen werden und ich nicht mit nervigen Benachrichtigungen und Werbung bombardiert werde und im Hintergrund nicht mein Akku leergenuckelt wird. Die Webseiten sind in der Regel auch scheiße gemacht und ich wäre so so dankbar wenn es eine vernünftige App gäbe, aber die Erfahrung zeigt, dass man bei dieser Wette nur verliert, deshalb probier ichs halt gar nicht erst.

Krishty hat geschrieben: ↑25.08.2023, 00:17

Alexander Kornrumpf hat geschrieben: ↑25.08.2023, 00:03Nur dass das natürlich orthogonale Lösungen für völlig verschiedene Probleme sind. Sind wir uns einig was eine Supply Chain Attack ist?

Ja. Mallorys böse Lösung kann dann nicht deine Festplatte gegen Ransom verschlüsseln, weil meine Web-Portal-Lösung überhaupt keinen Schreibzugriff aufs Dateisystem kriegt.

Verstehe ich nicht. Mallorys böse Lösung ersetzt deine gute Lösung denn Mallory kann dich gegenüber der Verteilungsinfrastruktur impersonaten. Egal wie gut deine Lösung war, es ist irrelevant denn sie kommt nicht mehr beim Nutzer an. Mallory's böser Code kommt an.

Weil 2FA nunmal keine Supply Chain Attacks schließt. Statt eines Github-Accounts mit Passwort braucht ein Bösewicht nun einen Github-Account mit Passwort *und* ein Handy. Game Changer!

Wir sind uns einig dass er statt einem Secret (Passwort) jetzt zwei Secrets (Passwort und TOTP seed braucht), ja? Dass du das zweite Secret per Design komplett vom Internet isolieren kannst? Dass es schwerer ist an beide Secrets zu kommen wenn eins davon nicht mit dem Internet verbunden ist? Was Chromanoid über Keylogger sagt stimmt zwar prinzipiell, aber wenn der letzte Keystroke des OTP Code den Request abfeuert (so macht es facebook, habe es wie gesagt heute erst ausprobiert) und der Server danach den OTP Code verbrennt, wird das Zeitfenster was der Angreifer (der eine zusätzliche Latenz hat du - server vs. du - angreifer - server) treffen muss ziemlich klein.

Und ja, am Ende ist der OTP Generator in der Realität nicht auf dem hypothetischen isolierten Gerät sondern auf dem Handy. Aber der Angreifer brauch nicht "ein Handy" er braucht _dein_ Handy.

Ist das alles perfekt? Sicherlich nicht. Ist es nur Theater? Auch sicherlich nicht.

Ich erkenne ja an, dass es Identitätsdiebstahl schwieriger macht, und jeder Gauner fängt mit Identitätsdiebstahl an. (Denn warum sollte ich ein Verbrechen unter meinem namen begehen, wenn ich deinen dafür benutzen kann?) Ich wiederhole aber nochmal: Wenn wir dem Code schon nicht trauen können, macht es auch nichts besser, dass wir anfangen, stattdessen Identitäten zu vertrauen.

??? Der Identitätsdiebstahl dient nicht dazu die Identität des Angreifers zu verschleiern sondern _deinen_ Zugriff auf die Supply Chain zu benutzen, der logischerweise an _deine_ Identität gebunden ist. Wenn wir dem Code schon nicht trauen können dann ist es natürlich besser wenn ich dem Autoren der 5 Jahre alten Bibliothek mit den 5 Millionen Nutzern traue, bei der es augenscheinlich nie ein Problem gab, als wenn ich der Bibliothek traue, die gerade heute jemand hochgeladen hat. Nicht im Sinne von absoluter Sicherheit natürlich, aber im Sinne von: wenn du auf eine von beiden dein Haus verwetten müsstest, wäre es dir _wirklich_ egal welche von beiden?

Und natürlich ist es dann ein Problem wenn uns jemand diese Bibliothek unter dem Hintern weg austauscht, weil er den Maintainer impersonaten kann.

Wogegen das natürlich nicht hilft ist der Long-Con, wo du 5 Jahre lang hochqualitative Software entwickelst, die siich durchsetzt weil alle sie benutzen wollen und dann _selbst_ den Schadcode triggerst. Warum machen das nicht mehr Angreifer so? Vielleicht doch weil der Aufwand für die 5 Jahre in keinem Verhältnis zum Nutzen steht, wenn ich viel einfacher 5 Jahre Vertrauensbildung von jemand anderem per Indentitätsdiebstahl klauen kann?

Späße wie https://snyk.io/blog/peacenotwar-malici ... erability/ oder https://www.bleepingcomputer.com/news/s ... s-of-apps/ sind ja sicher bekannt. Ich denke fed-up OSS Entwickler und Typosquatting sind die größten Software-Supply-Chain-Gefahren aktuell. Ich würde behaupten feindliche Übernahmen werden zu schnell bemerkt.

Chromanoid hat geschrieben: ↑25.08.2023, 01:39 Ich würde behaupten feindliche Übernahmen werden zu schnell bemerkt.

"zu schnell" relativ zu was?

Das implizite Argument dass Identitätsdiebstahl sich nicht lohnt, weil es ja sowieso bemerkt wird ist trivial dadurch widerlegt dass Identitätsdiebstahl stattfindet und außerdem offensichtlich eine Funktion dessen wie teuer Identitätsdiebstahl für den Angreifer ist. Natürlich wollen wir alle kein security Wettrüsten, aber 2FA ist doch in der richtigen Richtung assymetrisch?! Es ist relativ billig für den Verteidiger (?) und überproportional teurer für den Angreifer. Genau das will man doch.

Das implizite Argument dass es ja bemerkt würde bevor ein Schaden entstehen kann ... ich bin nicht überzeugt. Vielleicht sind die Supply Chains stabiler als ich es mir vorstelle, mein Eindruck ist ein anderer.

Bei Identitätsdiebstahl allgemein sieht das anders aus, da stimme ich Dir zu. Ich persönlich nutze MFA auch wo es geht, weil das die Accounts ja an verschiedenen Stellen gegen Passwortverlust absichert - sei es weil mein Passwortmanager die Passworttresore leakt oder weil ich bei einem "Notfall" einen mir unbekannten PC (unbekannterweise mit Keylogger) nutzen muss.

Ich habe aber noch nie von einer feindlichen Library-Übernahme gelesen, die nicht schnell entdeckt wurde. Gerne Links dazu! Bei Libraries mit ein paar Sternen/Watchern muss da ganz schön viel passieren, dass das nicht auffällt, wenn da ein merkwürdiges Release kommt. Natürlich ist es dann vielleicht für einen ersten Schaden zu spät, aber solange jemand ein Auge auf die Vulnerabilities hat, sollte das dann zumindest aufgearbeitet werden können. NPM & Co. sind da natürlich wesentlich anfälliger als Ökosysteme, wo Library-Versionen nicht automatisch aktualisiert werden.

Ich lese eigentlich immer nur von Brandjacking / Typosquatting, sowie OSS-Entwicklern, die keine Lust mehr haben, Rogue gehen oder den Stecker ziehen, wo das dann größere Runden macht. Das habe ich dann sogar mal direkt mitbekommen, als es merkwürdige CLI-Ausgaben beim AWS CDK gab (siehe auch https://twitter.com/s0enke/status/1480248975722692617).