Anmelden
(Bild: Dmitri T/Shutterstock.com)
Die Houthis sperren den Seeweg nach Saudi-Arabien. Goldman Sachs warnt vor einem Brent-Ölpreis von 120 Dollar pro Barrel.
Die Straße von Hormus ist faktisch geschlossen, und jetzt droht auch der Seeverkehr durch das Rote Meer zu kippen. Der Grund dafür sind die Houthi-Rebellen im Jemen, die am Montag eine Seeblockade gegen Saudi-Arabien [1] verhängt haben – mit sofortiger Wirkung, wie Militärsprecher Yahya Saree erklärte [2].
Die Houthis begründen den Schritt mit den Worten "Belagerung gegen Belagerung", also als Vergeltung für die saudische Blockade jemenitischer Häfen und Flughäfen.
Der Ölpreis dürfte dadurch weiter steigen, einmal weil sich das Angebot verknappen könnte, aber auch, weil die Transportwege länger werden. Der Brent-Ölpreis notiert laut Bloomberg bereits bei 89 US-Dollar pro Barrel [3], ein Plus von über 20 Prozent allein in diesem Monat.
In Saudi-Arabien trifft die Drohung der Houthis einen Nerv. Seitdem der Iran-Krieg den Tankerverkehr durch die Straße von Hormus faktisch zum Erliegen gebracht hat, pumpt das Königreich sein Rohöl über die 1.202 Kilometer lange Ost-West-Pipeline zum Rotmeerhafen Yanbu.
Rund 2,5 Millionen Barrel pro Tag laufen dort auf Tanker, die anschließend durch die Meerenge von Bab el-Mandeb müssen, direkt an der jemenitischen Küste vorbei, von wo aus die Houthis mit Raketen und Drohnen [4] auf Schiffe schießen können.
Parallel dazu geht der Krieg gegen den Iran unvermindert weiter, und die Islamischen Revolutionsgarden feuern im Gegenzug auf Schiffe, welche die Straße von Hormus ohne ihre Erlaubnis passieren wollen.
Am Dienstag traf ein Projektil den kuwaitischen Produkttanker "Kaifan" nordöstlich von Limah in Oman, wie Bloomberg unter Berufung auf die EOS Risk Group berichtet [5]. In der Woche bis zum 19. Juli passierten im Schnitt nur noch sieben Tanker pro Tag die Meerenge – die Hälfte der Vorwoche, so S&P Global Energy.
Die Sinokor Group aus Südkorea etwa bietet Besatzungen laut Bloomberg sechs Monatsgehälter Bonus für eine Durchfahrt.
Die ökonomischen Folgen zeichnen sich längst ab. Goldman Sachs hält laut Bloomberg einen Brent-Preis von über 120 Dollar im vierten Quartal für möglich, sollten die Störungen anhalten.
Rob Thummel von Tortoise Capital warnt gegenüber Bloomberg, die geschrumpften Lagerbestände ließen "einfach nicht viel Spielraum für Fehler".
Die IEA stufte schon im März die Lage als größte Versorgungsstörung in der Geschichte des globalen Ölmarkts ein, da mindestens 8 Millionen Barrel pro Tag ausfielen.
Die USA fliegen den zehnten Tag in Folge Angriffe auf iranische Militärziele, Außenminister Marco Rubio schließt Verhandlungen vorerst aus.
Ob die Houthis ihre Blockade tatsächlich durchsetzen können, bleibt offen, aber ihr Arsenal aus Anti-Schiff-Raketen und Kamikaze-Drohnen reicht aus, um Reeder großflächig abzuschrecken.
Anoop Singh von Oil Brokerage brachte es gegenüber Bloomberg auf den Punkt: "Wenn es eine alternative Route gibt, wird man diese wählen".
URL dieses Artikels:
https://www.heise.de/-11372207
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Kimi K3 könnte proprietäre US-Modelle unter Druck setzen
(Bild: Samuel Boivin/Shutterstock.com)
Moonshot AIs Kimi K3 ist das größte offen zugängliche KI-Modell der Welt. Die Nachfrage überrollte die Server binnen 48 Stunden. Was kann das neue Modell?
Nut wenige Wochen nach Anthropics Durchbruch mit "Fable" gibt es bereits einen neuen aufsteigenden Stern am KI-Himmel: Mit Mit 2,8 Billionen Parametern ist Kimi K3 nach eigenen Angaben von Moonshot AI das größte KI-Modell, das bislang als Open-Weight [1] (bei dem die Modellparameter frei verfügbar sind) veröffentlicht wurde. Das in Peking ansässige Startup hat damit eine Welle ausgelöst, die an den Finanzmärkten ebenso spürbar ist wie in der KI-Branche selbst.
Die Nvidia-Aktie gab am Freitag um 2,2 Prozent nach, die Papiere von Applied Materials verloren sogar mehr als fünf Prozent – ein Echo des sogenannten "DeepSeek-Moments" Anfang 2015, als das chinesische Modell R1 den Marktwert von Nvidia an einem einzigen Tag um fast 600 Milliarden US-Dollar einbrechen ließ. Doch was kann das neue Modell wirklich?
Moonshot AI gibt in einem Beitrag auf seinem technischen Blog [2] an, dass Kimi K3 alle Konkurrenzmodelle mit Ausnahme von Anthropics "Claude Fable 5" und OpenAIs "GPT-5.6 Sol" übertreffe.
In der unabhängigen Entwickler-Plattform Arena, die Modelle in Blindtests bewertet, erreichte K3 mit 1.679 Punkten den ersten Platz in der Kategorie Frontend-Code-Entwicklung [3] – noch vor Claude Fable 5. In der agentischen Disziplin (also beim autonomen Lösen komplexer Aufgaben) belegt K3 den vierten Platz, hinter GPT 5.6 (Sol) und vor Claude Sonnet 5.
"Trotz anhaltender Einschränkungen bei der Hardware- und Rechenkapazität in China zeigt K3, dass eine Skalierung des Vortrainings in Verbindung mit architektonischen Innovationen nach wie vor erhebliche Leistungssprünge für chinesische Vorzeigemodelle bewirken kann", kommentierten [4] Analysten der Bank of America in einer von Alex Liu verfassten Analyse.
Die Veröffentlichung des Modells hat indes einen kleinen Hype ausgelöst: Die Nachfrage überstieg innerhalb von 48 Stunden nach der Veröffentlichung die verfügbaren GPU-Ressourcen. Auf der Plattform X teilte Moonshot mit [5], die Kapazitätsgrenzen seien "fast erreicht". Um bestehende Nutzer zu schützen und Qualitätseinbußen zu vermeiden, wurden neue Abonnements vorübergehend gestoppt. Bestehende zahlende Kunden seien nicht betroffen.
Einen konkreten Zeitplan für die Wiederaufnahme neuer Abonnements nannte das Unternehmen nicht. Parallel dazu kündigte Moonshot eine Neustrukturierung seiner Tarife an.
Der Vergleich mit DeepSeek, das ebenfalls frei zugänglich ist [6], liegt nahe, greift aber nur bedingt. DeepSeek R1 hatte Anfang 2025 vor allem deshalb für Aufruhr gesorgt, weil es Training und Betrieb von KI-Modellen deutlich kostengünstiger machte und damit die Annahme erschütterte, dass für leistungsstarke KI zwingend enorme Rechenleistung nötig sei (Telepolis berichtete [7]).
Kimi K3 verbessert zwar ebenfalls die Recheneffizienz – die sogenannte Sparsity-Rate, also der Anteil der pro Aufgabe tatsächlich aktivierten Parameter an der Gesamtgröße des Modells, und erreicht laut [8] Bloomberg-Daten einen Rekordwert –, tut dies jedoch auf Basis eines deutlich größeren Modells.
Pro Token werden lediglich 16 der insgesamt 896 sogenannten "Experten" aktiviert, was rund 1,8 Prozent entspricht. Dennoch muss jeder der 2,8 Billionen Parameter im Arbeitsspeicher vorgehalten werden. Selbst nach Komprimierung belegt das Modell noch rund 1,4 Terabyte Speicherplatz. Für den produktiven Einsatz empfiehlt Moonshot AI Cluster aus mindestens 64 Hochleistungsbeschleunigern.
Das bedeutet: Anders als DeepSeek dürfte Kimi K3 die Nachfrage nach leistungsstarker KI-Hardware nicht dämpfen, sondern eher aufrechterhalten – insbesondere nach Hochbandbreiten-Speicher von SK Hynix, nach Nvidia-KI-Systemen der neuesten Generation sowie nach fortschrittlicher Chipfertigung von TSMC.
Moonshot AI beschreibt zwei zentrale architektonische Neuerungen: "Kimi Delta Attention", ein hybrides lineares Aufmerksamkeitsverfahren, sowie "Attention Residuals", die verändern, wie Informationen zwischen den Schichten des Modells weitergegeben werden.
Das Modell verfügt über ein Kontextfenster von einer Million Token und unterstützt nativ die Verarbeitung von Bildern. Für das Training wurde ein sogenanntes quantisierungsbasiertes Verfahren eingesetzt, das auf MXFP4-Gewichten [9] und MXFP8-Aktivierungen [10] basiert – eine Kombination, die laut Moonshot auf möglichst vielen Hardware-Plattformen lauffähig sein soll.
Ein Benchmarking der Kernel-Optimierung führte Moonshot auf Nvidias H200 sowie auf einem nicht namentlich genannten "GPGPU eines alternativen Herstellers" durch.
Daneben kommt MiniTriton zum Einsatz, ein von Moonshot selbst entwickelter Compiler, der auf dem quelloffenen Triton-Framework basiert. Bemerkenswert ist, dass Moonshot für Vergleichstests auch die Nvidia L20 nutzt – eine abgespeckte Grafikkarte, die unter den US-amerikanischen Exportbeschränkungen nach China verkauft werden darf.
Sämtliche bisher veröffentlichten Leistungswerte stammen von Moonshot selbst oder basieren auf API-Zugängen und lassen sich derzeit nicht unabhängig überprüfen.
Die vollständigen Modellgewichte sollen am 27. Juli öffentlich zugänglich gemacht werden. Unternehmen, die das Modell dann selbst lokal betreiben möchten, benötigen weiterhin umfangreiche KI-Hardware. Die API-Preise liegen bei 0,30 US-Dollar pro Million Cache-Treffer-Eingabe-Token, 3 US-Dollar bei Cache-Fehltreffern und 15 US-Dollar pro Million Ausgabe-Token.
Anthropic hatte Moonshot im Februar vorgeworfen [11], 3,4 Millionen Konversationen mit Claude-Modellen genutzt zu haben, um eigene Modelle durch sogenannte Destillation zu trainieren. Kimi K3 erreicht in Benchmarks nun Werte, die nahe an den Modellen liegen, die in diesem Vorwurf genannt wurden. Derartige Vorwürfe sind in der Branche allerdings keine Seltenheit, auch OpenAI-Ingenieure sollen sich bereits bei Anthropic bedient haben [12].
Moonshot AI nutzt die Aufmerksamkeit rund um Kimi K3, um den eigenen Börsengang voranzutreiben. Das Unternehmen hat den entsprechenden Aktionärsbeschluss an seine Investoren verteilt und bittet um Zustimmung zu einem Börsengang in Hongkong.
Laut [13] Bloomberg könnte eine laufende Finanzierungsrunde das erst drei Jahre alte Startup mit mehr als 30 Milliarden US-Dollar bewerten. Als Grundlage dient ein jährlicher wiederkehrender Umsatz, der im Juni 300 Millionen US-Dollar erreicht haben soll.
Für US-amerikanische KI-Unternehmen wie OpenAI und Anthropic, die selbst Börsengänge erwägen, ist das eine ungünstige Entwicklung: Sollte Moonshot AI trotz der Größe seines Modells kostengünstigere Dienste anbieten können, dürfte das auf die Bewertungen der amerikanischen Konkurrenz drücken.
URL dieses Artikels:
https://www.heise.de/-11371967
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Bild: Shutterstock.com
Wir wollen im Urlaub möglichst nichts tun. Vielleicht ist genau das der Grund, warum Erholung nicht funktioniert.
Endlich frei. In 14 Bundesländern haben die Sommerferien bereits begonnen. Nur Baden-Württemberg und Bayern warten noch. Deutschland fährt in den Urlaub.
Jedes Jahr erscheinen Ende August Texte darüber, wie sich das Urlaubsgefühl in den Alltag retten lässt. Fast alle behandeln Erholung wie einen Vorrat, den man nur langsam genug aufbrauchen müsse.
Das hat im vergangenen Jahr nicht funktioniert, im Jahr davor ebenso wenig und vermutlich auch in den fünf Jahren zuvor nicht. Sollte man überhaupt ein entspanntes Gefühl aus dem Urlaub mitgebracht haben, wird es rasch zur Erinnerung.
Spätestens nach einer Arbeitswoche ist die Erholung verflogen, und die illuminierten und bronzierten Gesichter sind wieder zu Alltagsmasken aus Gummi und Käse geworden.
Vielleicht verstehen wir Erholung falsch.
Das legt ein Artikel des Psychiaters Richard A. Friedman nahe, den das US-Magazin The Atlantic derzeit wieder aus seinem Archiv hervorholt. Friedmans Text "Beach Vacationers Are Doing It Wrong" [1] (Strandurlauber machen es falsch) erschien bereits 2022. Seine zentrale These steht im Untertitel: Wer wirklich abschalten will, sollte sich körperlich anstrengen.
Die Empfehlung passt verdächtig gut in eine Gegenwart, in der selbst Erholung zur Optimierungsaufgabe geworden ist: Schritte zählen, Laufstrecken dokumentieren, Schlafwerte prüfen, Proteine berechnen. Soll dieser Leistungsbetrieb nun auch noch den Urlaub erobern?
Viele Menschen träumen schließlich vom Liegestuhl, vom Buch, vom Strand und davon, möglichst nichts tun zu müssen. Das ist vollkommen verständlich.
Seine Antwort widerspricht fast allem, was wir mit Erholung verbinden.
Wer reglos am Strand liegt, warnt Friedman, findet sich womöglich nicht in tiefer Entspannung wieder, sondern in Langeweile, Unruhe und den eigenen Problemen. Verbringen wir den Urlaub also schlicht falsch?
"Ein besserer Urlaub ist einer, in dem intensive körperliche Aktivität eine zentrale Rolle spielt. So machen Sie nicht nur eine Pause von Arbeit und Alltag, sondern auch von der Tyrannei der Selbstbezogenheit", schreibt Friedman.
Sein Argument lautet allerdings nicht einfach: Sport ist gesund. Es geht um etwas anderes. Wer den ganzen Tag untätig ist, verbringt womöglich erstaunlich viel Zeit mit sich selbst. Und genau das ist psychologisch nicht immer angenehm.
Der eigentliche Gegner in Friedmans Text ist das sogenannte Mind-Wandering, das ziellose Kreisen der Gedanken. Dabei verbindet er Psychologie, Neurowissenschaft und Alltagserfahrung.
Jeder kennt das. Man liegt am Strand. Nach zwanzig Minuten denkt man an den Chef und die Kollegen. Dann an die Steuer. An den Gesundheitscheck. An die Kinder. Schließlich an die gesamte Weltlage.
Der Körper mag am Atlantikstrand liegen, der Kopf ist längst wieder im Büro.
Friedman will deshalb auf eine weitergehende Idee hinaus: Eigentliche Erholung könnte darin bestehen, für einige Stunden aus sich selbst herauszukommen.
Dafür kommen viele Tätigkeiten infrage: Radfahren, Bergsteigen, Segeln, Kajakfahren, Tauchen, Klettern, Gartenarbeit oder Kochen. Nicht der Sport ist entscheidend, sondern dass eine Tätigkeit unsere Aufmerksamkeit so sehr beansprucht, dass das ständige Nachdenken über uns selbst für eine Weile verstummt.
Das passt durchaus zu unserer Zeit. Selftracking, Selfcare, Selbstoptimierung und soziale Medien halten das eigene Ich permanent unter Beobachtung. Wir prüfen unsere Leistung, unsere Stimmung, unseren Schlaf, unsere Wirkung und unsere Identität. Selbst Entspannung wird dabei leicht zu einem weiteren Projekt der Selbstkontrolle.
Urlaub, so ließe sich Friedmans Gedanke zuspitzen, sollte deshalb auch Urlaub vom eigenen Ich sein.
Dabei stehen sich heute scheinbar zwei Urlaubsideale gegenüber. Auf der einen Seite Entschleunigung, Digital Detox, Ausschlafen und Nichtstun. Auf der anderen Seite Trailrunning, Bikepacking, Surfcamps, Pilgerwege und Alpenüberquerungen.
Doch womöglich suchen beide dasselbe: nicht Leistung, sondern Gegenwart. Einen Zustand, in dem man weder den vergangenen Arbeitswochen nachhängt noch die kommenden bereits vorwegnimmt.
Vielleicht erinnern wir uns an aktive Urlaube deshalb so lange, weil sie uns nicht nur aus dem Alltag herausführen, sondern für einige Stunden auch aus uns selbst.
URL dieses Artikels:
https://www.heise.de/-11372121
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach / iX / KI)
Die neue Assess-Erweiterung von Spec Kit 0.13 sortiert automatisiert Ideen, bevor sie in eine Spec eingehen. Außerdem beseitigt Spec Kit eine Reihe an Bugs.
Die neue Version 0.13 von Spec Kit, GitHubs Werkzeug für Spec-driven Development, enthält eine neue Extension zur Ideenbewertung sowie kleine Korrekturen für mehr Stabilität und weniger Fehler.
Die neue Extension [1] Idea Assessment Pipeline (assess) schaltet einen weiteren, optionalen Schritt vor den bestehenden Spec-driven-Workflow. Hier lassen sich Ideen rollenneutral testen und bewerten [2], bevor sie in eine Spec übergehen. Das erfolgt in fünf Schritten: Rohe Idee erfassen, Evidenz sammeln, das Problem schärfen, ein Konzept entwerfen und schließlich entscheiden: Go, klären oder Kill. Das positive Urteil überführt die Idee in eine Spec: /speckit.specify.
Bugfixes betreffen die Authentifizierung der Azure-DevOps-CLI: Erhielt das Tool eine nicht dekodierbare Antwort, führte das zum stillen Crash, statt ein erwartetes None auszugeben. Gefixt hat das Team auch unklare Fehlermeldungen bei nicht korrekten Bundle-Download-URLs. Spec Kit wirft jetzt einen klar benannten BundlerError aus. Außerdem ersetzt ein PresetValidationError den bisherigen unklareren ValueError bei ungültigen Katalog-URLs.
Als Tool für das Spec-driven Development plant und steuert Spec Kit die Arbeit von Coding-Agenten. Specs dienen dabei als Kern für Planung, Entwicklung, Testing und Doku. Die Specs liegen oft in Markdown vor und dienen als Single Source of Truth. Dabei arbeitet Spec Kit laut Projekt mit 35 Tools zusammen, darunter GitHub Copilot, Gemini oder Codex. Spec-driven Development [3] steigt in der Bedeutung bei Entwicklerinnen und Entwicklern, ein ähnliches Tool ist OpenSpec [4].
URL dieses Artikels:
https://www.heise.de/-11371623
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Wie Personen mit Autismusdiagnose ihre Fähigkeiten gut im Software-Testing einsetzen können, erklären Helmut Pichler und Markus Kalbhenn.
Menschen mit Autismusdiagnose, die im Wartezimmer spontan 48 Rechtschreibfehler in einer Illustrierten zählen, bevor das Gespräch überhaupt beginnt: Darüber sprechen Helmut Pichler und Markus Kalbhenn mit Richard Seidl. Es erklärt besser als jede Theorie, warum genau diese Fähigkeiten im Software-Testing so gut ankommen. Die drei sprechen darüber, wie das Ausbildungsprogramm TestingPRO [1], in dem Menschen aus dem neurodivergenten Spektrum als Softwaretester ausgebildet werden, aufgebaut ist und welche Anpassungen im Training wirklich den Unterschied machen. Sie besprechen auch, was Unternehmen konkret brauchen, damit die Zusammenarbeit funktioniert. Dabei geht es nicht nur um Pausen und ruhige Räume, sondern auch darum, wie klare Aufgabenstellungen und ein fester Tagesrhythmus aus einer unsicheren Situation ein gutes Arbeitsverhältnis machen können.
„Im Software-Testing, im Qualitätsmanagement sind diese Personen von ihrer Kapazität her, von ihren Potenzialen wie ein Ferrari.“ – Markus Kalbhenn
Helmut Pichler [3] ist ein echter „Vollblut‑Tester/-Berater/-Trainer“, der seit Jahren mit unglaublicher Leidenschaft die Softwaretest‑Community prägt und weltweit Standards mitgestaltet. Als Ehren-Präsident vom Austrian Testing Board und langjähriger Botschafter auf internationalen Konferenzen bringt er Menschen zusammen, inspiriert sie und zeigt, wie lebendig Qualitätssicherung sein kann. Mit seinem Know-how als Trainer, Berater und Co-Autor von „Agile Testing“ gilt er im deutschsprachigen Raum längst als eines der Urgesteine und bleibt trotzdem immer am Puls der Zeit. Eines seiner Herzensprojekte, das er federführend mit konzipiert, ist seit nun 10 Jahren TestingPRO.
Markus Kalbhenn [4] ist ein erfahrener Experte im Personalmanagement, der auf 30 Jahre Erfahrung im Recruiting- und Tech-Bereich zurückblickt. In der ETC – Enterprise Training Center GmbH hat er den Bereich Talent Services mit aufgebaut und setzt dort neue Impulse in der IT-Personalvermittlung. Sein Fokus liegt auf der Entwicklung innovativer Recruiting-Methoden, die über konventionelle Ansätze hinausgehen, um dem Fachkräftemangel in der IT-Branche entgegenzuwirken. Besonders hervorzuheben ist sein Engagement für die IT-Ausbildungsprogramme TestingPro und INCLUSIVE-IT, die Menschen mit Behinderungen den Zugang zu IT-Karrieren ermöglichen. Als ausgebildeter Pädagoge und zertifizierter CSR-Berater verbindet er soziale Verantwortung mit wirtschaftlicher Effizienz bei der Besetzung technischer Rollen.
Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.
Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar [5].
URL dieses Artikels:
https://www.heise.de/-11371595
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Maika Möbus / KI / iX)
So funktionieren Passkeys: Der erste Teil der Praxis-Serie für Entwickler zeigt im Detail die Architektur, die auf FIDO2 und WebAuthn aufbaut.
Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.
Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.
Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.
Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.
FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) [1] und Client to Authenticator Protocol 2 (CTAP2) [2]. WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance [3] und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.
Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.
Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.
Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.
Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.
Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.
Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.
Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.
Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys [4] gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.
Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.
(Bild: Yubinerd123 [5], CC BY-SA 4.0 [6], via Wikimedia Commons)
Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.
In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:
FreshRSS {
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
}
}Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators
"platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. "residentKey": "required" erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.
Bisher wurde hier WebAuthn als die Schnittstelle zwischen Webanwendung und Browser betrachtet. Doch wie kommuniziert der Browser eigentlich mit dem Authenticator? Dafür ist CTAP2 zuständig – und auch wenn Entwicklerinnen und Entwickler mit CTAP2 in der Regel nicht direkt in Berührung kommen, ist es sinnvoll, das Protokoll grob zu verstehen.
CTAP2 definiert das Nachrichtenformat und den Befehlssatz für diese Kommunikation. Nachrichten sind CBOR-kodiert (Concise Binary Object Representation, RFC 8949 [7]). Das binäre Format CBOR ist kompakter als JSON und eignet sich besonders für ressourcenbeschränkte Hardware wie einen USB-Sicherheitsschlüssel. Das Protokoll ist transport-agnostisch: Ein Windows-Browser kann genauso mit einem YubiKey über USB kommunizieren wie ein macOS-Browser mit einem NFC-Token, weil CTAP2 den Transport von der eigentlichen Nachrichtensemantik trennt.
Besonders hilfreich ist die direkte Zuordnung zwischen den CTAP2-Kommandos und den WebAuthn-Ceremonies: authenticatorMakeCredential entspricht der Registration – der Authenticator erzeugt ein neues Schlüsselpaar und gibt den Public Key zurück. authenticatorGetAssertion entspricht der Authentication – der Authenticator signiert eine Challenge mit dem gespeicherten Private Key. Die WebAuthn-API auf Browserebene ruft intern genau diese Kommandos auf. Mit anderen Worten: navigator.credentials.create() ist aus Sicht des Authenticators ein authenticatorMakeCredential, und navigator.credentials.get() ist ein authenticatorGetAssertion. Diese Zuordnung ist das konzeptuelle Bindeglied zwischen der JavaScript-API und dem Low-Level-Protokoll.
| Transport | Beschreibung | Plattformunterstützung |
| USB HID | kabelgebunden, hohe Zuverlässigkeit | Windows, macOS, Linux, Android |
| NFC | kontaktlos, kurze Reichweite | mobile Geräte, NFC-fähige PCs |
| BLE |
Bluetooth Low Energy (drahtlos, energiesparend, mittlere Reichweite) |
Mobile- und Desktop-Plattformen |
| Internal | plattforminterner Kanal (Platform Authenticator) | alle modernen Plattformen |
| Hybrid | QR-Code + BLE-Proximity (früher „caBLE“) | iOS 16+, Android 9+, moderne Desktopbrowser |
Tabelle 1: CTAP2-Transportmechanismen und deren Plattformunterstützung
Besonders erwähnenswert ist der Hybrid Transport, früher unter dem Namen caBLE bekannt. Er ermöglicht es, ein Smartphone als Roaming Authenticator für einen Desktopbrowser zu verwenden, der selbst keinen Platform Authenticator besitzt. Der Ablauf ist einfach: Der Desktop zeigt einen QR-Code an, das Smartphone scannt ihn, und die eigentliche Assertion wird anschließend über eine verschlüsselte Bluetooth-Verbindung übertragen. Aus Entwicklersicht ist dieser Transport vollständig transparent. Er läuft im Client ab und hat keinerlei Einfluss auf die WebAuthn-API oder die serverseitige Validierungslogik.
WebAuthn ist die API, mit der Entwicklerinnen und Entwickler direkt arbeiten. Sie besteht aus den zwei bereits erwähnten Methoden: navigator.credentials.create() für die Registration und navigator.credentials.get() für die Authentication. Beide geben ein PublicKeyCredential-Objekt zurück. Was sich unterscheidet, ist die response-Property darin. Bei der Registration enthält sie eine AuthenticatorAttestationResponse:
// Registration
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
}) as PublicKeyCredential;
const attestationResponse =
credential.response as AuthenticatorAttestationResponse;
// attestationResponse.clientDataJSON – ArrayBuffer
// attestationResponse.attestationObject – ArrayBuffer (CBOR-kodiert)
// attestationResponse.getPublicKey() – ArrayBuffer (DER-Format, convenience)Listing 2: create()-Aufruf und Zugriff auf die AuthenticatorAttestationResponse
Bei der Authentication enthält sie eine AuthenticatorAssertionResponse:
// Authentication
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
}) as PublicKeyCredential;
const assertionResponse =
assertion.response as AuthenticatorAssertionResponse;
// assertionResponse.clientDataJSON – ArrayBuffer
// assertionResponse.authenticatorData – ArrayBuffer
// assertionResponse.signature – ArrayBuffer
// assertionResponse.userHandle – ArrayBuffer | nullListing 3: get()-Aufruf und Zugriff auf die AuthenticatorAssertionResponse
Beide Responses teilen sich ein gemeinsames Feld: clientDataJSON. Es ist ein ArrayBuffer, der ein JSON-Objekt enthält – erzeugt vom Browser, nicht vom Authenticator. Es enthält type ("webauthn.create" oder "webauthn.get"), challenge als Base64url-String, origin und crossOrigin. Der entscheidende Punkt ist, dass origin und challenge Teil der späteren Signatur werden. Dadurch ist kryptografisch sichergestellt, dass die Antwort weder für eine andere Origin noch als Replay einer früheren Anfrage gültig ist. Das sind zwei Angriffsvektoren, gegen die klassische Passwörter strukturell keine Antwort haben.
Bei der Registration kommt zu clientDataJSON noch das attestationObject hinzu. Es ist CBOR-kodiert und enthält drei Felder: fmt (das Attestation-Format, zum Beispiel "packed", "tpm" oder "none"), attStmt (die formatspezifische Attestation-Aussage) und authData, die zentrale Datenstruktur, auf die der nächste Abschnitt eingeht. Bei der Authentication Response entfällt der Attestation-Wrapper. Dort steht authenticatorData direkt im Response-Objekt, zusammen mit signature und optional userHandle.
Es gibt dabei einige Fehlerszenarien, die in der Praxis regelmäßig auftauchen: Ein NotAllowedError erscheint, wenn der Nutzer die Anfrage abgelehnt hat oder das Timeout abgelaufen ist. Ein SecurityError signalisiert, dass die rpId nicht zur aktuellen Origin passt – ein häufiger Konfigurationsfehler in Entwicklungsumgebungen, wenn man zwischen localhost und einer lokalen Domain wechselt. Und ein AbortError tritt auf, wenn die Anfrage programmatisch über einen AbortController abgebrochen wurde. Das ist relevant, wenn Conditional UI und ein manuell ausgelöster Login-Flow gleichzeitig im Spiel sind und koordiniert werden müssen.
Wer verstehen will, was der Server bei der Validierung tatsächlich prüft, muss die authData kennen. Sie ist die Datenstruktur, die sich durch beide Ceremonies zieht – bei der Registration steckt sie im attestationObject, bei der Authentication erscheint sie direkt als authenticatorData. Ihr Layout ist in §6.1 der W3C-WebAuthn-Level-2-Spezifikation [8] exakt definiert: ein Byte-Array, aufgebaut aus fest definierten Feldern in einer fixen Reihenfolge.
| Offset | Länge | Feld | Beschreibung |
| 0 | 32 Bytes | rpIdHash | SHA-256-Hash der rpId |
| 32 | 1 Byte | flags | Bit-Feld mit Statusinformationen |
| 33 | 4 Bytes | signCount | Big Endian, Zähler für Replay-Schutz |
| 37 | variabel | attestedCredentialData | nur bei Registration, wenn Attested Credential Data Flag gesetzt |
| variabel | variabel | extensions | optional, nur wenn Extension Data Flag gesetzt |
Tabelle 2: Byte-Layout der authData (§6.1 WebAuthn Level 2)
Die ersten 32 Bytes sind der rpIdHash – der SHA-256-Hash der rpId. Das ist das Erste, was der Server prüfen muss: Stimmt dieser Hash mit dem Hash seiner eigenen rpId überein? Sofern er nicht stimmt, wurde die Antwort für eine andere Relying Party erzeugt und muss abgelehnt werden, ohne Ausnahme und ohne Fallback.
Byte 32 enthält das flags-Byte. Dieses Byte steuert den Großteil der Validierungslogik auf Serverseite. Es ist ein Bit-Feld – jedes Bit hat eine eigene Bedeutung. Das UP-Flag (Bit 0, User Presence) zeigt an, dass der Nutzer den Authenticator aktiv bedient hat – den YubiKey-Knopf gedrückt, das Gerät entsperrt, eine Geste ausgeführt. Es muss laut Spezifikation immer gesetzt sein; fehlt es, muss die RP die Antwort ablehnen. Das UV-Flag (Bit 2, User Verification) geht einen Schritt weiter: Es zeigt an, dass der Nutzer lokal verifiziert wurde, etwa durch Biometrie oder PIN. Server, die userVerification: "required" konfiguriert haben, müssen dieses Bit zwingend prüfen.
Für Synced Passkeys sind die beiden Bits BE (Bit 3, Backup Eligibility) und BS (Bit 4, Backup State) besonders relevant. BE zeigt an, ob das Credential überhaupt sync-fähig ist – also ob es sich um ein Multi-Device Credential handelt. BS zeigt an, ob es zum Zeitpunkt der Anfrage tatsächlich aktiv synchronisiert ist. Die Kombination BE=1, BS=1 bedeutet: aktiv synchronisiert. BE=1, BS=0 heißt: sync-fähig, aber aktuell nicht in der Cloud gesichert. BE=0 wiederum garantiert, dass das Credential Device-bound ist und das Gerät nie verlassen hat. Diese Unterscheidung ist für Hochsicherheitsszenarien relevant, in denen Synced Credentials bewusst ausgeschlossen werden sollen. Schließlich steuert das AT-Flag (Bit 6), ob attestedCredentialData in der authData vorhanden ist. Es wird bei der Registration gesetzt, nicht bei der Authentication.
// flags-Byte aus authData auslesen (authData ist ein Uint8Array)
function parseAuthDataFlags(authData) {
const flagsByte = authData[32];
return {
up: !!(flagsByte & 0x01), // Bit 0 – User Presence
uv: !!(flagsByte & 0x04), // Bit 2 – User Verification
be: !!(flagsByte & 0x08), // Bit 3 – Backup Eligibility
bs: !!(flagsByte & 0x10), // Bit 4 – Backup State
at: !!(flagsByte & 0x40), // Bit 6 – Attested Credential Data
ed: !!(flagsByte & 0x80), // Bit 7 – Extension Data
};
}Listing 4: flags-Byte aus authData auslesen, in JavaScript
Die Bytes 33 bis 36 enthalten den signCount – einen Big-Endian-Zähler, der bei jedem Authentifizierungsvorgang höher sein muss als der zuletzt vom Server gespeicherte Wert. Die Idee dahinter ist eine Art Klon-Detektion: Wäre ein privater Schlüssel kopiert worden, wäre der Counter irgendwann nicht mehr korrekt. Bei Synced Passkeys ist diese Logik allerdings kompromittiert. Da etwa ein iCloud-Passkey parallel auf iPhone, iPad und MacBook genutzt werden kann, ist ein konsistenter, monotoner Counter schlicht nicht gewährleistet. Viele Implementierungen setzen signCount deshalb dauerhaft auf 0. Server müssen das explizit behandeln. Wie genau, wird Teil 2 dieser Artikelserie klären.
Das letzte relevante Feld ist attestedCredentialData. Es ist nur bei der Registration vorhanden, wenn das Attested Credential Data Flag gesetzt ist. Es enthält drei Bestandteile, die für die serverseitige Speicherung direkt relevant sind. Die aaguid (16 Bytes) identifiziert das Authenticator-Modell, nicht die individuelle Instanz. Über den FIDO Metadata Service (MDS) kann die RP damit prüfen, welches Gerät oder welche Software das Credential erzeugt hat. Das ist relevant für Szenarien, in denen nur bestimmte Hardware akzeptiert werden soll. Die credentialId ist eine vom Authenticator erzeugte eindeutige ID, die der Server speichert und bei zukünftigen Authentifizierungen in allowCredentials übergibt. Und der credentialPublicKey enthält schließlich den Public Key im Format CBOR Object Signing and Encryption (COSE) (RFC 8152), CBOR-kodiert. Der alg-Parameter gibt den Algorithmus an: -7 steht für ES256 (Elliptic Curve Digital Signature Algorithm (ECDSA) über P-256 mit SHA-256), -257 für RS256, -8 für EdDSA. Dieser Schlüssel ist der einzige Wert, den die RP dauerhaft speichern muss. Alle zukünftigen Assertion-Signaturen werden gegen ihn validiert.
Die Architektur von FIDO2 ist strukturell überschaubar: drei Akteure, zwei API-Aufrufe, eine zentrale Datenstruktur. Relying Party, WebAuthn Client und Authenticator kommunizieren über klar definierte Schnittstellen: WebAuthn nach oben zur Webanwendung, CTAP2 nach unten zum Authenticator. Die authData zieht sich als gemeinsamer Nenner durch beide Ceremonies: Bei der Registration steckt sie im attestationObject, bei der Authentication ist sie direkt als authenticatorData enthalten. Wer das Byte-Layout kennt und weiß, welche Bits welche Validierungen auslösen, kann die Serverlogik direkt einordnen.
Der nächste Teil geht die Registration Ceremony nach §7.1 [9] Schritt für Schritt durch: Er zeigt, wie PublicKeyCredentialCreationOptions aufgebaut ist, wie das attestationObject validiert wird und welche Felder der Server in welcher Reihenfolge prüfen muss. Anschließend folgt die Authentication Ceremony nach §7.2 [10]: PublicKeyCredentialRequestOptions, Signaturvalidierung über authData || SHA-256(clientDataJSON) und der Umgang mit signCount bei Synced Passkeys.
URL dieses Artikels:
https://www.heise.de/-11364345
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Unser Deal-Qualitätsversprechen: Gute, ehrliche und unabhängig recherchierte Angebote. Mehr Infos
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Bei Amazon läuft aktuell ein großer Sale um Balkonkraftwerke. Mehrere Sets mit einer Modulleistung zwischen 900 und 2.000 Watt sind dort befristet reduziert. Zur Verfügung gestellt werden die Deals von den deutschen Händlern Solakon und Solarway. Beide offerieren die Sets mit Gratisversand.
Die Aktion stößt offenkundig auf Interesse, denn der Bestseller Nr. 1
Trotzdem gibt es noch mehrere interessante Balkonkraftwerke zum Aktionspreis.
400-mal im letzten Monat verkauft hat sich das Onlite aus dem Hause Solakon. Es bietet zwei bifaziale Module zu 450 W, konkret die LP182M54NB. Das 900-Watt-Balkonkraftwerk verfügt über einen Markstek-Wechselrichter, der im Rahmen der Bagatellgrenze auf 800 Watt drosselt. Zum Lieferumfang gehören ein fünf Meter langes Anschlusskabel, zwei 2 Meter lange Solarverlängerungskabel und eine Wechselrichterhalterung. Modulhalterungen sind separat erhältlich.
Bis einschließlich Sonntag kostet das Balkonkraftwerk bei Amazon wieder nur 244,95 Euro
Solakon 900W Balkonkraftwerk - Balkonkraftwerk 800W komplett Steckdose - neuester 800 Watt Wechselrichter - Solaranlage Komplettset - 450W bifaziale Solarmodule inkl Zubehör - 5m Kabel, Ohne Halterung
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Etwas mehr Modulleistung bietet Solakons Onbasic. Dazu stellt es zwei 500-Wp-Module von Markenhersteller JA Solar zur Verfügung. Es handelt sich laut Hersteller um die JAM60D41. Zubehör und Wechselrichter entsprechen dem erwähnten Onlite. Erwähnenswert ist sicherlich noch, dass Solakon eine eigene App nutzt. Die Server liegen in Deutschland.
Bis maximal Sonntag liegt der Preis bei 269,98 Euro
Solakon 1000W Balkonkraftwerk - Balkonkraftwerk 800W komplett Steckdose - neuester 800 Watt Wechselrichter - Solaranlage Komplettset, 500W bifaziale Solarmodule inkl Zubehör - 5m Kabel, Ohne Halterung
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Interessant ist das 2.000-Watt-Balkonkraftwerk der Marke Solarway. Dieses setzt auf vier bifaziale Full-Black-Module an einem 2.000-Watt-Wechselrichter von Envertech. Hier bedarf es also einer Genehmigung und die Installation muss durch eine Fachkraft erfolgen. Anschlusskabel und Solarverlängerungskabel gehören zum Lieferumfang.
Laut Preistracker zahlte man im Dreimonatsmittel 599,99 Euro auf Amazon. Bis einschließlich zum 2. August – oder solange die Vorräte reichen – stehen 559,99 Euro
Solarway® Balkonkraftwerk 2000W komplett Steckdose - neuester 2000W Wechselrichter - Solaranlage Komplettset - 500W Solarmodule & Envertech & Zubehör
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Eine weitere Option ist das Solakon Onpower mit 2.000 Watt. Das JA Solar JAM60D41 liegt gleich viermal bei. Auch die erwähnten Anschluss- und Verlängerungskabel sind an Bord. Der Marstek-Wechselrichter drosselt werksseitig auf 800 Watt.
Solakon Balkonkraftwerk 2000W komplett Steckdose - Balkonkraftwerk 2000 Watt neuester Wechselrichter 800W - Solaranlage Komplettset mit 4x500W Solarpanel/Solar Panels mit 5m Kabel
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Nicht das richtige Set dabei? Weitere befristet reduzierte Balkonkraftwerke der beiden Händler findet man bei Amazon in der Übersicht
Unser Deal-Qualitätsversprechen: Gute, ehrliche und unabhängig recherchierte Angebote. Mehr Infos
Mit nur einem Monitor zu arbeiten, ist zwar möglich, aber schön ist anders. Das gilt besonders für Schichten im Zug oder Café, bei denen man auf einen Laptopbildschirm beschränkt ist. Portable Monitore lösen das Problem, indem sie den Komfort vom heimischen Dual-Monitor-Setup auch unterwegs bieten – und das zu immer attraktiveren Preisen. Ein unter Amazon-Kunden beliebtes Modell, der 16,1 Zoll große Arzopa Z1C, ist aktuell wieder günstiger bei dem Onlinehändler verfügbar. Im befristeten Angebot zahlt man unter 90 Euro.
Der Arzopa Z1C bietet eine vergleichbare Grundausstattung wie herkömmliche Office-Monitore. Sein 16,1 Zoll großer Bildschirm stellt Inhalte in Full-HD-Auflösung, mit 60 Hz Bildwiederholrate und einem Kontrastverhältnis von 1.000:1. Wo viele Bildschirme im unteren Preissegment mit VA-Panels kommen, bietet Arzopas Portable Monitor ein IPS-Panel. Die Vorteile: eine genauere Farbwiedergabe und größere Betrachtungswinkel. Sein 3-in-1-Anzeige-Modus erlaubt es, den Bildschirm vom Quellgerät zu duplizieren, erweitern oder als Zweitbildschirm zu dienen. Für lange Sitzungen kann ein augenschonender Blaulichtfilter zugeschaltet werden.
Ob mit Laptops, PCs, Tablets oder Konsolen: Der Arzopa Z1C ist dank USB-C- und Mini-HDMI-Anschlüssen mit zahlreichen Geräten kompatibel. Er eignet sich also nicht nur zum Tabellenabarbeiten, sondern auch zum Spielen nach der Schicht. Die nötigen Kabel sind im Lieferumfang enthalten. Wer dabei auf Kopfhörer verzichten möchte, kann auf das eingebaute Lautsprecherpaar zurückgreifen.
Wie man es von einem Portable Monitor erwartet, hat der Arzopa Z1C einen schlanken Formfaktor. Laut Hersteller ist er weniger als 1 cm dick und bringt nur knapp 780 g auf die Waage. Das Gehäuse besteht aus CNC-eloxiertem Metall, so dass man sich beim Transport nicht um Kratzer oder sonstige Schäden sorgen muss. Auf der Rückseite ist eine stabile und rutschfeste Einzelstangenhalterung verbaut, die sich für einen komfortablen Blickwinkel um bis zu 80 Grad verstellen lässt.
Amazon verkauft den Arzopa Z1C
ARZOPA 16.1" Portable Monitor, 1920×1080 FHD IPS 100% sRGB Tragbarer Monitor für Laptop mit Einzelstange, Unterstützt HDMI/Typ-C/USB-C, Augenschutz-Gaming-Bildschirm für Laptop/PC/Mac/PS3/4/5/Xbox
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Unser Deal-Qualitätsversprechen: Gute, ehrliche und unabhängig recherchierte Angebote. Mehr Infos
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Vor der Anschaffung neuer Kopfhörer sollten Käufer sich im Klaren sein, welche Art denn die am besten geeignete ist, da alle ihre Eigenheiten haben. Wer sich für Over-Ear-Kopfhörer entscheidet, hat in der Regel einen noch satteren Sound und eine bessere Geräuschunterdrückung. Die kleinen In-Ear-Kopfhörer auf der anderen Seite sind dafür besonders leicht zu transportieren, können bequem beim Sport getragen werden und lassen sich in der Hosentasche verstauen. Bei Amazon sind die Soundcore Liberty 4 Pro von Anker derzeit zum bisher günstigsten Preis erhältlich.
Die In-Ear-Kopfhörer Anker Soundcore Liberty 4 Pro vereinen ein gutes Soundprofil mit einem effektiven Schallschutz von außen. Mit einem 10,5-mm-Treiber sowie einem titanbeschichteten Hochtöner bieten sie ein ausgewogenes Klangerlebnis und Hi-Res-Sound mit vielen Details. Für ein störungsfreies Hörerlebnis sorgen sechs Geräuschsensoren sowie ein Luftdrucksensor, welche Außengeräusche aus allen Richtungen erfassen können. Die adaptive Geräuschunterdrückung erfolgt alle 0,3 Sekunden in Echtzeit. Alternativ steht auch ein Transparenzmodus bereit.
Die Anker Soundcore Liberty 4 Pro werden in einem Smart Case mit Display und Touch-Leiste ausgeliefert. Dort können Nutzer das Noise Cancelling einstellen und die In-Ear-Kopfhörer aufladen. Bei voller Ladung sollen die Kopfhörer zehn Stunden am Stück durchhalten, mit dem Ladecase sogar 40 Stunden. Sind die Akkus leer, sollen fünf Minuten Ladung für vier Stunden Musikgenuss ausreichen.
Wer mit den Anker Soundcore Liberty 4 Pro
soundcore Liberty 4 Pro von Anker, Kabellose Noise Cancelling Kopfhörer, Earbuds mit 7 Sensoren, ANC in Echtzeit, 2× schneller Laden, Hi-Fi-Musik Studio-Niveau, klare Anrufe mit 6 Mikros + KI
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Aktuell werden die Soundcore Liberty 4 Pro
soundcore Liberty 4 Pro von Anker, Kabellose Noise Cancelling Kopfhörer, Earbuds mit 7 Sensoren, ANC in Echtzeit, 2× schneller Laden, Hi-Fi-Musik Studio-Niveau, klare Anrufe mit 6 Mikros + KI
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Weitere Produkte des Herstellers finden sich im Soundcore-Store bei Amazon
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
(Bild: II.studio / Shutterstock.com)
Die Finanzaufsicht BaFin hat TeamViewer ein Bußgeld von 240.000 Euro aufgebrummt. Grund ist ein Cyberangriff aus dem Jahr 2024.
Die Finanzaufsichtsbehörde BaFin hat gegen das Unternehmen TeamViewer ein Bußgeld in Höhe von 240.000 Euro verhängt. Auslöser ist ein Cyberangriff auf das Unternehmen, der Mitte 2024 stattgefunden hat.
Das teilt die BaFin in einer Veröffentlichung vom Montag [1] dieser Woche mit. Demnach seien Unternehmen mit Sitz in Deutschland wie TeamViewer, die etwa Aktien und ähnliche Finanzinstrumente nutzen, von der Ad-hoc-Publizitätspflicht betroffen. Das bedeutet, dass sie Insiderinformationen sofort veröffentlichen müssen. Die BaFin erläutert dazu: „Unter Insiderinformationen versteht man nicht öffentlich bekannte, präzise Informationen, die direkt oder indirekt einen oder mehrere Emittenten oder ein oder mehrere Finanzinstrumente betreffen und die, wenn sie öffentlich bekannt würden, geeignet wären, den Kurs dieser Finanzinstrumente oder den Kurs damit verbundener derivativer Finanzinstrumente erheblich zu beeinflussen.“ Etwas einfacher formuliert, müssen börsennotierte Unternehmen Ereignisse umgehend melden, die Einfluss auf die Aktienkurse haben können.
Die BaFin bemängelt, dass der Cyberangriff auf TeamViewer eine Insiderinformation darstellt – insbesondere, da TeamViewer ein Softwareunternehmen ist. Solche Informationen müssen gemäß Marktmissbrauchsverordnung (Market Abuse Regulation, MAR) sofort veröffentlicht werden. Das soll verhindern, dass sich Insider aus dem Wissensvorsprung mittels Wertpapierhandel Vorteile verschaffen und Kapital schlagen. Anleger sollen dadurch „bei ihren Investitionsentscheidungen nicht irregeführt werden“, führt die BaFin weiter aus.
Ende Juni 2024 hatte TeamViewer bestätigt [2], Auffälligkeiten in den internen IT-Umgebungen festgestellt zu haben. Auf der Webseite erfolgte eine Mitteilung, dass TeamViewer unverzüglich mit Untersuchungen und Sicherungsmaßnahmen begonnen habe. Erste Details nannte das Unternehmen dort ebenfalls. So habe es keine Anzeichen dafür gegeben, dass die Produktumgebung, die komplett unabhängig von der internen TeamViewer-IT-Umgebung sei, oder Kundendaten betroffen sein könnten.
Der BaFin genügt die Meldung auf der TeamViewer-Webseite nicht. Ad-hoc-Meldungen müssen über [3] ein elektronisches Informationssystem an Medien und an die Bafin verteilt sowie auf der Unternehmenswebseite veröffentlicht werden, was üblicherweise spezialisierte, beauftragte Ad-hoc-Dienstleister erledigen. „Wenn ein Unternehmen eine Insiderinformation nicht unverzüglich veröffentlicht, verstößt es gegen die MAR, konkret gegen Artikel 17 Absatz 1 Unterabsatz 1. Die Bafin kann dies mit einer Geldbuße ahnden.“ Gegen das Bußgeld von 240.000 Euro könne TeamViewer noch Einspruch einlegen, teilt die BaFin weiter mit [4].
URL dieses Artikels:
https://www.heise.de/-11371639
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Maika Möbus / KI / iX)
So funktionieren Passkeys: Der erste Teil der Praxis-Serie für Entwickler zeigt im Detail die Architektur, die auf FIDO2 und WebAuthn aufbaut.
Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.
Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.
Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.
Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.
FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) [1] und Client to Authenticator Protocol 2 (CTAP2) [2]. WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance [3] und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.
Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.
Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.
Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.
Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.
Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.
Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.
Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.
Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys [4] gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.
Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.
(Bild: Yubinerd123 [5], CC BY-SA 4.0 [6], via Wikimedia Commons)
Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.
In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:
{
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
}
}Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators
"platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. "residentKey": "required" erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.
Bisher wurde hier WebAuthn als die Schnittstelle zwischen Webanwendung und Browser betrachtet. Doch wie kommuniziert der Browser eigentlich mit dem Authenticator? Dafür ist CTAP2 zuständig – und auch wenn Entwicklerinnen und Entwickler mit CTAP2 in der Regel nicht direkt in Berührung kommen, ist es sinnvoll, das Protokoll grob zu verstehen.
CTAP2 definiert das Nachrichtenformat und den Befehlssatz für diese Kommunikation. Nachrichten sind CBOR-kodiert (Concise Binary Object Representation, RFC 8949 [7]). Das binäre Format CBOR ist kompakter als JSON und eignet sich besonders für ressourcenbeschränkte Hardware wie einen USB-Sicherheitsschlüssel. Das Protokoll ist transport-agnostisch: Ein Windows-Browser kann genauso mit einem YubiKey über USB kommunizieren wie ein macOS-Browser mit einem NFC-Token, weil CTAP2 den Transport von der eigentlichen Nachrichtensemantik trennt.
Besonders hilfreich ist die direkte Zuordnung zwischen den CTAP2-Kommandos und den WebAuthn-Ceremonies: authenticatorMakeCredential entspricht der Registration – der Authenticator erzeugt ein neues Schlüsselpaar und gibt den Public Key zurück. authenticatorGetAssertion entspricht der Authentication – der Authenticator signiert eine Challenge mit dem gespeicherten Private Key. Die WebAuthn-API auf Browserebene ruft intern genau diese Kommandos auf. Mit anderen Worten: navigator.credentials.create() ist aus Sicht des Authenticators ein authenticatorMakeCredential, und navigator.credentials.get() ist ein authenticatorGetAssertion. Diese Zuordnung ist das konzeptuelle Bindeglied zwischen der JavaScript-API und dem Low-Level-Protokoll.
| Transport | Beschreibung | Plattformunterstützung |
| USB HID | kabelgebunden, hohe Zuverlässigkeit | Windows, macOS, Linux, Android |
| NFC | kontaktlos, kurze Reichweite | mobile Geräte, NFC-fähige PCs |
| BLE |
Bluetooth Low Energy (drahtlos, energiesparend, mittlere Reichweite) |
Mobile- und Desktop-Plattformen |
| Internal | plattforminterner Kanal (Platform Authenticator) | alle modernen Plattformen |
| Hybrid | QR-Code + BLE-Proximity (früher „caBLE“) | iOS 16+, Android 9+, moderne Desktopbrowser |
Tabelle 1: CTAP2-Transportmechanismen und deren Plattformunterstützung
Besonders erwähnenswert ist der Hybrid Transport, früher unter dem Namen caBLE bekannt. Er ermöglicht es, ein Smartphone als Roaming Authenticator für einen Desktopbrowser zu verwenden, der selbst keinen Platform Authenticator besitzt. Der Ablauf ist einfach: Der Desktop zeigt einen QR-Code an, das Smartphone scannt ihn, und die eigentliche Assertion wird anschließend über eine verschlüsselte Bluetooth-Verbindung übertragen. Aus Entwicklersicht ist dieser Transport vollständig transparent. Er läuft im Client ab und hat keinerlei Einfluss auf die WebAuthn-API oder die serverseitige Validierungslogik.
WebAuthn ist die API, mit der Entwicklerinnen und Entwickler direkt arbeiten. Sie besteht aus den zwei bereits erwähnten Methoden: navigator.credentials.create() für die Registration und navigator.credentials.get() für die Authentication. Beide geben ein PublicKeyCredential-Objekt zurück. Was sich unterscheidet, ist die response-Property darin. Bei der Registration enthält sie eine AuthenticatorAttestationResponse:
// Registration
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
}) as PublicKeyCredential;
const attestationResponse =
credential.response as AuthenticatorAttestationResponse;
// attestationResponse.clientDataJSON – ArrayBuffer
// attestationResponse.attestationObject – ArrayBuffer (CBOR-kodiert)
// attestationResponse.getPublicKey() – ArrayBuffer (DER-Format, convenience)Listing 2: create()-Aufruf und Zugriff auf die AuthenticatorAttestationResponse
Bei der Authentication enthält sie eine AuthenticatorAssertionResponse:
// Authentication
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
}) as PublicKeyCredential;
const assertionResponse =
assertion.response as AuthenticatorAssertionResponse;
// assertionResponse.clientDataJSON – ArrayBuffer
// assertionResponse.authenticatorData – ArrayBuffer
// assertionResponse.signature – ArrayBuffer
// assertionResponse.userHandle – ArrayBuffer | nullListing 3: get()-Aufruf und Zugriff auf die AuthenticatorAssertionResponse
Beide Responses teilen sich ein gemeinsames Feld: clientDataJSON. Es ist ein ArrayBuffer, der ein JSON-Objekt enthält – erzeugt vom Browser, nicht vom Authenticator. Es enthält type ("webauthn.create" oder "webauthn.get"), challenge als Base64url-String, origin und crossOrigin. Der entscheidende Punkt ist, dass origin und challenge Teil der späteren Signatur werden. Dadurch ist kryptografisch sichergestellt, dass die Antwort weder für eine andere Origin noch als Replay einer früheren Anfrage gültig ist. Das sind zwei Angriffsvektoren, gegen die klassische Passwörter strukturell keine Antwort haben.
Bei der Registration kommt zu clientDataJSON noch das attestationObject hinzu. Es ist CBOR-kodiert und enthält drei Felder: fmt (das Attestation-Format, zum Beispiel "packed", "tpm" oder "none"), attStmt (die formatspezifische Attestation-Aussage) und authData, die zentrale Datenstruktur, auf die der nächste Abschnitt eingeht. Bei der Authentication Response entfällt der Attestation-Wrapper. Dort steht authenticatorData direkt im Response-Objekt, zusammen mit signature und optional userHandle.
Es gibt dabei einige Fehlerszenarien, die in der Praxis regelmäßig auftauchen: Ein NotAllowedError erscheint, wenn der Nutzer die Anfrage abgelehnt hat oder das Timeout abgelaufen ist. Ein SecurityError signalisiert, dass die rpId nicht zur aktuellen Origin passt – ein häufiger Konfigurationsfehler in Entwicklungsumgebungen, wenn man zwischen localhost und einer lokalen Domain wechselt. Und ein AbortError tritt auf, wenn die Anfrage programmatisch über einen AbortController abgebrochen wurde. Das ist relevant, wenn Conditional UI und ein manuell ausgelöster Login-Flow gleichzeitig im Spiel sind und koordiniert werden müssen.
Wer verstehen will, was der Server bei der Validierung tatsächlich prüft, muss die authData kennen. Sie ist die Datenstruktur, die sich durch beide Ceremonies zieht – bei der Registration steckt sie im attestationObject, bei der Authentication erscheint sie direkt als authenticatorData. Ihr Layout ist in §6.1 der W3C-WebAuthn-Level-2-Spezifikation [8] exakt definiert: ein Byte-Array, aufgebaut aus fest definierten Feldern in einer fixen Reihenfolge.
| Offset | Länge | Feld | Beschreibung |
| 0 | 32 Bytes | rpIdHash | SHA-256-Hash der rpId |
| 32 | 1 Byte | flags | Bit-Feld mit Statusinformationen |
| 33 | 4 Bytes | signCount | Big Endian, Zähler für Replay-Schutz |
| 37 | variabel | attestedCredentialData | nur bei Registration, wenn Attested Credential Data Flag gesetzt |
| variabel | variabel | extensions | optional, nur wenn Extension Data Flag gesetzt |
Tabelle 2: Byte-Layout der authData (§6.1 WebAuthn Level 2)
Die ersten 32 Bytes sind der rpIdHash – der SHA-256-Hash der rpId. Das ist das Erste, was der Server prüfen muss: Stimmt dieser Hash mit dem Hash seiner eigenen rpId überein? Sofern er nicht stimmt, wurde die Antwort für eine andere Relying Party erzeugt und muss abgelehnt werden, ohne Ausnahme und ohne Fallback.
Byte 32 enthält das flags-Byte. Dieses Byte steuert den Großteil der Validierungslogik auf Serverseite. Es ist ein Bit-Feld – jedes Bit hat eine eigene Bedeutung. Das UP-Flag (Bit 0, User Presence) zeigt an, dass der Nutzer den Authenticator aktiv bedient hat – den YubiKey-Knopf gedrückt, das Gerät entsperrt, eine Geste ausgeführt. Es muss laut Spezifikation immer gesetzt sein; fehlt es, muss die RP die Antwort ablehnen. Das UV-Flag (Bit 2, User Verification) geht einen Schritt weiter: Es zeigt an, dass der Nutzer lokal verifiziert wurde, etwa durch Biometrie oder PIN. Server, die userVerification: "required" konfiguriert haben, müssen dieses Bit zwingend prüfen.
Für Synced Passkeys sind die beiden Bits BE (Bit 3, Backup Eligibility) und BS (Bit 4, Backup State) besonders relevant. BE zeigt an, ob das Credential überhaupt sync-fähig ist – also ob es sich um ein Multi-Device Credential handelt. BS zeigt an, ob es zum Zeitpunkt der Anfrage tatsächlich aktiv synchronisiert ist. Die Kombination BE=1, BS=1 bedeutet: aktiv synchronisiert. BE=1, BS=0 heißt: sync-fähig, aber aktuell nicht in der Cloud gesichert. BE=0 wiederum garantiert, dass das Credential Device-bound ist und das Gerät nie verlassen hat. Diese Unterscheidung ist für Hochsicherheitsszenarien relevant, in denen Synced Credentials bewusst ausgeschlossen werden sollen. Schließlich steuert das AT-Flag (Bit 6), ob attestedCredentialData in der authData vorhanden ist. Es wird bei der Registration gesetzt, nicht bei der Authentication.
// flags-Byte aus authData auslesen (authData ist ein Uint8Array)
function parseAuthDataFlags(authData) {
const flagsByte = authData[32];
return {
up: !!(flagsByte & 0x01), // Bit 0 – User Presence
uv: !!(flagsByte & 0x04), // Bit 2 – User Verification
be: !!(flagsByte & 0x08), // Bit 3 – Backup Eligibility
bs: !!(flagsByte & 0x10), // Bit 4 – Backup State
at: !!(flagsByte & 0x40), // Bit 6 – Attested Credential Data
ed: !!(flagsByte & 0x80), // Bit 7 – Extension Data
};
}Listing 4: flags-Byte aus authData auslesen, in JavaScript
Die Bytes 33 bis 36 enthalten den signCount – einen Big-Endian-Zähler, der bei jedem Authentifizierungsvorgang höher sein muss als der zuletzt vom Server gespeicherte Wert. Die Idee dahinter ist eine Art Klon-Detektion: Wäre ein privater Schlüssel kopiert worden, wäre der Counter irgendwann nicht mehr korrekt. Bei Synced Passkeys ist diese Logik allerdings kompromittiert. Da etwa ein iCloud-Passkey parallel auf iPhone, iPad und MacBook genutzt werden kann, ist ein konsistenter, monotoner Counter schlicht nicht gewährleistet. Viele Implementierungen setzen signCount deshalb dauerhaft auf 0. Server müssen das explizit behandeln. Wie genau, wird Teil 2 dieser Artikelserie klären.
Das letzte relevante Feld ist attestedCredentialData. Es ist nur bei der Registration vorhanden, wenn das Attested Credential Data Flag gesetzt ist. Es enthält drei Bestandteile, die für die serverseitige Speicherung direkt relevant sind. Die aaguid (16 Bytes) identifiziert das Authenticator-Modell, nicht die individuelle Instanz. Über den FIDO Metadata Service (MDS) kann die RP damit prüfen, welches Gerät oder welche Software das Credential erzeugt hat. Das ist relevant für Szenarien, in denen nur bestimmte Hardware akzeptiert werden soll. Die credentialId ist eine vom Authenticator erzeugte eindeutige ID, die der Server speichert und bei zukünftigen Authentifizierungen in allowCredentials übergibt. Und der credentialPublicKey enthält schließlich den Public Key im Format CBOR Object Signing and Encryption (COSE) (RFC 8152), CBOR-kodiert. Der alg-Parameter gibt den Algorithmus an: -7 steht für ES256 (Elliptic Curve Digital Signature Algorithm (ECDSA) über P-256 mit SHA-256), -257 für RS256, -8 für EdDSA. Dieser Schlüssel ist der einzige Wert, den die RP dauerhaft speichern muss. Alle zukünftigen Assertion-Signaturen werden gegen ihn validiert.
Die Architektur von FIDO2 ist strukturell überschaubar: drei Akteure, zwei API-Aufrufe, eine zentrale Datenstruktur. Relying Party, WebAuthn Client und Authenticator kommunizieren über klar definierte Schnittstellen: WebAuthn nach oben zur Webanwendung, CTAP2 nach unten zum Authenticator. Die authData zieht sich als gemeinsamer Nenner durch beide Ceremonies: Bei der Registration steckt sie im attestationObject, bei der Authentication ist sie direkt als authenticatorData enthalten. Wer das Byte-Layout kennt und weiß, welche Bits welche Validierungen auslösen, kann die Serverlogik direkt einordnen.
Der nächste Teil geht die Registration Ceremony nach §7.1 [9] Schritt für Schritt durch: Er zeigt, wie PublicKeyCredentialCreationOptions aufgebaut ist, wie das attestationObject validiert wird und welche Felder der Server in welcher Reihenfolge prüfen muss. Anschließend folgt die Authentication Ceremony nach §7.2 [10]: PublicKeyCredentialRequestOptions, Signaturvalidierung über authData || SHA-256(clientDataJSON) und der Umgang mit signCount bei Synced Passkeys.
URL dieses Artikels:
https://www.heise.de/-11364345
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Der Molkereiprodukte-Zweig fairlife von Coca Cola muss nach einem Ransomware-Vorfall temporär die Produktion einstellen.
Die US-amerikanische Molkereiproduktsparte fairlife des Erfrischungsgetränkekonzerns Coca Cola ist Opfer einer Ransomware-Kampagne geworden. In der Folge steht die Produktion vorerst still.
Das lässt sich einer Börsen-Pflichtmeldung (Form 8-K) von Coca Cola [1] entnehmen. Demnach wurde der Cyberangriff am vergangenen Donnerstag, den 16. Juli 2026, entdeckt. Dort hat das Unternehmen unbefugte Zugriffe auf Teile der Systeme einschließlich produktionsbezogener Systeme Verbindung mit einem Ransomware-Ereignis festgestellt. Coca Cola habe die Incident-Response-Protokolle und auch jene zur Fortführung der Geschäftsprozesse aktiviert. Die Untersuchungen des Vorfalls zusammen mit externen Beratern und Cybersicherheitsexperten dauern demnach weiter an.
Der Vorfall habe keinen Einfluss auf Produktsicherheit und -Qualität, versichert das Unternehmen. Jedoch wurde in der Folge die Produktion von fairlife in den USA vorübergehend ausgesetzt – die kanadische Sparte ist davon nicht betroffen. Coca Cola untersuche den Vorfall weiter, bislang sei das volle Ausmaß noch unklar.
Auf der Darknet-Leaksite der Cybergang Anubis behauptet die Ransomware [2]-Bande, große Mengen an Daten bei fairlife abgegriffen zu haben.
Die Erpresserbande schreibt dort, dass sie beim Verschlüsseln der Server ein Terabyte an vertraulichen Daten ausgeschleust habe. Ein Countdown droht zum Meldungszeitpunkt mit der Veröffentlichung der Daten in etwas mehr als sechs Tagen.
Der Börsenmeldung ist nicht zu entnehmen, dass Coca Cola planen würde, ein Lösegeld zu zahlen – das ist für einige Unternehmen eine Option, etwa das Schweizer Rüstungsunternehmen RUAG hatte kürzlich Erpressern Geld [3] gezahlt. Cybersicherheitsunternehmen beschäftigen dafür sogar Verhandler. Ein betrügerischer Ransomware-Verhandler aus Florida wurde in der vergangenen Woche zu 70 Monaten Haft [4] verurteilt. Er hatte sogar selbst mit Komplizen Ransomware-Angriffe angeleiert, um hinterher Geld zu erpressen.
URL dieses Artikels:
https://www.heise.de/-11371577
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Nvidia)
Nach dem Shitstorm im März zeigte Nvidia DLSS 5 auf der Siggraph deutlich zurückhaltender. Ob es auf aktueller Hardware läuft, bleibt offen.
Auf der Siggraph-Konferenz in Los Angeles hat Nvidia am Montag eine kurze Vorführung von DLSS 5 gezeigt, die deutlich zurückhaltender ausfällt als der umstrittene Erstauftritt der Technik im März. Nvidia-Forscher Edward Liu präsentierte DLSS 5 in der Keynote „Next Era of Graphics“ inklusive eines knapp 30-sekündigen Clips.
Anstatt wie bei der GTC im Frühjahr auf ein reines Vergleichsvideo zu setzen, zeigte Nvidia diesmal auch, wie sich DLSS 5 im Detail live steuern lässt. So lässt sich etwa feinjustieren, wie stark das KI-Modell Gesichter verändert. Liu hatte schon vorab betont [2], dass die Simulation weiterhin die Welt definiere und die künstlerische Kontrolle bei den Entwicklern bleibe.
DLSS 5 unterscheidet sich grundlegend von früheren DLSS-Versionen. Statt wie bisher primär die Performance zu verbessern, indem Grafik hochskaliert oder zusätzliche Frames eingefügt werden, nutzt DLSS 5 ein generatives KI-Modell, das aus Farben und Bewegungsvektoren fotorealistischere Bilder erzeugt, ohne die Geometrie der Szene zu verändern. Auf der GTC im März hatte Nvidia die Technik erstmals vorgestellt [3]. DLSS 5 soll im Herbst für RTX-50-Grafikkarten erscheinen, unter anderem für „Starfield“, „Assassin's Creed Shadows“, „Hogwarts Legacy“ und „The Elder Scrolls IV: Oblivion Remastered“.
Bei der Vorführung auf der Siggraph zeigte Nvidia die Technik an einigen Spielfiguren in einer virtuellen Umgebung. Mit kontrastreicherer Beleuchtung, verbesserten Kontaktschatten und mehr Streulicht auf der Haut wirkten die Figuren realitätsnäher als in der zugrundeliegenden Render-Version, ohne dabei wie in früheren Demos zu sehr in das Uncanny Valley abzukippen.
Nvidia betonte, dass Entwickler über Regler für „Struktur-“ und „Ton-Intensität“ sowie über Masken für einzelne Objekte genau festlegen können, wie stark DLSS 5 in welchen Bildbereichen eingreift. So lassen sich einzelne Requisiten oder auch nur Teile einer Spielfigur separat regeln, während der Rest der Szene unverändert bleibt.
Die dezentere Demo dürfte auch eine Reaktion auf die heftige Kritik sein, die DLSS 5 seit der GTC-Präsentation begleitet. Fans warfen Nvidia vor, mit der Technik die künstlerische Vision der Entwickler durch KI-Gesichter zu ersetzen. Nvidia-Chef Jensen Huang wies die Kritik zurück [4] und nannte die Spieler „komplett im Unrecht“.
„DLSS 5 muss das Bild so verändern, dass sich die Geschichte nicht ändert“, sagte Liu auf seiner Siggraph-Keynote. Ob das reicht, um die Kritiker zu überzeugen, ist offen. Die frühen Vergleichsbilder aus dem März sorgten für heftige Vorwürfe, weil Gesichter von Figuren wie Grace Ashcroft aus „Resident Evil Requiem“ kaum wiederzuerkennen waren. YouTube-Kommentare unter dem Keynote-Video hat Nvidia deaktiviert.
Unklar bleibt weiterhin, wie viel Rechenleistung DLSS 5 tatsächlich benötigt. Die Demo auf der GTC im März lief auf zwei GeForce RTX 5090 gleichzeitig: Eine Karte übernahm das eigentliche Spiel, die zweite ausschließlich die DLSS-5-Berechnung. Nvidia hatte damals angekündigt, die Technik bis zum Marktstart auf eine einzelne Grafikkarte zu optimieren. Auf welcher Hardware die Vorführung bei der Siggraph lief, teilte Nvidia nicht mit.
URL dieses Artikels:
https://www.heise.de/-11371549
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Siri AI ist da – auch dank Google-Hilfe.
(Bild: Ronja Leppert / KI / heise medien)
Landen meine Daten bei Gemini? Wird Apple Intelligence besser? Brauche ich ein neues iPhone? Die KI-Partnerschaft von Apple und Google wirft Fragen auf.
Im September ist es so weit: Dann erscheinen Apples neue Betriebssysteme wie iOS 27, iPadOS 27 [1] [1], macOS 27 [2] [2] oder watchOS 27 [3] [3] mit Siri AI [4] [4]. Damit will der iPhone-Konzern Jahre des Wartens auf ein besseres KI-System [5] [5] endlich beenden. Doch was heißt das konkret und profitieren wirklich alle Nutzer? Was kann das teilweise von Googles Gemini verbesserte System? Sind neue Geräte notwendig und was passiert innerhalb der Europäischen Union [6] [6]? Wir haben die wichtigsten Antworten für Sie.
Hat Apple Intelligence in iOS, macOS und iPadOS 27 neue Hardware-Voraussetzungen?
Apple setzt weiterhin auf einen hybriden Ansatz aus einem lokalen Modell plus Cloud-Modellen. Die Basis-Systemvoraussetzungen bleiben unverändert: Apple Intelligence ist auf iPhones ab dem 15 Pro sowie Macs und iPads mit M-Chip – plus iPad mini mit A17 Pro und MacBook Neo mit A18 Pro – verfügbar. Allerdings gibt es das On-Device-Modell nun in zwei Varianten: Neueste Hardware mit mindestens 12 GByte RAM erhält ein größeres lokales Modell. Es bleibt dem iPhone 17 Pro (Max), iPhone Air, iPad Air M4, iPad Pro M4 (nur Modelle mit 1 TByte und 2 TByte Speicherplatz) sowie dem iPad Pro M5 vorbehalten. Bei Macs ist dafür ein M3-Chip mit 16 GByte RAM das Minimum.
URL dieses Artikels:
https://www.heise.de/-11369680
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Ein Stummel reicht, um 1.000 Liter Wasser zu vergiften. Die DUH fordert 200 Euro Bußgeld und ein Rauchverbot auf Spielplätzen.
Pro Tag fallen in Deutschland 204 Millionen Zigarettenkippen an und viele werden einfach weggeschnippt. Standardzigarettenfilter bestehen aus dem Kunststoff Celluloseacetat, der so resistent gegen Verrottung ist, dass man damit in der Vergangenheit Terrassendielen erfolgreich gegen Umwelteinflüsse imprägniert hat.
Celluloseacetat ist ein halbsynthetischer Werkstoff, der durch die Veresterung von natürlicher Cellulose aus Holz oder Baumwolle mit Essigsäure hergestellt wird. Es zeichnet sich durch Transparenz, gute Formbarkeit und Seidenglanz aus. Hauptanwendungen sind Textilien, Zigarettenfilter, Brillengestelle und fotografische Filme.
Neben Nikotin und polyzyklischen aromatischen Kohlenwasserstoffen werden auch Schwermetalle, wie Arsen, Blei, Cadmium oder Chrom sowie Teer aus weggeschnippten Zigarettenfiltern durch Regen in die Umwelt gespült. Sie speichern über 7.000 Chemikalien [1]. Ein einziger Stummel reicht aus, um bis zu 1.000 Liter Wasser zu vergiften.
Und die Zigarettenfilter selbst verrotten in der Umwelt nicht wie Papier, sondern zerfallen durch UV-Strahlung und mechanische Einflüsse über Jahre hinweg in winzige Plastikfasern, die auch als Mikroplastik bekannt sind. Es dauert 10 bis 15 Jahre, bis ein Filter im Süßwasser zerfällt. Im Salzwasser dauert der Zerfallsprozess deutlich länger.
Durch weggeworfene Zigarettenfilter sollen weltweit jedes Jahr rund 300.000 Tonnen Mikrofasern in die Umwelt gelangen. Damit gehören diese Stummel zu den größten Eintragsquellen für Mikroplastik überhaupt. Die Mikrofasern gelangen dann über das Grundwasser in die Nahrungskette und können zu Entzündungsreaktionen [2] in menschlichen Immunzellen führen.
Die Weltgesundheitsorganisation [3] bezeichnet Zigarettenfilter nicht nur als Quelle von Mikroplastik, sondern fordert auch, sie als Einwegplastik zu verbieten, denn Filter sind für die Gesundheit der Raucher letztlich wirkungslos, weil Raucher von Filterzigaretten tiefer inhalieren.
Sie sind für die Umwelt aber hoch schädlich. Ihre Herstellung, Nutzung und Entsorgung verursachen Kosten und Belastungen für die Umwelt, ohne irgendeinen gesundheitlichen Nutzen zu bringen.
Einen ersten, ganz zaghaften Schritt zur Eindämmung der Zigarettenfilterflut wagt die Bundesregierung aktuell mit der geplanten Erhöhung [4] der Tabaksteuer. An ein Verbot von Filterzigaretten traut sich Berlin jedoch noch nicht, weil offensichtlich die Mehrheit der Bevölkerung das Märchen von der reduzierten Schädlichkeit des Rauchens durch Zigarettenfilter als absolute Wahrheit zu glauben scheint.
Zudem will man es sich mit der Tabak-Industrie nicht verderben, hat sie doch in der Vergangenheit so manchen Parteitag gesponsort.
Solange sich die Politik nicht traut, Filterzigaretten wegen nachgewiesener Wirkungslosigkeit und Irreführung der Verbraucher zu verbieten, bleibt nur die Möglichkeit, die Folgen dieses Marketing-getriebenen Irrwegs zu begrenzen. Da Kippenstummel spielende Kinder gefährden, haben sie auf Spielplätzen nichts zu suchen.
Dringende Konsequenz ist daher in einem ersten Schritt ein bundeseinheitliches Rauchverbot auf Spielplätzen und eine konsequente Überwachung des Rauchverbots auf Bahnhöfen durch den Sicherheitsdienst der Deutschen Bahn und die Bundespolizei.
Die Deutsche Umwelthilfe fordert gegen die rücksichtslose Umweltverschmutzung, dass unter den Bundesländern einheitlich abgestimmte abschreckende Bußgelder in Höhe von mindestens 200 Euro für das illegale Entsorgen in der Landschaft [5] eingeführt werden. Dazu Barbara Metz [6], DUH-Bundesgeschäftsführerin:
"Das achtlose Wegschnippen von Kippenstummeln wird schon viel zu lang geduldet. Milliarden von Gift-Filtern verdrecken nicht nur die Landschaft, sie belasten Gewässer und gefährden Tiere, die sie essen. Vor allem auch für Kinder, die diese in den Mund nehmen, stellen die Zigarettenstummel ein großes Gesundheitsrisiko dar. Bei Kleinkindern kann schon eine einzige verschluckte Kippe zu ernsthaften Vergiftungssymptomen führen.
Wir fordern daher ein schnelles bundesweites Rauchverbot auf öffentlichen Spielplätzen, einheitlich abschreckend hohe Bußgelder in Höhe von mindestens 200 Euro für illegal entsorgte Zigaretten und eine konsequente Kontrolle durch die Länder."
Deutschland könnte dem Vorbild anderer Staaten folgen. In Schweden ist ein Rauchverbot auf allen Spielplätzen bereits umgesetzt. Dort wird zusätzlich empfohlen, mit Schildern auf das strikte Verbot hinzuweisen.
In Singapur [7] ist das Rauchen und der Umgang mit Zigaretten streng reguliert. Das Wegwerfen von Kippen auf die Straße wird als Müllsünder-Vergehen mit hohen dreistelligen Eurobeträgen bestraft.
Ein deutsches Pfandsystem für Zigarettenfilter wäre zwar ein auf den ersten Blick nachvollziehbarer Ansatz. Pfandsysteme haben sich sowohl bei Einwegflaschen als auch bei Starterbatterien erfolgreich durchgesetzt, bei Zigarettenstummel gibt es jedoch noch keinen konkreten Umsetzungsvorschlag. Denn die giftigen Filter sollten stofflich nicht mehr genutzt, sondern sicher entsorgt werden. Ein Filterverbot wäre daher erfolgversprechender.
URL dieses Artikels:
https://www.heise.de/-11370620
Links in diesem Artikel:
Copyright © 2026 Heise Medien
