Anmelden
(Bild: heise medien)
Zum Wochenende wurde die „wp2shell“-WordPress-Lücke bekannt. Seitdem beobachten IT-Sicherheitsforscher Attacken im Internet darauf.
Mehrere IT-Sicherheitsunternehmen sowie das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnen davor, dass sie Angriffe auf die am vergangenen Freitag bekannt gewordene „wp2shell“-Sicherheitslücke in WordPress beobachten. Es handelt sich bei „wp2shell“ am Ende um eine Verkettung von Schwachstellen, die das Einschleusen von Code über eine API [1] – durch die Verkettung ohne vorherige Authentifizierung – erlauben.
Das BSI hat eine Warnung veröffentlicht [2], laut der die Lücke die Stufe 3 (Orange) auf der Risikoskala (bis maximal 4/rot) erreicht. Die Behörde weist darin auf die aktive Ausnutzung in freier Wildbahn hin. Das BSI schreibt, dass im Laufe des Wochenendes Proof-of-Concept-Code veröffentlicht worden sei, der die Ausnutzung der Schwachstellenkette und damit Angriffe ohne vorherige Anmeldung demonstriert. Das BSI stuft die Lückenverkettung abweichend von den einzelnen Risikoeinstufungen der jeweiligen Lücken (CVE-2026-60137, CVSS 9.1, Risiko „kritisch“; CVE-2026-63030, CVSS 7.5, Risiko „hoch“) mit einem CVSS-Wert von 9.8 als „kritisch“ ein.
Die deutsche IT-Sicherheitsbehörde weist zudem darauf hin, dass nur wenige Stunden nach der Veröffentlichung der Lücken erste PoCs auftauchten und kurz darauf bereits Berichte über ersten Missbrauch auftauchten. Das sei ein weiterer Hinweis auf die inzwischen deutlich verkürzte Zeit zum Missbrauch von Schwachstellen („Time-to-Exploit“).
Etwa die IT-Forscher von wiz.io berichten [3] ebenfalls von beobachteten Angriffen auf die Schwachstellenkette. Die bösartigen Akteure verankern damit persistente Webshells, erklären die IT-Sicherheitsforscher. Sie nennen in ihrer Analyse auch Hinweise für Angriffe (Indicators of Compromise, IOC), die Admins beim Aufspüren von kompromittierten Instanzen helfen können. Cloudflare hat seiner Web-Application-Firewall (WAF) Regeln [4] beigebracht, die vor dem Missbrauch der Sicherheitslücken schützen sollen. Noch am Freitag hat das Unternehmen die Regeln für Kunden mit kostenlosen Zugängen und Bezahl-Abos damit ausgestattet. Voraussetzung für die Wirksamkeit ist natürlich, dass der Traffic auf die eigenen Server durch die Cloudflare-WAF geleitet wird. Auch der IT-Sicherheitsforscher Maurice Fielenbach von Hexastrike berichtet auf Linkedin [5] von beobachteten Angriffen.
IT-Verantwortliche müssen dringend aktiv werden. Wer bis jetzt die Aktualisierungen auf die fehlerbereinigten Versionen 7.1 Beta 2, 7.0.2, 6.9.5 sowie 6.8.6 oder neuere nicht vorgenommen hat, sollte das schleunigst nachholen. Da der aktive Missbrauch im Internet wenige Stunden nach Bekanntwerden der Lücke seinen Anfang nahm, sollten Admins ihre Instanzen als kompromittiert betrachten, sofern sie das Update nicht gleich am Freitag installiert haben. Sie sollten ihre Systeme in diesem Fall auf Einbruchsspuren untersuchen und gegebenenfalls bereinigen.
URL dieses Artikels:
https://www.heise.de/-11372213
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Garmin / Fabian Stoffers)
Garmin hat mit dem Cirqa seinen ersten bildschirmlosen Fitnesstracker vorgestellt. Das Band erfasst Gesundheitsdaten und kommt ohne Abozwang.
Mit dem Cirqa bringt Garmin seinen ersten bildschirmlosen Fitnesstracker auf den Markt. Das Armband folgt auf die Modelle der Mitbewerber Whoop, Amazfit, Polar [1] und Google Fitbit [2]. Es ist kein Abo erforderlich, jedoch müssen Interessierte 200 Euro auf den Tisch legen.
Laut Garmin richtet sich das Armband an Nutzerinnen und Nutzer, die „ihre Gesundheit und Fitness ganz bewusst leben, aber nicht ständig auf ein Display schauen möchten“. Das Smartband soll Gesundheits- und Fitnessdaten rund um die Uhr erfassen können und bietet eine Akkulaufzeit von bis zu zehn Tagen.
Laut Garmin [3] soll sich das Band durch die kompakte und dezente Form leicht tragen lassen. Es helfe dabei, „Gewohnheiten besser zu verstehen sowie persönliche Ziele im Blick zu behalten“. Das Cirqa-Band erfasst unter anderem Garmin-typische Werte wie „Body Battery“, Stresslevel, Schritte und soll zudem Einblicke in die Frauengesundheit liefern.
Ferner liefert das Band Schlafanalyse mit Sleep Score, HFV-Status (Herzfrequenzvariabilität) und Schlafcoach-Informationen rund um die persönliche Schlafqualität und den Biorhythmus. Außerdem analysiere das Band VO2max und Trainingszustand, um Trägern und Trägerinnen „fundierte Einblicke in Leistungsfähigkeit, Trainingsfortschritt und die Wirksamkeit des Trainings“ zu liefern.
Das Band erkennt allerlei Aktivitäten automatisch und zeichnet sie dann auf. Ebenso sollen sich mehr als 80 verschiedene Aktivitäten manuell starten lassen, darunter Laufen, Gehen und Yoga. Zudem lasse sich eine individuell festgelegte Lieblingsaktivität über eine Taste an der Gehäuseseite starten.
Laut Garmin sollen Nutzerinnen und Nutzer durch Bestätigungen oder Anpassungen in der Garmin-Connect-App dabei helfen, die Aktivitätserkennung stetig zu verbessern, um „präzisere Ergebnisse zu erhalten“.
Das Garmin Cirqa-Band lässt sich per Bluetooth und ANT+ mit Geräten verbinden, ferner unterstützt es sowohl Android als auch iOS. GPS hat das Band nicht an Bord; entsprechende Daten lassen sich in Verbindung mit einem Smartphone tracken, so der Hersteller.
(Bild: Garmin)
Das Armband ist in den Farben „Schwarz“, „French Gray“, „Malve“ und „Kapitänsblau“ erhältlich. Zusätzlich sind Armbänder in den Farben „Zitronengrau“, „Dark Olive“ und „French Blue“ sowie für den Oberarm in Schwarz – jeweils in zwei Größen (S–M: 120 bis 200 mm; L–XL: 145 bis 240 mm). Das Cirqa-Band ist ab dem 24. Juli über die Garmin-Webseite erhältlich und kostet 199,99 Euro [5].
URL dieses Artikels:
https://www.heise.de/-11372241
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Make)
Der Taupunktlüfter hat sich in den letzten Jahren als zuverlässiges System zum Trocknen von Wohnungen und Häusern erwiesen. Nun gibt es ein Update der Software.
Das Projekt Taupunktlüfter [1] erfreut sich weiterhin hoher Beliebtheit. Es wurde vom Autor selbst nicht nur mit Daten-Logging [2] versehen, sondern auch zum Radonlüfter erweitert. [3] Weiterhin wird es in vielen weiteren Projekten zitiert, sei es als Taupunktlüfter mit Shelly-Geräten [4] oder in das Smart Home eingebunden [5].
Jetzt gibt es Neuerungen für das Originalprojekt des Taupunktlüfters. Der Autor Ulli Schmerold schreibt:
„Angestoßen wurde das neue Taupunktlüfter-Update von der Chartplattform Highcharts, die bisher das Rendern der Taupunktlüfter-Charts erledigt hatte. Ohne Vorankündigung wurden bei allen Taupunktlüftern keine Charts mehr generiert, ich vermute seit Anfang 2026. Grund dafür war eine Änderung der Lizenzpolitik von Highcharts.“
Und weiter:
„So war ich gezwungen, ein anderes kostenloses Chartprojekt zu suchen, Highcharts aus dem Code herauszuoperieren und meinen neuen Favoriten Chart.js einzubauen – ein nicht unerheblicher Aufwand. Und wenn ich dann ohnehin schon dabei bin, kann ich auch gleich so einiges, was von Lesern (Taupunktlüfter-Betreibern) herangetragen wurde, umsetzen.“
Herausgekommen ist eine neue Version 7.0 mit folgenden Verbesserungen. Das Update ist für vorhandene Installationen schnell selbst erledigt [6] oder im heise-Shop als kompletter Bausatz [7] (ohne Lüfter, Kabel und Gehäuse) erhältlich.
Durch Supportanfragen und Fehlermeldungen wurde ein wohlbekanntes Problem bei DHT22-Sensoren auffällig. Sie sind sehr anfällig für elektromagnetische Störungen (EMI = Electromagnetic Interference). Wenn etwa Rollladenmotoren schalten, entstehen Spannungsspitzen und Magnetfelder, die die empfindliche digitale Kommunikation des DHT22 stören.
Beheben lässt sich dieses Problem durch jeweils einen 10-kΩ-Pull-up-Widerstand zwischen den DATA-Pins (Pin5 und Pin15) und der VCC (3.3 V) Leitung. Anderenfalls zieht jede kleine Funkstörung die Sensor-Datenleitung auf Masse und der Sensor liefert dann Datenmüll.
Diese Widerstände können entweder direkt mit in die Sensorbuchsen geschraubt oder auf die Rückseite der Platine an die entsprechenden Anschlüsse gelötet werden.
Die Signalisierung vom Radonmessgerät erfolgt über einen Stecker auf dem praktischen Lochraster auf der Platine.
Zu beachten: Es wird nicht der jeweilige Radonwert, sondern nur das Start- und Stoppsignal für den Radonlüfter übermittelt. Somit kann kein konkreter Becquerelwert am Taupunktlüfterdisplay abgelesen werden, aber die Zeit, die der Lüfter aufgrund zu hoher Radonwerte aktiv war.
Für die Zukunft plant der Autor, dass alle Einstellungen, die bisher nur direkt an der Taupunktlüfter-Steuerung verändert werden konnten, auch im Webbrowser eingetragen werden können.
Außerdem soll es dann möglich sein, wahlweise DHT22- oder BME/BMP280- Sensoren an den Taupunktlüfter anzuschließen.
URL dieses Artikels:
https://www.heise.de/-11371715
Links in diesem Artikel:
Copyright © 2026 Heise Medien
iPhone im Wiederherstellungsmodus: Nützliche Werkzeuge.
Apple ermöglicht es künftig, bestimmte Probleme am iPhone direkt zu überprüfen. So arbeitet der neue Modus.
Wenn bislang beim iPhone im Hinblick auf die Software etwas kaputtgeht, benötigt man einen Mac oder PC, um den Wiederherstellungsmodus zu starten. Zwar hatte Apple mit iOS 26 einen neuen Wiederherstellungsassistenten [1] direkt auf die Hardware geholt, der erscheint aber nur automatisch, wenn bestimmte Probleme festgestellt werden. Er kann also vom Nutzer nicht selbst aktiviert werden. Mit iOS 27, das derzeit im Betatest bei Entwicklern und der interessierten Öffentlichkeit [2] ist, ändert sich das: Nutzer können direkt in einen neuen Recovery-Modus [3] booten, wenn sie das wünschen. Die Vorgehensweise erinnert dabei an macOS.
Der erweiterte Wiederherstellungsmodus ist unter iOS 27 und iPadOS 27 verfügbar. Um ihn zu aktivieren, müssen iPhone oder iPad zunächst vollständig heruntergefahren sein. Dann drückt man die Einschalttaste und hält diese gedrückt, bis ein Hinweis auftaucht, dass der Recovery-Modus jetzt aufgerufen wird. Nach einer weiteren kurzen Wartezeit kann man die Taste dann loslassen, und es dauert etwas, bis der Bootvorgang abgeschlossen ist. Eine Kabelverbindung zu einem anderen Gerät sollte man zuvor trennen, bei unseren Versuchen mit angeschlossenem Netzteil landeten wir zwischenzeitlich im regulären Wiederherstellungsmodus mit Mac oder PC.
Der Wiederherstellungsassistent bietet aktuell fünf Möglichkeiten. Man kann automatisch nach Problemen forschen lassen, um diese zu lösen – das gilt für Softwarefehler. Es ist außerdem möglich, direkt ein Softwareupdate einzuleiten, ohne dass iPhone oder iPad regulär gebootet wurden. Ein Diagnostik-Modus sammelt Hard- und Softwaredaten für den Apple Support. Schließlich kann man das gesamte Gerät auch löschen (inklusive Inhalten) sowie den bekannten Wiederherstellungsmodus per Mac oder PC auslösen. Außerdem gibt es noch zwei weitere Menüpunkte: Spracheinstellungen sowie die Möglichkeit, den Wiederherstellungsassistenten wieder zu verlassen.
Alle Funktionen, die sensibel sind, schützt Apple mit der iPhone-PIN. So ist es nicht möglich, das Gerät aus dem Wiederherstellungsassistenten zu löschen, ohne diese zu kennen. Auch werden so nicht automatisch Fernlöschung und die Trackingmöglichkeiten für die Besitzer deaktiviert, diese bleiben weiter aktiv. Im Modus Diagnose und Reparatur lassen sich auch wichtige iPhone-Daten wie Seriennummer und IMEIs auslesen.
Wird Internet-Zugriff benötigt und sind keine eSIMs oder SIM-Karten vorhanden, können die verschiedenen Modi auch auf ein WLAN zugreifen. Dafür wird allerdings das Passwort benötigt. Wie gut die Selbstreparatur tatsächlich klappt, bleibt abzuwarten. Denkbar ist unter anderem, dass Apple Probleme im iPhone-Dateisystem behebt.
URL dieses Artikels:
https://www.heise.de/-11370166
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Bald neue iPhones im Anmarsch: Im September ist es soweit.
(Bild: KaterynaSypailova / Shutterstock)
In gut zwei Monaten findet Apples nächste iPhone-Keynote statt. Für die Pro-Modelle plant Apple einige Verbesserungen. Die fünf wichtigsten im Überblick.
Apples Herbst-Keynote mit den neuen iPhones verläuft in diesem Jahr womöglich anders als gewohnt: Die Gerüchteküche glaubt fest daran, dass es dieses Mal nur drei neue Geräte gibt, während weitere drei Modelle [1] (iPhone 18, 18e und Air 2) erst im Frühjahr 2027 folgen. Für September angepeilt sind demnach neben dem lange erwarteten ersten iPhone-Foldable („Ultra“) [2] zwei neue iPhone-Pro-Varianten, nämlich 18 Pro und 18 Pro Max. Diese dürften auch die meistverkauften iPhones zum Weihnachtsgeschäft werden. Hier fünf Prognosen, was die neue Hardware leisten könnte.
Apple plant angeblich, sowohl iPhone 18 Pro als auch 18 Pro Max erstmals mit einer variablen Blende auszustatten und auch die Kamerasensorik an sich zu vergrößern. Laut Leaker-Berichten könnte dies zu einer Verdickung von rund zwei Millimetern führen [3]. Der eine Zentimeter Bauhöhe wäre somit im Bereich der Kamera-Plattform überschritten. Optisch von weitem erkennbar ist das wohl nicht, der Look von 18 Pro und 18 Pro Max ähnelt dem von 17 Pro und 17 Pro Max, allerdings gibt es eine Reihe neuer Farben, darunter eine Art Kirschton, heißt es.
Apple verbaut in den neuen Pro-Modellen erstmals den A20 Pro, der die erste Generation von 2-nm-Chips für Apple von TSMC darstellt. Weiterhin sollen der Apple-eigene N2-Netzwerkchip (WLAN, Bluetooth) und der Apple-eigene C2-Modemchip verbaut sein. Letzterer wird es angeblich aber nicht in die US-Modelle schaffen [4], diese bekommen Qualcomm-Technik, damit schnelles mmWave-5G unterstützt werden kann. Beim RAM ändert sich angeblich nichts, Apple bleibt bei 12 GByte.
Apple hat zwar – mit Ausnahme von Japan – seine Preise beim iPhone [5] bislang nicht erhöht. Die neuen Modelle sollen jedoch neue Einsteigspreise erhalten. Laut Bill-of-Materials-Schätzungen sollen allein die Komponentenkosten um bis zu 300 US-Dollar [6] steigen, was Apple so auch weitergeben könnte. Schätzungen zufolge könnte die Preiserhöhung aber auch bei 200 bis 250 Dollar landen (jeweils ohne Umsatzsteuer). Euro-Tarife dürften noch stärker anziehen. Aktuell liegt der Einsteigspreis beim iPhone 17 Pro bei 1299 Euro, beim 17 Pro Max gar bei 1449 Euro.
Apples Dynamic Island – beziehungsweise die für Face ID und Selfie-Kamera benötigte Einstanzung im Bildschirm – soll etwas schrumpfen. Dazu könnten Teile des TrueDepth-Kameramoduls unter den Bildschirm wandern, etwa der Infrarot-Projektor. Eine komplette Verlagerung der Gesichtserkennung unter den Screen bereitet Apple aber angeblich frühestens für das Jubiläums-iPhone im kommenden Jahr vor.
Apple wird beim iPhone 18 Pro und 18 Pro Max angeblich die Kamerasteuerung vereinfachen. So könnte der kapazitive Sensor wegfallen und Apple stattdessen nur noch den ebenfalls integrierten Drucksensor verwenden. An der Funktionalität ändert das angeblich nichts. Das Kamerasystem an sich verspricht bessere Bilder, ob der Sensor tatsächlich von Samsung stammt und nicht mehr von Sony [7], bleibt abzuwarten. In Sachen Satelliteninternet dreht Apple nochmals etwas auf: Angeblich soll mit den neuen Geräten auch ein echtes Surfen möglich sein und nicht nur Notrufe und Chats [8].
Momentan ist noch unklar, wann Apple seine neuen Modelle vorstellt. Denkbar ist Anfang bis Mitte September. Die letzte iPhone-Keynote fand am 9. September 2025 statt. Die beiden neuen Pro-Modelle dürften noch im September in die Auslieferung gehen.
URL dieses Artikels:
https://www.heise.de/-11370906
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Schriftzug am US-Justizministerium Department of Justice.
(Bild: Lane V. Erickson / Shutterstock)
Es geht um Apples iPhone-Ökosystem: 2024 reichte das Department of Justice Klage ein. Nun gibt es Bestrebungen zu einer Einigung – mit ungewissem Ausgang.
Apple hat erste Versuche gestartet, ein großangelegtes US-Kartellverfahren abzuwenden. Laut einem Bericht der Finanznachrichtenagentur Bloomberg hätten vor kurzem „frühe Gespräche“ zwischen Apple und den klagenden Behörden begonnen. Es gebe aber keine Garantie dafür, dass es zu einer außergerichtlichen Einigung komme. Ein Gerichtstermin wurde bislang noch nicht angesetzt. Die Bemühungen gingen offenbar von Apple aus. Das Unternehmen habe „mehrfach“ Angebote unterbreitet, den Fall beizulegen. Genauere Vorschläge kamen demnach in den vergangenen Wochen auf den Tisch – und zwar von beiden Seiten.
Nicht nur in der Europäischen Union [1], in Japan [2] oder Indien [3] hat Apple Ärger mit Regulierungs- und Kartellbehörden wegen möglicher Wettbewerbsverstöße, sondern auch in seiner Heimat. Das US-Justizministerium (Department of Justice, DoJ) verfolgt dort seit mehreren Jahren ein Verfahren gegen Apples gut integriertes Ökosystem [4], das seiner Ansicht nach Konkurrenten ausbremst. Die 2024 eingereichte Klage behauptet unter anderem, dass Apple den Markt für High-End-Smartphones „monopolisiert“ habe.
Zudem stoppe Apple im App Store sogenannte Super-Apps, also Programme, die im Sinne von WeChat [5] diverse Funktionen in einer Anwendung zusammenfassen und auch Mini-Apps durch externe Entwickler erlauben. Der App Store und dessen Provision spielen in dem Verfahren hingegen nur eine Nebenrolle, da hierzu bereits Privatklagen laufen [6]. Das DoJ wirft Apple allerdings vor, unter anderem externe Messaging-Apps und Wallets für Zahlungsmittel auszubremsen, zudem Computeruhren von Drittanbietern. Auch die Tatsache, dass die Apple Watch nur mit dem iPhone arbeitet, wird kritisch beäugt.
Laut Bloomberg [7] gab es weder von Apple noch vom US-Justizministerium eine Antwort auf die Bitte nach einem Kommentar. Apple war es zunächst nicht gelungen, die Klage im vergangenen Sommer abweisen zu lassen. Die Klage war ursprünglich noch unter der vorherigen Administration unter US-Präsident Joe Biden eingereicht worden. Es ist denkbar, dass das DoJ unter Donald Trump die Situation anders sieht. Allerdings ist nicht nur die Bundesbehörde Kläger, sondern eine Gruppe von 19 Bundesstaaten samt District of Columbia (Washington, D.C.). Ob die Justizministerien der mitklagenden Staaten in die Gespräche eingeschaltet sind, blieb zunächst unklar.
Apple gelang es kürzlich, das Gericht davon zu überzeugen, das Sammeln von Daten bei US-Bundesbehörden [8] zu erlauben, um zu belegen, dass es ausreichend Wettbewerb im Smartphone-Markt gibt. Apple darf demnach auch Informationen vom Heimatschutzministerium, dem US-Verteidigungsministerium sowie vom Geheimdienst CIA einholen.
URL dieses Artikels:
https://www.heise.de/-11370162
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Dmitri T/Shutterstock.com)
Die Houthis sperren den Seeweg nach Saudi-Arabien. Goldman Sachs warnt vor einem Brent-Ölpreis von 120 Dollar pro Barrel.
Die Straße von Hormus ist faktisch geschlossen, und jetzt droht auch der Seeverkehr durch das Rote Meer zu kippen. Der Grund dafür sind die Houthi-Rebellen im Jemen, die am Montag eine Seeblockade gegen Saudi-Arabien [1] verhängt haben – mit sofortiger Wirkung, wie Militärsprecher Yahya Saree erklärte [2].
Die Houthis begründen den Schritt mit den Worten "Belagerung gegen Belagerung", also als Vergeltung für die saudische Blockade jemenitischer Häfen und Flughäfen.
Der Ölpreis dürfte dadurch weiter steigen, einmal weil sich das Angebot verknappen könnte, aber auch, weil die Transportwege länger werden. Der Brent-Ölpreis notiert laut Bloomberg bereits bei 89 US-Dollar pro Barrel [3], ein Plus von über 20 Prozent allein in diesem Monat.
In Saudi-Arabien trifft die Drohung der Houthis einen Nerv. Seitdem der Iran-Krieg den Tankerverkehr durch die Straße von Hormus faktisch zum Erliegen gebracht hat, pumpt das Königreich sein Rohöl über die 1.202 Kilometer lange Ost-West-Pipeline zum Rotmeerhafen Yanbu.
Rund 2,5 Millionen Barrel pro Tag laufen dort auf Tanker, die anschließend durch die Meerenge von Bab el-Mandeb müssen, direkt an der jemenitischen Küste vorbei, von wo aus die Houthis mit Raketen und Drohnen [4] auf Schiffe schießen können.
Parallel dazu geht der Krieg gegen den Iran unvermindert weiter, und die Islamischen Revolutionsgarden feuern im Gegenzug auf Schiffe, welche die Straße von Hormus ohne ihre Erlaubnis passieren wollen.
Am Dienstag traf ein Projektil den kuwaitischen Produkttanker "Kaifan" nordöstlich von Limah in Oman, wie Bloomberg unter Berufung auf die EOS Risk Group berichtet [5]. In der Woche bis zum 19. Juli passierten im Schnitt nur noch sieben Tanker pro Tag die Meerenge – die Hälfte der Vorwoche, so S&P Global Energy.
Die Sinokor Group aus Südkorea etwa bietet Besatzungen laut Bloomberg sechs Monatsgehälter Bonus für eine Durchfahrt.
Die ökonomischen Folgen zeichnen sich längst ab. Goldman Sachs hält laut Bloomberg einen Brent-Preis von über 120 Dollar im vierten Quartal für möglich, sollten die Störungen anhalten.
Rob Thummel von Tortoise Capital warnt gegenüber Bloomberg, die geschrumpften Lagerbestände ließen "einfach nicht viel Spielraum für Fehler".
Die IEA stufte schon im März die Lage als größte Versorgungsstörung in der Geschichte des globalen Ölmarkts ein, da mindestens 8 Millionen Barrel pro Tag ausfielen.
Die USA fliegen den zehnten Tag in Folge Angriffe auf iranische Militärziele, Außenminister Marco Rubio schließt Verhandlungen vorerst aus.
Ob die Houthis ihre Blockade tatsächlich durchsetzen können, bleibt offen, aber ihr Arsenal aus Anti-Schiff-Raketen und Kamikaze-Drohnen reicht aus, um Reeder großflächig abzuschrecken.
Anoop Singh von Oil Brokerage brachte es gegenüber Bloomberg auf den Punkt: "Wenn es eine alternative Route gibt, wird man diese wählen".
URL dieses Artikels:
https://www.heise.de/-11372207
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Kimi K3 könnte proprietäre US-Modelle unter Druck setzen
(Bild: Samuel Boivin/Shutterstock.com)
Moonshot AIs Kimi K3 ist das größte offen zugängliche KI-Modell der Welt. Die Nachfrage überrollte die Server binnen 48 Stunden. Was kann das neue Modell?
Nut wenige Wochen nach Anthropics Durchbruch mit "Fable" gibt es bereits einen neuen aufsteigenden Stern am KI-Himmel: Mit Mit 2,8 Billionen Parametern ist Kimi K3 nach eigenen Angaben von Moonshot AI das größte KI-Modell, das bislang als Open-Weight [1] (bei dem die Modellparameter frei verfügbar sind) veröffentlicht wurde. Das in Peking ansässige Startup hat damit eine Welle ausgelöst, die an den Finanzmärkten ebenso spürbar ist wie in der KI-Branche selbst.
Die Nvidia-Aktie gab am Freitag um 2,2 Prozent nach, die Papiere von Applied Materials verloren sogar mehr als fünf Prozent – ein Echo des sogenannten "DeepSeek-Moments" Anfang 2015, als das chinesische Modell R1 den Marktwert von Nvidia an einem einzigen Tag um fast 600 Milliarden US-Dollar einbrechen ließ. Doch was kann das neue Modell wirklich?
Moonshot AI gibt in einem Beitrag auf seinem technischen Blog [2] an, dass Kimi K3 alle Konkurrenzmodelle mit Ausnahme von Anthropics "Claude Fable 5" und OpenAIs "GPT-5.6 Sol" übertreffe.
In der unabhängigen Entwickler-Plattform Arena, die Modelle in Blindtests bewertet, erreichte K3 mit 1.679 Punkten den ersten Platz in der Kategorie Frontend-Code-Entwicklung [3] – noch vor Claude Fable 5. In der agentischen Disziplin (also beim autonomen Lösen komplexer Aufgaben) belegt K3 den vierten Platz, hinter GPT 5.6 (Sol) und vor Claude Sonnet 5.
"Trotz anhaltender Einschränkungen bei der Hardware- und Rechenkapazität in China zeigt K3, dass eine Skalierung des Vortrainings in Verbindung mit architektonischen Innovationen nach wie vor erhebliche Leistungssprünge für chinesische Vorzeigemodelle bewirken kann", kommentierten [4] Analysten der Bank of America in einer von Alex Liu verfassten Analyse.
Die Veröffentlichung des Modells hat indes einen kleinen Hype ausgelöst: Die Nachfrage überstieg innerhalb von 48 Stunden nach der Veröffentlichung die verfügbaren GPU-Ressourcen. Auf der Plattform X teilte Moonshot mit [5], die Kapazitätsgrenzen seien "fast erreicht". Um bestehende Nutzer zu schützen und Qualitätseinbußen zu vermeiden, wurden neue Abonnements vorübergehend gestoppt. Bestehende zahlende Kunden seien nicht betroffen.
Einen konkreten Zeitplan für die Wiederaufnahme neuer Abonnements nannte das Unternehmen nicht. Parallel dazu kündigte Moonshot eine Neustrukturierung seiner Tarife an.
Der Vergleich mit DeepSeek, das ebenfalls frei zugänglich ist [6], liegt nahe, greift aber nur bedingt. DeepSeek R1 hatte Anfang 2025 vor allem deshalb für Aufruhr gesorgt, weil es Training und Betrieb von KI-Modellen deutlich kostengünstiger machte und damit die Annahme erschütterte, dass für leistungsstarke KI zwingend enorme Rechenleistung nötig sei (Telepolis berichtete [7]).
Kimi K3 verbessert zwar ebenfalls die Recheneffizienz – die sogenannte Sparsity-Rate, also der Anteil der pro Aufgabe tatsächlich aktivierten Parameter an der Gesamtgröße des Modells, und erreicht laut [8] Bloomberg-Daten einen Rekordwert –, tut dies jedoch auf Basis eines deutlich größeren Modells.
Pro Token werden lediglich 16 der insgesamt 896 sogenannten "Experten" aktiviert, was rund 1,8 Prozent entspricht. Dennoch muss jeder der 2,8 Billionen Parameter im Arbeitsspeicher vorgehalten werden. Selbst nach Komprimierung belegt das Modell noch rund 1,4 Terabyte Speicherplatz. Für den produktiven Einsatz empfiehlt Moonshot AI Cluster aus mindestens 64 Hochleistungsbeschleunigern.
Das bedeutet: Anders als DeepSeek dürfte Kimi K3 die Nachfrage nach leistungsstarker KI-Hardware nicht dämpfen, sondern eher aufrechterhalten – insbesondere nach Hochbandbreiten-Speicher von SK Hynix, nach Nvidia-KI-Systemen der neuesten Generation sowie nach fortschrittlicher Chipfertigung von TSMC.
Moonshot AI beschreibt zwei zentrale architektonische Neuerungen: "Kimi Delta Attention", ein hybrides lineares Aufmerksamkeitsverfahren, sowie "Attention Residuals", die verändern, wie Informationen zwischen den Schichten des Modells weitergegeben werden.
Das Modell verfügt über ein Kontextfenster von einer Million Token und unterstützt nativ die Verarbeitung von Bildern. Für das Training wurde ein sogenanntes quantisierungsbasiertes Verfahren eingesetzt, das auf MXFP4-Gewichten [9] und MXFP8-Aktivierungen [10] basiert – eine Kombination, die laut Moonshot auf möglichst vielen Hardware-Plattformen lauffähig sein soll.
Ein Benchmarking der Kernel-Optimierung führte Moonshot auf Nvidias H200 sowie auf einem nicht namentlich genannten "GPGPU eines alternativen Herstellers" durch.
Daneben kommt MiniTriton zum Einsatz, ein von Moonshot selbst entwickelter Compiler, der auf dem quelloffenen Triton-Framework basiert. Bemerkenswert ist, dass Moonshot für Vergleichstests auch die Nvidia L20 nutzt – eine abgespeckte Grafikkarte, die unter den US-amerikanischen Exportbeschränkungen nach China verkauft werden darf.
Sämtliche bisher veröffentlichten Leistungswerte stammen von Moonshot selbst oder basieren auf API-Zugängen und lassen sich derzeit nicht unabhängig überprüfen.
Die vollständigen Modellgewichte sollen am 27. Juli öffentlich zugänglich gemacht werden. Unternehmen, die das Modell dann selbst lokal betreiben möchten, benötigen weiterhin umfangreiche KI-Hardware. Die API-Preise liegen bei 0,30 US-Dollar pro Million Cache-Treffer-Eingabe-Token, 3 US-Dollar bei Cache-Fehltreffern und 15 US-Dollar pro Million Ausgabe-Token.
Anthropic hatte Moonshot im Februar vorgeworfen [11], 3,4 Millionen Konversationen mit Claude-Modellen genutzt zu haben, um eigene Modelle durch sogenannte Destillation zu trainieren. Kimi K3 erreicht in Benchmarks nun Werte, die nahe an den Modellen liegen, die in diesem Vorwurf genannt wurden. Derartige Vorwürfe sind in der Branche allerdings keine Seltenheit, auch OpenAI-Ingenieure sollen sich bereits bei Anthropic bedient haben [12].
Moonshot AI nutzt die Aufmerksamkeit rund um Kimi K3, um den eigenen Börsengang voranzutreiben. Das Unternehmen hat den entsprechenden Aktionärsbeschluss an seine Investoren verteilt und bittet um Zustimmung zu einem Börsengang in Hongkong.
Laut [13] Bloomberg könnte eine laufende Finanzierungsrunde das erst drei Jahre alte Startup mit mehr als 30 Milliarden US-Dollar bewerten. Als Grundlage dient ein jährlicher wiederkehrender Umsatz, der im Juni 300 Millionen US-Dollar erreicht haben soll.
Für US-amerikanische KI-Unternehmen wie OpenAI und Anthropic, die selbst Börsengänge erwägen, ist das eine ungünstige Entwicklung: Sollte Moonshot AI trotz der Größe seines Modells kostengünstigere Dienste anbieten können, dürfte das auf die Bewertungen der amerikanischen Konkurrenz drücken.
URL dieses Artikels:
https://www.heise.de/-11371967
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Bild: Shutterstock.com
Wir wollen im Urlaub möglichst nichts tun. Vielleicht ist genau das der Grund, warum Erholung nicht funktioniert.
Endlich frei. In 14 Bundesländern haben die Sommerferien bereits begonnen. Nur Baden-Württemberg und Bayern warten noch. Deutschland fährt in den Urlaub.
Jedes Jahr erscheinen Ende August Texte darüber, wie sich das Urlaubsgefühl in den Alltag retten lässt. Fast alle behandeln Erholung wie einen Vorrat, den man nur langsam genug aufbrauchen müsse.
Das hat im vergangenen Jahr nicht funktioniert, im Jahr davor ebenso wenig und vermutlich auch in den fünf Jahren zuvor nicht. Sollte man überhaupt ein entspanntes Gefühl aus dem Urlaub mitgebracht haben, wird es rasch zur Erinnerung.
Spätestens nach einer Arbeitswoche ist die Erholung verflogen, und die illuminierten und bronzierten Gesichter sind wieder zu Alltagsmasken aus Gummi und Käse geworden.
Vielleicht verstehen wir Erholung falsch.
Das legt ein Artikel des Psychiaters Richard A. Friedman nahe, den das US-Magazin The Atlantic derzeit wieder aus seinem Archiv hervorholt. Friedmans Text "Beach Vacationers Are Doing It Wrong" [1] (Strandurlauber machen es falsch) erschien bereits 2022. Seine zentrale These steht im Untertitel: Wer wirklich abschalten will, sollte sich körperlich anstrengen.
Die Empfehlung passt verdächtig gut in eine Gegenwart, in der selbst Erholung zur Optimierungsaufgabe geworden ist: Schritte zählen, Laufstrecken dokumentieren, Schlafwerte prüfen, Proteine berechnen. Soll dieser Leistungsbetrieb nun auch noch den Urlaub erobern?
Viele Menschen träumen schließlich vom Liegestuhl, vom Buch, vom Strand und davon, möglichst nichts tun zu müssen. Das ist vollkommen verständlich.
Seine Antwort widerspricht fast allem, was wir mit Erholung verbinden.
Wer reglos am Strand liegt, warnt Friedman, findet sich womöglich nicht in tiefer Entspannung wieder, sondern in Langeweile, Unruhe und den eigenen Problemen. Verbringen wir den Urlaub also schlicht falsch?
"Ein besserer Urlaub ist einer, in dem intensive körperliche Aktivität eine zentrale Rolle spielt. So machen Sie nicht nur eine Pause von Arbeit und Alltag, sondern auch von der Tyrannei der Selbstbezogenheit", schreibt Friedman.
Sein Argument lautet allerdings nicht einfach: Sport ist gesund. Es geht um etwas anderes. Wer den ganzen Tag untätig ist, verbringt womöglich erstaunlich viel Zeit mit sich selbst. Und genau das ist psychologisch nicht immer angenehm.
Der eigentliche Gegner in Friedmans Text ist das sogenannte Mind-Wandering, das ziellose Kreisen der Gedanken. Dabei verbindet er Psychologie, Neurowissenschaft und Alltagserfahrung.
Jeder kennt das. Man liegt am Strand. Nach zwanzig Minuten denkt man an den Chef und die Kollegen. Dann an die Steuer. An den Gesundheitscheck. An die Kinder. Schließlich an die gesamte Weltlage.
Der Körper mag am Atlantikstrand liegen, der Kopf ist längst wieder im Büro.
Friedman will deshalb auf eine weitergehende Idee hinaus: Eigentliche Erholung könnte darin bestehen, für einige Stunden aus sich selbst herauszukommen.
Dafür kommen viele Tätigkeiten infrage: Radfahren, Bergsteigen, Segeln, Kajakfahren, Tauchen, Klettern, Gartenarbeit oder Kochen. Nicht der Sport ist entscheidend, sondern dass eine Tätigkeit unsere Aufmerksamkeit so sehr beansprucht, dass das ständige Nachdenken über uns selbst für eine Weile verstummt.
Das passt durchaus zu unserer Zeit. Selftracking, Selfcare, Selbstoptimierung und soziale Medien halten das eigene Ich permanent unter Beobachtung. Wir prüfen unsere Leistung, unsere Stimmung, unseren Schlaf, unsere Wirkung und unsere Identität. Selbst Entspannung wird dabei leicht zu einem weiteren Projekt der Selbstkontrolle.
Urlaub, so ließe sich Friedmans Gedanke zuspitzen, sollte deshalb auch Urlaub vom eigenen Ich sein.
Dabei stehen sich heute scheinbar zwei Urlaubsideale gegenüber. Auf der einen Seite Entschleunigung, Digital Detox, Ausschlafen und Nichtstun. Auf der anderen Seite Trailrunning, Bikepacking, Surfcamps, Pilgerwege und Alpenüberquerungen.
Doch womöglich suchen beide dasselbe: nicht Leistung, sondern Gegenwart. Einen Zustand, in dem man weder den vergangenen Arbeitswochen nachhängt noch die kommenden bereits vorwegnimmt.
Vielleicht erinnern wir uns an aktive Urlaube deshalb so lange, weil sie uns nicht nur aus dem Alltag herausführen, sondern für einige Stunden auch aus uns selbst.
URL dieses Artikels:
https://www.heise.de/-11372121
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach / iX / KI)
Die neue Assess-Erweiterung von Spec Kit 0.13 sortiert automatisiert Ideen, bevor sie in eine Spec eingehen. Außerdem beseitigt Spec Kit eine Reihe an Bugs.
Die neue Version 0.13 von Spec Kit, GitHubs Werkzeug für Spec-driven Development, enthält eine neue Extension zur Ideenbewertung sowie kleine Korrekturen für mehr Stabilität und weniger Fehler.
Die neue Extension [1] Idea Assessment Pipeline (assess) schaltet einen weiteren, optionalen Schritt vor den bestehenden Spec-driven-Workflow. Hier lassen sich Ideen rollenneutral testen und bewerten [2], bevor sie in eine Spec übergehen. Das erfolgt in fünf Schritten: Rohe Idee erfassen, Evidenz sammeln, das Problem schärfen, ein Konzept entwerfen und schließlich entscheiden: Go, klären oder Kill. Das positive Urteil überführt die Idee in eine Spec: /speckit.specify.
Bugfixes betreffen die Authentifizierung der Azure-DevOps-CLI: Erhielt das Tool eine nicht dekodierbare Antwort, führte das zum stillen Crash, statt ein erwartetes None auszugeben. Gefixt hat das Team auch unklare Fehlermeldungen bei nicht korrekten Bundle-Download-URLs. Spec Kit wirft jetzt einen klar benannten BundlerError aus. Außerdem ersetzt ein PresetValidationError den bisherigen unklareren ValueError bei ungültigen Katalog-URLs.
Als Tool für das Spec-driven Development plant und steuert Spec Kit die Arbeit von Coding-Agenten. Specs dienen dabei als Kern für Planung, Entwicklung, Testing und Doku. Die Specs liegen oft in Markdown vor und dienen als Single Source of Truth. Dabei arbeitet Spec Kit laut Projekt mit 35 Tools zusammen, darunter GitHub Copilot, Gemini oder Codex. Spec-driven Development [3] steigt in der Bedeutung bei Entwicklerinnen und Entwicklern, ein ähnliches Tool ist OpenSpec [4].
URL dieses Artikels:
https://www.heise.de/-11371623
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Wie Personen mit Autismusdiagnose ihre Fähigkeiten gut im Software-Testing einsetzen können, erklären Helmut Pichler und Markus Kalbhenn.
Menschen mit Autismusdiagnose, die im Wartezimmer spontan 48 Rechtschreibfehler in einer Illustrierten zählen, bevor das Gespräch überhaupt beginnt: Darüber sprechen Helmut Pichler und Markus Kalbhenn mit Richard Seidl. Es erklärt besser als jede Theorie, warum genau diese Fähigkeiten im Software-Testing so gut ankommen. Die drei sprechen darüber, wie das Ausbildungsprogramm TestingPRO [1], in dem Menschen aus dem neurodivergenten Spektrum als Softwaretester ausgebildet werden, aufgebaut ist und welche Anpassungen im Training wirklich den Unterschied machen. Sie besprechen auch, was Unternehmen konkret brauchen, damit die Zusammenarbeit funktioniert. Dabei geht es nicht nur um Pausen und ruhige Räume, sondern auch darum, wie klare Aufgabenstellungen und ein fester Tagesrhythmus aus einer unsicheren Situation ein gutes Arbeitsverhältnis machen können.
„Im Software-Testing, im Qualitätsmanagement sind diese Personen von ihrer Kapazität her, von ihren Potenzialen wie ein Ferrari.“ – Markus Kalbhenn
Helmut Pichler [3] ist ein echter „Vollblut‑Tester/-Berater/-Trainer“, der seit Jahren mit unglaublicher Leidenschaft die Softwaretest‑Community prägt und weltweit Standards mitgestaltet. Als Ehren-Präsident vom Austrian Testing Board und langjähriger Botschafter auf internationalen Konferenzen bringt er Menschen zusammen, inspiriert sie und zeigt, wie lebendig Qualitätssicherung sein kann. Mit seinem Know-how als Trainer, Berater und Co-Autor von „Agile Testing“ gilt er im deutschsprachigen Raum längst als eines der Urgesteine und bleibt trotzdem immer am Puls der Zeit. Eines seiner Herzensprojekte, das er federführend mit konzipiert, ist seit nun 10 Jahren TestingPRO.
Markus Kalbhenn [4] ist ein erfahrener Experte im Personalmanagement, der auf 30 Jahre Erfahrung im Recruiting- und Tech-Bereich zurückblickt. In der ETC – Enterprise Training Center GmbH hat er den Bereich Talent Services mit aufgebaut und setzt dort neue Impulse in der IT-Personalvermittlung. Sein Fokus liegt auf der Entwicklung innovativer Recruiting-Methoden, die über konventionelle Ansätze hinausgehen, um dem Fachkräftemangel in der IT-Branche entgegenzuwirken. Besonders hervorzuheben ist sein Engagement für die IT-Ausbildungsprogramme TestingPro und INCLUSIVE-IT, die Menschen mit Behinderungen den Zugang zu IT-Karrieren ermöglichen. Als ausgebildeter Pädagoge und zertifizierter CSR-Berater verbindet er soziale Verantwortung mit wirtschaftlicher Effizienz bei der Besetzung technischer Rollen.
Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.
Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar [5].
URL dieses Artikels:
https://www.heise.de/-11371595
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Maika Möbus / KI / iX)
So funktionieren Passkeys: Der erste Teil der Praxis-Serie für Entwickler zeigt im Detail die Architektur, die auf FIDO2 und WebAuthn aufbaut.
Passwörter sind nicht deshalb unsicher, weil Menschen nachlässig damit umgehen – sie sind strukturell gebrochen. Das zugrunde liegende Modell beruht auf einem geteilten Geheimnis zwischen Client und Server, das abgefangen, erraten oder durch Datenlecks kompromittiert werden kann. Passkeys setzen an genau dieser Schwachstelle an und lösen das Problem auf architektonischer Ebene: Anstelle eines Passworts kommt ein kryptografisches Schlüsselpaar zum Einsatz. Der private Schlüssel verlässt niemals das Gerät – auf dem Server liegt ausschließlich der öffentliche Schlüssel.
Die Authentifizierung erfolgt lokal, durch Biometrie oder PIN, und ist kryptografisch an exakt eine Relying Party ID gebunden: Ein Credential, das für example.com registriert wurde, kann auf evil-example.com schlicht nicht verwendet werden – egal, ob es auf einem einzelnen Gerät liegt oder via iCloud auf mehreren. Phishing wird damit nicht nur erschwert, sondern technisch unmöglich gemacht.
Der erste Teil dieser Artikelserie steigt direkt auf Architekturebene ein und legt das technische Fundament: Wie greifen FIDO2, WebAuthn und CTAP2 ineinander? Welche Akteure sind an jeder WebAuthn-Interaktion beteiligt, und welche Aufgabe hat jeder von ihnen? Was liefern navigator.credentials.create() und navigator.credentials.get() zurück – und welche Informationen verbergen sich in der authData-Struktur, die beide Methoden durchzieht? Wer diese Fragen beantworten kann, verfügt über das Vokabular und Strukturverständnis, auf dem Registration und Authentication in Teil 2 aufbauen.
Zunächst lohnt sich eine kurze Begriffsklärung – nicht, weil die Begriffe kompliziert wären, sondern weil sie in der Praxis häufig durcheinandergeworfen werden, was zu Verwirrung bei der Implementierung führt.
FIDO2 ist der Oberbegriff. Er kombiniert zwei Spezifikationen, die auf unterschiedlichen Ebenen ansetzen: Web Authentication (WebAuthn) [1] und Client to Authenticator Protocol 2 (CTAP2) [2]. WebAuthn ist die Browser-API, die vom World Wide Web Consortium (W3C) standardisiert wird und die Kommunikation zwischen Webanwendung und Browser beschreibt. CTAP2 ist eine Spezifikation der FIDO Alliance [3] und regelt, wie der Browser beziehungsweise das Betriebssystem mit dem Authenticator kommuniziert. Beide Spezifikationen sind voneinander unabhängig standardisiert, aber konzeptuell aufeinander abgestimmt: WebAuthn definiert, was der Browser nach oben zur Webanwendung durchreicht; CTAP2 definiert, was der Browser nach unten zum Authenticator sendet.
Der Begriff Passkey ist jünger als die beiden Spezifikationen und dient als benutzerfreundliche Bezeichnung für Synced Credentials im Sinne der FIDO Alliance – also Multi-Device FIDO Credentials, die verschlüsselt über ein Cloud-Ökosystem wie iCloud Keychain oder den Google Password Manager auf mehrere Geräte repliziert werden können. Davon abzugrenzen sind Device-bound Passkeys: gerätegebundene Credentials, bei denen der private Schlüssel das Gerät nie verlässt, etwa auf einem Roaming Authenticator wie einem YubiKey. Technisch basieren beide Varianten identisch auf WebAuthn – der Unterschied liegt im Sicherheitsmodell des Authenticators, nicht in der API.
Jede WebAuthn-Interaktion – ob Registration oder Authentication – involviert genau drei Akteure. Ihr Zusammenspiel bestimmt, welche Daten ausgetauscht werden, wer welche Validierungen durchführt und wo das Vertrauen im System verankert ist. Es lohnt sich, diese drei Rollen klar auseinanderzuhalten, denn Verwechslungen führen direkt zu falschen Annahmen in der Serverlogik.
Die Relying Party (RP) ist die Webanwendung, genauer gesagt, der Server dahinter. Sie initiiert beide Ceremonies – Registration und Authentication –, indem sie Options-Objekte mit einer kryptografisch zufälligen Challenge bereitstellt, und validiert anschließend die Antwort des Authenticators. Identifiziert wird sie durch ihre rpId – typischerweise die Domain der Anwendung, etwa example.com. Wichtig dabei: Die rpId muss eine registrierbare Domain-Teilmenge der aktuellen Origin sein. Das bedeutet, dass example.com als rpId für login.example.com gültig ist, aber auth.other.com es nicht für example.com sein darf. Diese Einschränkung klingt technisch, ist aber der eigentliche Kern der Phishing-Resistenz – dazu gleich mehr. Was die RP am Ende einer erfolgreichen Registration speichert, ist ausschließlich der Public Key. Kein Passwort, kein geteiltes Geheimnis.
Zwischen Relying Party und Authenticator sitzt der WebAuthn-Client – in der Regel der Browser, manchmal das Betriebssystem. Er implementiert die navigator.credentials-API und übernimmt die Rolle des Vermittlers: Er empfängt die Options-Objekte der RP, leitet sie an den Authenticator weiter und verpackt dessen Antwort als PublicKeyCredential-Objekt zurück an die Webanwendung. Was dabei oft übersehen wird: Der Client führt eigene Sicherheitsprüfungen durch, bevor er den Authenticator überhaupt kontaktiert. Er validiert, ob die rpId zur aktuellen Origin passt – und bricht die Anfrage mit einem SecurityError ab, wenn das nicht der Fall ist. Das ist keine optionale Validierung, sondern eine Pflichtprüfung des Browsers.
Der Authenticator schließlich ist das Gerät oder die Software, die das Schlüsselpaar erzeugt und Assertions signiert. Konzeptuell ist er eine vollständig separate Vertrauensdomäne – weder Teil der Webanwendung noch des Browsers. Was der Authenticator signiert, haben weder Browser noch RP manipuliert. Genau das macht ihn zur Vertrauensquelle des gesamten Systems.
Das Vertrauensmodell folgt daraus fast zwingend: Der Server vertraut dem registrierten Public Key. Der Browser vertraut dem Authenticator über das CTAP2-Protokoll oder die Plattform-API. Und der Authenticator vertraut der lokalen Nutzerverifizierung – der Biometrie oder der PIN, die den privaten Schlüssel freischaltet. Kein Akteur muss dem anderen blind vertrauen, weil jeder Schritt kryptografisch abgesichert ist.
Es folgt ein genauerer Blick auf den Authenticator – denn nicht jeder Authenticator ist gleich. Die WebAuthn-Spezifikation unterscheidet grundlegend zwischen zwei Varianten, die sich in Sicherheitsmodell, Recovery-Optionen und praktischem Einsatzszenario erheblich unterscheiden. Ein Platform Authenticator ist fest in das Gerät integriert: Touch ID und Face ID auf Apple-Geräten, Windows Hello auf PC und Laptop, Android Biometrics auf Android-Smartphones.
Der private Schlüssel wird direkt im sicheren Element des Geräts erzeugt und gespeichert – in der Secure Enclave auf Apple-Hardware oder dem Trusted Platform Module (TPM) auf Windows-Systemen. Er verlässt diese Sicherheitsdomäne nicht. Bei Synced Passkeys [4] gibt es eine wichtige Nuance: Das Schlüsselmaterial wird verschlüsselt über die iCloud Keychain oder den Google Password Manager auf andere Geräte desselben Ökosystems repliziert. Der Schlüssel selbst bleibt dabei immer geschützt. Was synchronisiert wird, ist ein verschlüsselter Blob, kein Klartext-Schlüssel.
Ein Roaming Authenticator hingegen ist ein externes Gerät, das unabhängig vom Endgerät funktioniert. Die häufigsten Beispiele sind YubiKeys, FIDO2-USB-Sicherheitsschlüssel und NFC-Token. Sie sind per Definition Device-bound – das heißt, sie bleiben fest mit dem Gerät verbunden, auf dem sie erstellt wurden. Ein Cloud-Sync oder Transfer der Schlüssel zwischen Geräten ist nicht möglich. Besonders interessant ist dabei die Rolle des Smartphones als Cross-Device Authenticator: Es kann mittels QR-Code-Scan und einer verschlüsselten Bluetooth-Verbindung (Hybrid Transport) als Roaming Authenticator für andere Geräte dienen – beispielsweise für einen Desktop-Browser, der selbst über keinen Platform Authenticator verfügt.
(Bild: Yubinerd123 [5], CC BY-SA 4.0 [6], via Wikimedia Commons)
Eine verbreitete Fehlannahme ist, dass Synced Passkeys weniger phishingresistent seien als Hardware-Schlüssel. Das stimmt nicht. Phishing-Resistenz ist kein Merkmal eines bestimmten Authenticator-Typs, sondern sie ergibt sich direkt aus dem kryptografischen Origin-Binding der WebAuthn-Spezifikation. Zur Erinnerung: Ein Credential, das für example.com registriert wurde, kann schlicht nicht auf evil-example.com verwendet werden, egal ob es auf einem YubiKey oder in der iCloud liegt. Der Authenticator signiert immer die rpId, die der Browser mitliefert, und der Browser prüft zuvor, ob diese rpId zur aktuellen Origin passt. Der Unterschied liegt woanders: bei der Angriffsfläche des Schlüsselmaterials und bei den Recovery-Optionen. Ausführliche Informationen dazu folgen zu einem späteren Zeitpunkt in dieser Artikelserie.
In den AuthenticatorSelectionCriteria kann die RP über authenticatorAttachment festlegen, welchen Typ sie bevorzugt:
FreshRSS {
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"residentKey": "required",
"userVerification": "required"
}
}Listing 1: authenticatorSelection-Objekt mit Präferenz für Platform Authenticators
"platform" schränkt auf eingebettete Authenticators ein, "cross-platform" auf externe Geräte. "residentKey": "required" erzeugt ein Discoverable Credential – Voraussetzung für eine Anmeldung ohne Benutzernamen.
Bisher wurde hier WebAuthn als die Schnittstelle zwischen Webanwendung und Browser betrachtet. Doch wie kommuniziert der Browser eigentlich mit dem Authenticator? Dafür ist CTAP2 zuständig – und auch wenn Entwicklerinnen und Entwickler mit CTAP2 in der Regel nicht direkt in Berührung kommen, ist es sinnvoll, das Protokoll grob zu verstehen.
CTAP2 definiert das Nachrichtenformat und den Befehlssatz für diese Kommunikation. Nachrichten sind CBOR-kodiert (Concise Binary Object Representation, RFC 8949 [7]). Das binäre Format CBOR ist kompakter als JSON und eignet sich besonders für ressourcenbeschränkte Hardware wie einen USB-Sicherheitsschlüssel. Das Protokoll ist transport-agnostisch: Ein Windows-Browser kann genauso mit einem YubiKey über USB kommunizieren wie ein macOS-Browser mit einem NFC-Token, weil CTAP2 den Transport von der eigentlichen Nachrichtensemantik trennt.
Besonders hilfreich ist die direkte Zuordnung zwischen den CTAP2-Kommandos und den WebAuthn-Ceremonies: authenticatorMakeCredential entspricht der Registration – der Authenticator erzeugt ein neues Schlüsselpaar und gibt den Public Key zurück. authenticatorGetAssertion entspricht der Authentication – der Authenticator signiert eine Challenge mit dem gespeicherten Private Key. Die WebAuthn-API auf Browserebene ruft intern genau diese Kommandos auf. Mit anderen Worten: navigator.credentials.create() ist aus Sicht des Authenticators ein authenticatorMakeCredential, und navigator.credentials.get() ist ein authenticatorGetAssertion. Diese Zuordnung ist das konzeptuelle Bindeglied zwischen der JavaScript-API und dem Low-Level-Protokoll.
| Transport | Beschreibung | Plattformunterstützung |
| USB HID | kabelgebunden, hohe Zuverlässigkeit | Windows, macOS, Linux, Android |
| NFC | kontaktlos, kurze Reichweite | mobile Geräte, NFC-fähige PCs |
| BLE |
Bluetooth Low Energy (drahtlos, energiesparend, mittlere Reichweite) |
Mobile- und Desktop-Plattformen |
| Internal | plattforminterner Kanal (Platform Authenticator) | alle modernen Plattformen |
| Hybrid | QR-Code + BLE-Proximity (früher „caBLE“) | iOS 16+, Android 9+, moderne Desktopbrowser |
Tabelle 1: CTAP2-Transportmechanismen und deren Plattformunterstützung
Besonders erwähnenswert ist der Hybrid Transport, früher unter dem Namen caBLE bekannt. Er ermöglicht es, ein Smartphone als Roaming Authenticator für einen Desktopbrowser zu verwenden, der selbst keinen Platform Authenticator besitzt. Der Ablauf ist einfach: Der Desktop zeigt einen QR-Code an, das Smartphone scannt ihn, und die eigentliche Assertion wird anschließend über eine verschlüsselte Bluetooth-Verbindung übertragen. Aus Entwicklersicht ist dieser Transport vollständig transparent. Er läuft im Client ab und hat keinerlei Einfluss auf die WebAuthn-API oder die serverseitige Validierungslogik.
WebAuthn ist die API, mit der Entwicklerinnen und Entwickler direkt arbeiten. Sie besteht aus den zwei bereits erwähnten Methoden: navigator.credentials.create() für die Registration und navigator.credentials.get() für die Authentication. Beide geben ein PublicKeyCredential-Objekt zurück. Was sich unterscheidet, ist die response-Property darin. Bei der Registration enthält sie eine AuthenticatorAttestationResponse:
// Registration
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
}) as PublicKeyCredential;
const attestationResponse =
credential.response as AuthenticatorAttestationResponse;
// attestationResponse.clientDataJSON – ArrayBuffer
// attestationResponse.attestationObject – ArrayBuffer (CBOR-kodiert)
// attestationResponse.getPublicKey() – ArrayBuffer (DER-Format, convenience)Listing 2: create()-Aufruf und Zugriff auf die AuthenticatorAttestationResponse
Bei der Authentication enthält sie eine AuthenticatorAssertionResponse:
// Authentication
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
}) as PublicKeyCredential;
const assertionResponse =
assertion.response as AuthenticatorAssertionResponse;
// assertionResponse.clientDataJSON – ArrayBuffer
// assertionResponse.authenticatorData – ArrayBuffer
// assertionResponse.signature – ArrayBuffer
// assertionResponse.userHandle – ArrayBuffer | nullListing 3: get()-Aufruf und Zugriff auf die AuthenticatorAssertionResponse
Beide Responses teilen sich ein gemeinsames Feld: clientDataJSON. Es ist ein ArrayBuffer, der ein JSON-Objekt enthält – erzeugt vom Browser, nicht vom Authenticator. Es enthält type ("webauthn.create" oder "webauthn.get"), challenge als Base64url-String, origin und crossOrigin. Der entscheidende Punkt ist, dass origin und challenge Teil der späteren Signatur werden. Dadurch ist kryptografisch sichergestellt, dass die Antwort weder für eine andere Origin noch als Replay einer früheren Anfrage gültig ist. Das sind zwei Angriffsvektoren, gegen die klassische Passwörter strukturell keine Antwort haben.
Bei der Registration kommt zu clientDataJSON noch das attestationObject hinzu. Es ist CBOR-kodiert und enthält drei Felder: fmt (das Attestation-Format, zum Beispiel "packed", "tpm" oder "none"), attStmt (die formatspezifische Attestation-Aussage) und authData, die zentrale Datenstruktur, auf die der nächste Abschnitt eingeht. Bei der Authentication Response entfällt der Attestation-Wrapper. Dort steht authenticatorData direkt im Response-Objekt, zusammen mit signature und optional userHandle.
Es gibt dabei einige Fehlerszenarien, die in der Praxis regelmäßig auftauchen: Ein NotAllowedError erscheint, wenn der Nutzer die Anfrage abgelehnt hat oder das Timeout abgelaufen ist. Ein SecurityError signalisiert, dass die rpId nicht zur aktuellen Origin passt – ein häufiger Konfigurationsfehler in Entwicklungsumgebungen, wenn man zwischen localhost und einer lokalen Domain wechselt. Und ein AbortError tritt auf, wenn die Anfrage programmatisch über einen AbortController abgebrochen wurde. Das ist relevant, wenn Conditional UI und ein manuell ausgelöster Login-Flow gleichzeitig im Spiel sind und koordiniert werden müssen.
Wer verstehen will, was der Server bei der Validierung tatsächlich prüft, muss die authData kennen. Sie ist die Datenstruktur, die sich durch beide Ceremonies zieht – bei der Registration steckt sie im attestationObject, bei der Authentication erscheint sie direkt als authenticatorData. Ihr Layout ist in §6.1 der W3C-WebAuthn-Level-2-Spezifikation [8] exakt definiert: ein Byte-Array, aufgebaut aus fest definierten Feldern in einer fixen Reihenfolge.
| Offset | Länge | Feld | Beschreibung |
| 0 | 32 Bytes | rpIdHash | SHA-256-Hash der rpId |
| 32 | 1 Byte | flags | Bit-Feld mit Statusinformationen |
| 33 | 4 Bytes | signCount | Big Endian, Zähler für Replay-Schutz |
| 37 | variabel | attestedCredentialData | nur bei Registration, wenn Attested Credential Data Flag gesetzt |
| variabel | variabel | extensions | optional, nur wenn Extension Data Flag gesetzt |
Tabelle 2: Byte-Layout der authData (§6.1 WebAuthn Level 2)
Die ersten 32 Bytes sind der rpIdHash – der SHA-256-Hash der rpId. Das ist das Erste, was der Server prüfen muss: Stimmt dieser Hash mit dem Hash seiner eigenen rpId überein? Sofern er nicht stimmt, wurde die Antwort für eine andere Relying Party erzeugt und muss abgelehnt werden, ohne Ausnahme und ohne Fallback.
Byte 32 enthält das flags-Byte. Dieses Byte steuert den Großteil der Validierungslogik auf Serverseite. Es ist ein Bit-Feld – jedes Bit hat eine eigene Bedeutung. Das UP-Flag (Bit 0, User Presence) zeigt an, dass der Nutzer den Authenticator aktiv bedient hat – den YubiKey-Knopf gedrückt, das Gerät entsperrt, eine Geste ausgeführt. Es muss laut Spezifikation immer gesetzt sein; fehlt es, muss die RP die Antwort ablehnen. Das UV-Flag (Bit 2, User Verification) geht einen Schritt weiter: Es zeigt an, dass der Nutzer lokal verifiziert wurde, etwa durch Biometrie oder PIN. Server, die userVerification: "required" konfiguriert haben, müssen dieses Bit zwingend prüfen.
Für Synced Passkeys sind die beiden Bits BE (Bit 3, Backup Eligibility) und BS (Bit 4, Backup State) besonders relevant. BE zeigt an, ob das Credential überhaupt sync-fähig ist – also ob es sich um ein Multi-Device Credential handelt. BS zeigt an, ob es zum Zeitpunkt der Anfrage tatsächlich aktiv synchronisiert ist. Die Kombination BE=1, BS=1 bedeutet: aktiv synchronisiert. BE=1, BS=0 heißt: sync-fähig, aber aktuell nicht in der Cloud gesichert. BE=0 wiederum garantiert, dass das Credential Device-bound ist und das Gerät nie verlassen hat. Diese Unterscheidung ist für Hochsicherheitsszenarien relevant, in denen Synced Credentials bewusst ausgeschlossen werden sollen. Schließlich steuert das AT-Flag (Bit 6), ob attestedCredentialData in der authData vorhanden ist. Es wird bei der Registration gesetzt, nicht bei der Authentication.
// flags-Byte aus authData auslesen (authData ist ein Uint8Array)
function parseAuthDataFlags(authData) {
const flagsByte = authData[32];
return {
up: !!(flagsByte & 0x01), // Bit 0 – User Presence
uv: !!(flagsByte & 0x04), // Bit 2 – User Verification
be: !!(flagsByte & 0x08), // Bit 3 – Backup Eligibility
bs: !!(flagsByte & 0x10), // Bit 4 – Backup State
at: !!(flagsByte & 0x40), // Bit 6 – Attested Credential Data
ed: !!(flagsByte & 0x80), // Bit 7 – Extension Data
};
}Listing 4: flags-Byte aus authData auslesen, in JavaScript
Die Bytes 33 bis 36 enthalten den signCount – einen Big-Endian-Zähler, der bei jedem Authentifizierungsvorgang höher sein muss als der zuletzt vom Server gespeicherte Wert. Die Idee dahinter ist eine Art Klon-Detektion: Wäre ein privater Schlüssel kopiert worden, wäre der Counter irgendwann nicht mehr korrekt. Bei Synced Passkeys ist diese Logik allerdings kompromittiert. Da etwa ein iCloud-Passkey parallel auf iPhone, iPad und MacBook genutzt werden kann, ist ein konsistenter, monotoner Counter schlicht nicht gewährleistet. Viele Implementierungen setzen signCount deshalb dauerhaft auf 0. Server müssen das explizit behandeln. Wie genau, wird Teil 2 dieser Artikelserie klären.
Das letzte relevante Feld ist attestedCredentialData. Es ist nur bei der Registration vorhanden, wenn das Attested Credential Data Flag gesetzt ist. Es enthält drei Bestandteile, die für die serverseitige Speicherung direkt relevant sind. Die aaguid (16 Bytes) identifiziert das Authenticator-Modell, nicht die individuelle Instanz. Über den FIDO Metadata Service (MDS) kann die RP damit prüfen, welches Gerät oder welche Software das Credential erzeugt hat. Das ist relevant für Szenarien, in denen nur bestimmte Hardware akzeptiert werden soll. Die credentialId ist eine vom Authenticator erzeugte eindeutige ID, die der Server speichert und bei zukünftigen Authentifizierungen in allowCredentials übergibt. Und der credentialPublicKey enthält schließlich den Public Key im Format CBOR Object Signing and Encryption (COSE) (RFC 8152), CBOR-kodiert. Der alg-Parameter gibt den Algorithmus an: -7 steht für ES256 (Elliptic Curve Digital Signature Algorithm (ECDSA) über P-256 mit SHA-256), -257 für RS256, -8 für EdDSA. Dieser Schlüssel ist der einzige Wert, den die RP dauerhaft speichern muss. Alle zukünftigen Assertion-Signaturen werden gegen ihn validiert.
Die Architektur von FIDO2 ist strukturell überschaubar: drei Akteure, zwei API-Aufrufe, eine zentrale Datenstruktur. Relying Party, WebAuthn Client und Authenticator kommunizieren über klar definierte Schnittstellen: WebAuthn nach oben zur Webanwendung, CTAP2 nach unten zum Authenticator. Die authData zieht sich als gemeinsamer Nenner durch beide Ceremonies: Bei der Registration steckt sie im attestationObject, bei der Authentication ist sie direkt als authenticatorData enthalten. Wer das Byte-Layout kennt und weiß, welche Bits welche Validierungen auslösen, kann die Serverlogik direkt einordnen.
Der nächste Teil geht die Registration Ceremony nach §7.1 [9] Schritt für Schritt durch: Er zeigt, wie PublicKeyCredentialCreationOptions aufgebaut ist, wie das attestationObject validiert wird und welche Felder der Server in welcher Reihenfolge prüfen muss. Anschließend folgt die Authentication Ceremony nach §7.2 [10]: PublicKeyCredentialRequestOptions, Signaturvalidierung über authData || SHA-256(clientDataJSON) und der Umgang mit signCount bei Synced Passkeys.
URL dieses Artikels:
https://www.heise.de/-11364345
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Unser Deal-Qualitätsversprechen: Gute, ehrliche und unabhängig recherchierte Angebote. Mehr Infos
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Bei Amazon läuft aktuell ein großer Sale um Balkonkraftwerke. Mehrere Sets mit einer Modulleistung zwischen 900 und 2.000 Watt sind dort befristet reduziert. Zur Verfügung gestellt werden die Deals von den deutschen Händlern Solakon und Solarway. Beide offerieren die Sets mit Gratisversand.
Die Aktion stößt offenkundig auf Interesse, denn der Bestseller Nr. 1
Trotzdem gibt es noch mehrere interessante Balkonkraftwerke zum Aktionspreis.
400-mal im letzten Monat verkauft hat sich das Onlite aus dem Hause Solakon. Es bietet zwei bifaziale Module zu 450 W, konkret die LP182M54NB. Das 900-Watt-Balkonkraftwerk verfügt über einen Markstek-Wechselrichter, der im Rahmen der Bagatellgrenze auf 800 Watt drosselt. Zum Lieferumfang gehören ein fünf Meter langes Anschlusskabel, zwei 2 Meter lange Solarverlängerungskabel und eine Wechselrichterhalterung. Modulhalterungen sind separat erhältlich.
Bis einschließlich Sonntag kostet das Balkonkraftwerk bei Amazon wieder nur 244,95 Euro
Solakon 900W Balkonkraftwerk - Balkonkraftwerk 800W komplett Steckdose - neuester 800 Watt Wechselrichter - Solaranlage Komplettset - 450W bifaziale Solarmodule inkl Zubehör - 5m Kabel, Ohne Halterung
-21%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
-18%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
-7%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
-21%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
-31%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
-28%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
-28%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
