Anmelden
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
(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
Künstlerische Darstellung von LHS 1140b
Forscher haben erstmals eine Atmosphäre auf einem felsigen Exoplaneten in der bewohnbaren Zone nachgewiesen. Damit sind jedoch längst nicht alle Fragen geklärt.
Ein internationales Forschungsteam unter Leitung von Wissenschaftlern der Harvard University hat erstmals eine Atmosphäre um den Exoplaneten LHS 1140 b nachgewiesen.
Der Himmelskörper hat eine felsige Oberfläche und gilt als erdähnliches Planet,der sich in der sogenannten habitablen Zone seines Sterns befindet. Das ist jener Bereich, in dem auf der Planetenoberfläche flüssiges Wasser existieren könnte. Die Studie wurde im Fachjournal Science veröffentlicht [1].
LHS 1140 b liegt rund 48 Lichtjahre von der Erde entfernt und umkreist einen roten Zwergstern im Sternbild Cetus [2] (Walfisch). Dieser Stern ist kleiner und kühler als unsere Sonne, gibt aber einen größeren Anteil seiner Energie als ionisierende Strahlung ab. Der Planet selbst hat eine Masse, die 5,6-mal größer ist als die der Erde, und sein Radius übertrifft den unserer Erde um 70 Prozent. Er wurde bereits 2017 entdeckt.
Der Nachweis der Atmosphäre gelang dem Team mithilfe des Warm Infrared Echelle (Winered) [3] Spektrografen am Magellan-Clay-Teleskop [4] des Las-Campanas-Observatoriums in Chile.
Bei einem Transit – also dem Vorüberziehen des Planeten vor seinem Stern – registrierten die Forscher im Jahr 2024 Helium, das aus der oberen Atmosphäre des Planeten in den Weltraum entweicht. Dieser Vorgang, den Astrophysiker als atmosphärische Entgasung bezeichnen, bestätigte, dass LHS 1140 b tatsächlich eine Atmosphäre besitzt und diese aktiv aufrechterhält.
Dem Erstautor der Studie, Dr. Collin Cherubim, der kürzlich seinen Doktortitel in Erd- und Planetenwissenschaften an der Harvard University erworben hat, zufolge war der Fund eindeutig: "Dies ist das erste Mal, dass jemand eine Atmosphäre auf einem felsigen Planeten in der habitablen Zone eines anderen Sterns gefunden hat", sagte [5] er gegenüber der BBC.
Ausgangspunkt der Beobachtungen waren Computermodelle, die das Team zuvor entwickelt hatte und die eine heliumreiche obere Atmosphäre für LHS 1140 b vorhergesagt hatten. "Collin hat die bekannten Planeten analysiert und vorhergesagt, dass dieser eine Heliumatmosphäre haben würde. Dann hat er Teleskopzeit organisiert, die Daten beschafft, und der Nachweis war statistisch absolut solide", erklärte David Charbonneau, Leiter des Astronomie-Departments der Harvard University und Co-Betreuer von Cherubim.
Allerdings blieb eine Beobachtung zunächst rätselhaft: Bei Folgebeobachtungen im Jahr 2025 ließ sich das Heliumsignal nicht reproduzieren. Cherubim bezeichnete dies als einen Schock, der ihn und sein Team dazu veranlasste, die ursprünglichen Daten erneut zu überprüfen.
"Jeden falschen positiven Befund, den wir uns vorstellen konnten, haben wir sicher ausgeschlossen", sagte [6] er gegenüber dem Guardian. Das variierende Signal könnte nach Einschätzung von Forschern damit zusammenhängen, wie die Atmosphäre des Planeten auf die extreme ultraviolette Strahlung seines Sterns reagiert.
Cherubim betonte, dass LHS 1140 b nun alle wesentlichen Voraussetzungen für eine potenziell bewohnbare Umgebung erfülle: ein felsiger Planet, Temperaturen, die flüssiges Wasser ermöglichen, und eine Atmosphäre, die verhindert, dass dieses Wasser entweicht, und die gleichzeitig die Oberfläche vor schädlicher Strahlung schützt. Hinzu komme, dass der Stern selbst vergleichsweise ruhig sei und selten Strahlungsausbrüche produziere.
Robin Wordsworth, Professor für Erd- und Planetenwissenschaften an der Harvard University, ordnete den Fund historisch ein: Noch vor zwanzig Jahren wussten Astronomen nicht einmal, ob erdähnliche Planeten überhaupt existierten. Schnell stellte sich heraus, dass solche Planeten häufig vorkommen – auch in habitablen Zonen. "Die nächste Frage war, ob es irgendeinem von ihnen gelungen ist, eine Atmosphäre zu behalten", sagte Wordsworth. "Jetzt wissen wir, dass mindestens einem das gelungen ist."
Gleichwohl mahnen Forscher zur Vorsicht. Das bislang einzige nachgewiesene Gas ist Helium – und zwar in der oberen Atmosphäre. Helium allein kann kein Leben unterstützen. Dr. Yamila Miguel vom Leidener Observatorium in den Niederlanden wies darauf hin, dass die Beobachtungen die obere Atmosphäre betreffen und nicht die bodennahen Schichten, in denen Leben entstehen würde.
"Daher glaube ich nicht, dass diese Ergebnisse direkte Implikationen für den Nachweis von Leben auf anderen Planeten haben", sagte sie gegenüber dem Guardian. Ob weitere, lebensfreundlichere Gase in tieferen Atmosphärenschichten vorhanden sind, bleibt vorerst offen.
Seit 1995 wurden mehr als 6.000 Exoplaneten bestätigt. Atmosphären wurden bislang um Gasriesen und sogenannte Sub-Neptune gefunden – also Planeten, die größer als die Erde, aber kleiner als Neptun sind. Auch um felsige Exoplaneten außerhalb der habitablen Zone gab es bereits Hinweise auf Atmosphären. Der Nachweis einer Atmosphäre um einen felsigen Planeten innerhalb der habitablen Zone ist jedoch ein Novum.
URL dieses Artikels:
https://www.heise.de/-11370882
Links in diesem Artikel:
Copyright © 2026 Heise Medien
OpenAI-Chef Sam Altman hat sich wegen des möglichen Baus eines hochmodernen KI-Rechenzentrums im vergangenen Jahr mehrfach mit der deutschen Staatsspitze getroffen. Im September sprach er mit Bundeskanzler Friedrich Merz, zudem führte er separate Gespräche mit Vizekanzler Lars Klingbeil und Digitalminister Karsten Wildberger, wie das Handelsblatt berichtete.
OpenAI wollte dem Bericht zufolge eine Anlage mit einer Kapazität von bis zu einem Gigawatt errichten, mehr als alle bestehenden deutschen KI-Rechenzentren zusammen haben. Innerhalb der Regierung soll die Investition als Chance gegolten haben, Deutschland als Standort für KI-Infrastruktur zu positionieren.
Altman wollte den Standort allerdings nahe der französischen Grenze, damit das Werk auf günstigen französischen Atomstrom zugreifen kann, statt auf das vergleichsweise teure deutsche Netz. Das sagten mit den Gesprächen vertraute Personen dem Handelsblatt.
Deutschland schaltete seine letzten Atomkraftwerke 2023 ab. Merz bezeichnete diese Entscheidung wiederholt als unumkehrbar. Ein Projekt, das an Atomstrom gekoppelt ist, berührt damit einen politisch heiklen Punkt innerhalb der Koalition.
Insider sagten der Zeitung weiter, die Folgegespräche seien vage und ohne die technischen Details gewesen, die ein Projekt dieser Größenordnung normalerweise erfordere. In Regierungskreisen vermutet man dem Bericht zufolge, OpenAI habe nie ernsthaft vorgehabt, sich zu binden, sondern lediglich getestet, wie Berlin reagiere.
In Deutschland gelten strenge Vorschriften: Abwärmeauflagen und eine kommende Pflicht, Rechenzentren ab 2027 vollständig mit grünem Strom zu betreiben, erhöhen die Kosten. Das Kabinett lockerte im Juni zwar einen Teil dieser Vorgaben. Koalitionspläne sehen vor, dass Kommunen künftig einen größeren Anteil der Steuereinnahmen aus solchen Anlagen behalten dürfen. Ob das Projekt wieder auf die Agenda kommt, ist aber offen.
(Bild: ronstik/Shutterstock.com)
Ermittler aus Deutschland und den USA haben die Infrastruktur des Phishing-Services Kratos zerschlagen. Der Dienst ermöglichte monatlich tausende Angriffe.
Die Anzahl der Opfer, die aus mehr als 30 Ländern – vor allem aus Europa und den USA – stammten, gehe seit Ende 2024 in die Hunderttausende, teilten das Bundeskriminalamt (BKA) und die bei der Generalstaatsanwaltschaft Frankfurt ansässige Zentralstelle zur Bekämpfung der Internetkriminalität (ZIT) mit. Zudem seien durch den Schlag Angriffe auf hunderttausende potenzielle Opfer weltweit abgewehrt worden.
Laut den Angaben wurde der Entwickler und technische Administrator des Phishing-Services [1] namens „Kratos“ in Indonesien von den dortigen Behörden festgenommen. Zudem seien zentrale technische Komponenten abgeschaltet und die „Kratos“-Infrastruktur vollständig außer Betrieb gesetzt worden.
„Wer im Internet mit gefälschten Webseiten Zugangsdaten stiehlt, darf sich nicht in Sicherheit wiegen. Der Erfolg gegen das Phishing-Kit Kratos zeigt, dass sich auch hochprofessionelle Phishing-Infrastrukturen wirksam bekämpfen lassen. Das ist Pionierarbeit und ein deutliches Signal an andere Cyberakteure“, betont Carsten Meywirth, Leiter der Abteilung Cybercrime im BKA.
Bei Kratos handelte es sich den Angaben zufolge um einen von der gleichnamigen Gruppierung entwickelten digitalen Baukasten, mit dem sich insbesondere täuschend echte Microsoft-Authentifizierungs-Webseiten erstellen und verwalten ließen. „Die Webseiten wurden eingesetzt, um Zugangsdaten wie Passwörter und E-Mail-Adressen von Opfern durch gefälschte Abfragemasken zu stehlen (Phishing), mit denen dann weitere Straftaten begangen wurden“, erklärten die Ermittler.
Das Geschäftsmodell der Kratos-Gruppierung beruhte darauf, den digitalen Baukasten an andere Cyberkriminelle weiterzuvermieten, die dann wiederum die eigentlichen Phishing-Kampagnen durchführten. Dadurch hätten auch technisch weniger kompetente Kriminelle agieren können.
Laut den Angaben habe die Gruppe seit 2024 mehr als 300.000 Euro erwirtschaftet. „Über 1.800 kriminelle Franchisenehmer sollen „Kratos“ erworben und damit monatlich ca. 15.000 Phishing-Kampagnen durchgeführt haben. Dabei hatte jede einzelne Kampagne das Potenzial, mehrere tausend Empfänger weltweit zu schädigen“, hieß es. Mehr als 200 Server der Gruppe seien unschädlich gemacht worden.
Mit dem Schlag sei „erstmalig ein bedeutender Ermittlungserfolg“ gegen eine der weltweit gefährlichsten Phishing-as-a-Service-Gruppierungen gelungen, hieß es. Weitere Details sind in der Pressemitteilung [2] nachzulesen.
URL dieses Artikels:
https://www.heise.de/-11371371
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
IPFire Core Update 203 ersetzt Unbound durch Knot Resolver, bringt DNS-Firewall, DoT und 6-GHz-WLAN.
Mit dem Core Update 203 baut IPFire die DNS-Infrastruktur grundlegend um: Statt Unbound kommt künftig Knot Resolver zum Einsatz. Die Umstellung soll unter anderem verschlüsselte Weiterleitung per DNS over TLS, DNS-basierte Filterregeln und einen persistenten Cache ermöglichen. Außerdem unterstützt der integrierte WLAN-Access-Point nun das 6-GHz-Band von Wi-Fi 6E und Wi-Fi 7.
IPFire ist eine auf Sicherheit und Netzwerkgateways ausgerichtete Linux-Distribution. Sie wird typischerweise als Firewall und VPN-Gateway mit Intrusion-Prevention-Funktion eingesetzt.
Laut Release Notes [1] ersetzen die IPFire-Entwickler mit dem Update den bisher verwendeten Resolver Unbound durch Knot Resolver. Der Wechsel betrifft eine Kernfunktion des Systems: DNS löst nicht nur Hostnamen in IP-Adressen auf, sondern liefert inzwischen auch Informationen für verschlüsselte Verbindungen und moderne Transportprotokolle.
Knot Resolver soll IPFire dafür eine besser erweiterbare Architektur bieten. Der Resolver arbeitet modular und lässt sich skripten. IPFire nutzt dies für eigene Erweiterungen, etwa für die Anbindung von DHCP-Leases und DNS-Filterlisten.
Neu ist unter anderem die Möglichkeit, DNS-Anfragen an externe Resolver verschlüsselt über DNS over TLS weiterzuleiten. Damit lassen sich Anfragen auf dem Weg zum gewählten Upstream-Resolver vor Mitlesern und Manipulation schützen. Administratoren können damit beispielsweise einen externen Resolver einsetzen, ohne DNS-Abfragen unverschlüsselt über den öffentlichen Internetzugang zu schicken.
Mit der neuen DNS-Basis führt IPFire eine DNS-Firewall ein. Sie kann Domains für Malware, Werbung oder andere Kategorien bereits bei der Namensauflösung blockieren. Die dafür benötigten Zonen und Filterdaten lädt das neue Werkzeug zone-sync verschlüsselt herunter. Es aktualisiert die Daten inkrementell, statt stets vollständige Listen zu übertragen.
Auch der Filtermechanismus SafeSearch lässt sich netzwerkweit erzwingen: IPFire leitet Suchanfragen dann zu den SafeSearch-Varianten unterstützter Suchmaschinen und von YouTube um. Zusätzlich bleiben lokale DNS-Einträge und bedingte Weiterleitungen verfügbar. Letztere schicken Anfragen für definierte Zonen gezielt an bestimmte DNS-Server, etwa für ein internes Firmennetz oder eine per VPN erreichbare Domain.
Der Resolver-Cache übersteht künftig Neustarts. Das soll die Namensauflösung nach einem Reboot beschleunigen und die Last auf übergeordneten DNS-Servern senken. Knot Resolver nutzt zudem mehrere Worker-Prozesse, die sich Cache und Status teilen. Dadurch kann IPFire mehrere CPU-Kerne einsetzen, ohne dass jeder Prozess einen eigenen, isolierten Cache pflegt.
Administratoren müssen bei bestehenden DNS-Weiterleitungen allerdings nacharbeiten: Als Forward-Zones konfigurierte vollständig qualifizierte Domainnamen (FQDN) akzeptiert IPFire nicht mehr. Solche Einträge auf der Seite für DNS-Forwarding müssen durch IP-Adressen ersetzt werden.
Der WLAN-Access-Point von IPFire unterstützt nun das 6-GHz-Band. Damit kann die Distribution das zusätzliche Spektrum von Wi-Fi 6E und Wi-Fi 7 nutzen. Gerade in dicht belegten Umgebungen verspricht das weniger Störungen durch Altgeräte und mehr Platz für breite Kanäle mit 80 oder 160 MHz.
Anders als in Teilen des 5-GHz-Bands ist im 6-GHz-Spektrum keine Radarerkennung per DFS erforderlich. Access Points müssen daher vor dem Start keinen freien Kanal suchen und bei erkannten Radarsignalen nicht zwangsweise den Kanal wechseln. Das soll Verbindungsabbrüche durch solche Wechsel vermeiden. Zudem behebt das Update einen Fehler, der den Start des Access Points bei manuell gewähltem Kanal und 40 MHz Kanalbreite verhindern konnte.
Für IPFire-Instanzen auf AWS ergänzt das Release die Unterstützung für IMDSv2. Der tokenbasierte Metadatenservice von EC2 gilt gegenüber der ersten Version als sicherer und kann bei neueren Konfigurationen verpflichtend sein. Bestehende Installationen mit IMDSv1 sollen weiterhin funktionieren.
Core Update 203 aktualisiert außerdem Intel-Microcode für bestimmte Prozessoren. Dieser soll eine unter INTEL-SA-01420 geführte Sicherheitslücke adressieren. Ein Fehler bei der UTF-8-Verarbeitung in Perl wurde ebenfalls korrigiert; dadurch sollen Übersetzungen mit Nicht-ASCII-Zeichen wieder korrekt in der Weboberfläche erscheinen.
Daneben aktualisiert IPFire zahlreiche Basis- und Zusatzpakete, darunter BIND, OpenVPN, Suricata, strongSwan, Samba, Postfix und Zabbix Agent. Bei OpenVPN wurden unter anderem die Konfigurations-Download-Schaltfläche überarbeitet und zusätzliche Angaben für Roadwarrior-Verbindungen mit statischer IP-Zuweisung ergänzt.
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11371136
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Shutterstock/chanpipat)
Die OpenSSL-Maintainer haben stillschweigend eine Denial-of-Service-Lücke geschlossen. Okta nennt sie „HollowByte“.
In OpenSSL haben die Entwickler stillschweigend eine Denial-of-Service-Sicherheitslücke geschlossen. Die IT-Sicherheitsexperten von Okta haben der Schwachstelle den Spitznamen „HollowByte“ verpasst.
In einem aktuellen Blogbeitrag erklären die Okta-Programmierer [1], dass die Sicherheitslücke sich mit manipulierten Paketen mit einer Nutzlast von 11 Byte missbrauchen lässt. Angreifer können OpenSSL damit aus dem Internet attackieren und dazu bringen, unverhältnismäßig große Speicherbereiche zu belegen, noch bevor ein Sicherheits-Handshake anfängt.
Okta führt aus, dass ein TLS-Handshake mit einer „ClientHello“-Nachricht anfängt. Diese Handshake-Nachricht enthält einen 4-Byte-Header, der die Länge des ankommenden Nachrichtentexts deklariert. Ältere OpenSSL-Versionen allokieren einen Speicherbereich mit dieser Größenangabe, bevor überhaupt etwaige Daten ankommen. Mit bösartigen Headern führt OpenSSL nun unüberprüft diese Speicherbelegung aus. Mit der bösartigen, 11 Byte langen Nutzlast liest die TLS-State-Machine den 4-Byte-Handshake-Header und belegt vorab Speicher gemäß der 3 Byte langen Längendeklaration. Bis zu 131 KByte Speicher belegt das dann aufgrund einer Angabe in nicht vertrauenswürdigen Paketen. Dazu kommt, dass der Worker-Thread blockiert und auf die Ankunft der angekündigten Daten wartet, die jedoch niemals ankommen, erklärt Okta das Problem.
Ein Angriff, der Verbindungen offen hält und die verfügbaren Threads ausschöpft, ist ein klassischer Denial-of-Service. „HollowByte“ ist noch etwas schlimmer, schreibt Okta, da OpenSSL zwar bei Beenden der Verbindung den Puffer wieder freigibt. Glibc hingegen gibt die Speicherbereiche kleinerer und mittlerer Belegungen nicht sofort wieder zurück, sondern hält sie für eine mögliche erneute Nutzung erstmal weiter vor. Durch Anfragen mit zufälligen Größen unterbinden Angreifer die Wiederbenutzung der Speicherblöcke, der Heap-Speicher fragmentiert stark. Selbst nach dem Ende eines Angriffs bleibt der Server weiter in diesem Status. Der einzige Weg, wieder an den Speicher zu gelangen, ist das Abschießen des Prozesses.
Okta hat das mit einem nginx-Server mit einer 1-GByte-RAM-Umgebung getestet. Nachdem 547 MByte des Speichers fragmentiert und eingefroren waren, kam es zum Prozess-Hänger aufgrund von „Out Of Memory“. Mit mehr Speicher, etwa 16 GByte RAM, trat der Zustand nach Belegung von 25 Prozent des Systemspeichers ein. Dabei blieb der Angriff unter der maximalen Anzahl möglicher Verbindungen, sodass Standard-Maßnahmen zur Begrenzung von Verbindungen nicht helfen.
Die OpenSSL-Entwickler haben das Problem stillschweigend mit OpenSSL 4.0.1 behoben und auf die Zweige 3.6.3, 3.5.7, 3.4.6 und 3.0.21 zurückportiert. Sie haben das „Fix zur Härtung“ deklariert und keinen CVE-Eintrag vergeben. Dennoch raten die Okta-Experten OpenSSL-Nutzern dazu, ihre Software auf den aktuellen Stand zu bringen. OpenSSL 4.0.1 sowie die Backports erschienen bereits früher im Juni [2] und schlossen mehrere Sicherheitslücken, die teils das Einschleusen von Schadcode erlaubten. Wer also die Aktualisierung noch nicht vorgenommen hat, sollte das nun nachholen.
URL dieses Artikels:
https://www.heise.de/-11370866
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Mit dem CMS WordPress sind Websites auch ohne Fachwissen schnell aufgebaut. Damit dessen JSON-API nicht sämtliche Daten ausplaudert, müssen Sie es schützen.
Mit WordPress ein eigenes Blog oder eine Homepage aufzusetzen, ist leicht. Schlüsselfertige Installationen des CMS bekommt man praktisch bei jedem Hoster. Das ist ideal, um Informationen zu verbreiten. Manche Daten nur bestimmten Benutzern zugänglich zu machen, ist hingegen nicht so leicht. Denn was viele Betreiber nicht wissen: WordPress besitzt ein leistungsfähiges, standardmäßig ziemlich auskunftsfreudiges JSON-API. Darüber lassen sich zum Teil sensible Daten ohne vorherige Anmeldung am Frontend vorbei abrufen.
Durch das JSON-API ist WordPress besonders ausbaufähig und flexibel. Es ermöglicht die Entwicklung von Erweiterungen auf Basis einer stabilen, klar definierten Schnittstelle, die noch dazu zustandslos ist – also nicht abhängig davon, was andere Benutzer gerade auf der Website tun. So gibt es Smartphone-Apps und verschiedene Editoren, mit denen man Inhalte erstellen und verwalten kann: Neben dem Classic Editor den aktuellen Standard-Editor Guttenberg, Thrive Architect, Elementor und Divi, um nur drei bekanntere zu nennen. Auch viele Plug-ins wie Kontaktformulare nutzen das JSON-API als Schnittstelle zu WordPress.
Für ein Reise-Blog mag es kein Problem sein, dass standardmäßig alle Inhalte jedem zugänglich sind, doch schon bei einer Vereinswebsite liegt der Fall anders: Dort gibt es üblicherweise einen Mitglieds- oder gar Vorstandsbereich, den eben nicht jeder einsehen können soll. Denn selbst wenn der Abruf dieser Seiten über das Standard-Theme nur angemeldeten Benutzern möglich sein sollte, kommt über das JSON-API jeder ohne eine Anmeldung heran. Abhilfe bringt ein Plug-in, das den Zugang zum JSON-API einschränkt.
URL dieses Artikels:
https://www.heise.de/-11350569
Links in diesem Artikel:
Copyright © 2026 Heise Medien
iPad mini 7 in verschiedenen Farben: Nachfolger bald erstmals mit OLED?
(Bild: Apple)
Apple steht kurz vor der Überholung seines Kompakt-Tablets – und bereitet auch neue Modelle weiterer Baureihen vor. Doch gibt es technische Defizite?
Die siebte Generation des iPad mini [1] wird demnächst zwei Jahre alt. Apple plant einem Bericht zufolge zeitnah einen Nachfolger – und geht damit offenbar einen wichtigen technischen Schritt. Nachdem der Hersteller bereits beim iPad Pro in den Größen mit 11 und 13 Zoll seit der M4-Variante [2] von 2024 erstmals größere OLED-Screens verbaut, sollen diese nun auch erstmals in dem Kompakt-Tablet landen. Allerdings ist offenbar eine abgespeckte Version der organischen Leuchtdioden mit geringerer Bildwiederholfrequenz geplant, als man das von den Pro-Modellen kennt.
Wie die Finanznachrichtenagentur Bloomberg [3] schreibt, trägt das neue iPad mini 8 den internen Codenamen J510. Der aktuelle LCD-Screen mit 8,3 Zoll wird demnach gegen ein OLED-Panel ausgetauscht. Es verspricht unter anderem eine bessere Farbdarstellung mit besseren Schwarzwerten, mitunter auch weniger Stromverbrauch. Der neue iPad-mini-Screen fügt sich im Hinblick auf die Größe zwischen den iPhone-OLEDs (seit 2017, maximale Größe: 6,9 Zoll beim iPhone 17 Pro Max [4]) und dem iPad Pro ein. Die Verfügbarkeit könnte im Herbst beginnen, möglicherweise im Oktober.
Ob sich aufgrund des neuen Bildschirms etwas am Formfaktor des iPad mini ändert, ist noch nicht durchgesickert. Denkbar wäre es, dass es dadurch etwas dünner wird. Apple dürfte weiterhin schnellere Chips verbauen. Derzeit nutzt Apple im iPad mini 7 den A17 Pro aus iPhone 15 Pro und 15 Pro Max, der bereits Apple-Intelligence-fähig [5] ist. Apple könnte auf den A19 Pro aus dem iPhone 17 Pro und 17 Pro Max wechseln, der in diesem September vermutlich durch den A20 Pro abgelöst wird. Der Einstiegspreis des neuen iPad mini dürfte höher ausfallen als bislang, wobei Apple die Preise für die aktuellen Modelle bereits erhöht [6] hat.
Angeblich nicht im iPad mini 8 integriert ist eine höhere Bildwechselfrequenz. Ein südkoreanischer Leaker hatte Mitte Juli behauptet, Apple werde kein ProMotion nutzen, also nicht die bis zu 120 Hertz aus dem iPad Pro anbieten [7]. Laut der Quelle setzt Apple auf ein 8,4 Zoll großes LTPS-Hybrid-Panel.
Dafür hat Apple vor, weitere iPads zu aktualisieren: Neue Einsteiger-iPads (dann Generation 12) sowie ein neues Air seien „für nächstes Jahr“ vorgesehen, möglicherweise im Frühjahr. Apple war es zuletzt gelungen, die iPad-Verkäufe im gesamten Geschäftsjahr um sechs Prozent zu steigern. Das war allerdings vor den Preiserhöhungen. Es gibt auch Gerüchte um neue Varianten des Apple Pencil für das kommende Jahr [8]. Erste MacBooks mit OLED [9] werden ebenfalls im Oktober erwartet – angeblich mit bis zu 16 Zoll.
URL dieses Artikels:
https://www.heise.de/-11369648
Links in diesem Artikel:
Copyright © 2026 Heise Medien
