Cloudflare führt mit Precursor ein neues Verfahren zur Bot-Erkennung ein, welches das Verhalten von Besuchern über eine gesamte Websitzung hinweg auswertet. Statt nur einzelne Aktionen wie Login oder Checkout zu prüfen, sammelt das System fortlaufend Signale aus dem Browser. So soll es automatisierte Zugriffe zuverlässiger von menschlichen Nutzern unterscheiden. Die Funktion ergänzt Cloudflares Bot-Management und den CAPTCHA-Ersatz Turnstile zunächst als optionales Enterprise-Feature.

Verhaltensanalyse über die gesamte Sitzung

Nach Angaben von Cloudflare schließt Precursor eine Lücke der klassischen Bot-Abwehr: Moderne Bots können JavaScript ausführen, echte Browser verwenden und einzelne CAPTCHA-Prüfungen bestehen. Schwieriger sei es hingegen, menschliches Verhalten über einen längeren Zeitraum konsistent nachzubilden.

Dafür bindet Cloudflare beim Ausliefern von HTML-Seiten automatisch ein kompaktes JavaScript-Skript ein. Es erfasst während der Sitzung unter anderem Mausbewegungen, Tastaturaktivität, Fokuswechsel und Sichtbarkeitsänderungen der Seite. Die Daten werden fortlaufend an Cloudflares Auswertungsplattform übertragen und fließen in den Bot-Score sowie bestehende Schutzmechanismen ein.

Zum Beispiel kann das System erkennen, wenn Tastatureingaben auftreten, obwohl kein Eingabefeld aktiv ist, oder wenn Mausbewegungen nicht zu der Zeit passen, in der eine Seite tatsächlich sichtbar war. Solche Inkonsistenzen sind zusätzliche Indikatoren für automatisierte Zugriffe.

Menschliche Bewegungsmuster als Erkennungsmerkmal

Cloudflare begründet den Ansatz damit, dass menschliche Mausbewegungen durch biomechanische und kognitive Faktoren geprägt sind – etwa die Drehbewegung des Handgelenks, messbare Verzögerungen durch kognitive Verarbeitung und das physiologische Handzittern. Automatisierte Werkzeuge erzeugen dagegen häufig mathematisch ideale Bewegungsbahnen oder wiederkehrende Muster.

Entscheidend sei dabei nicht ein einzelnes Ereignis, sondern die Gesamtheit der Interaktionen innerhalb einer Sitzung. Da Precursor sitzungsbasiert arbeitet, soll ein Bot seine Bewertung auch nicht durch einfaches Neuladen einer Seite zurücksetzen können.

Parallel führt Cloudflare neue sitzungsbezogene Ansichten in Security Analytics ein. Administratoren sollen damit komplette Nutzerpfade analysieren können, statt lediglich einzelne HTTP-Anfragen zu betrachten.

Datenschutz soll berücksichtigt werden

Der Ansatz ist datenschutzrechtlich zumindest fragwürdig. Cloudflare betont in der Ankündigung jedoch, dass Precursor unter Datenschutzgesichtspunkten entwickelt worden sei. So würden bei der Tastaturerfassung beispielsweise nur zeitliche Muster und Eingaberhythmen ausgewertet, nicht jedoch die tatsächlich gedrückten Tasten. Die gesammelten Verhaltensdaten würden zudem aggregiert verarbeitet und weder Benutzerkonten noch dauerhaften Identitäten zugeordnet.

Precursor wird nach Angaben des Unternehmens derzeit eingeführt und lässt sich über das Cloudflare-Dashboard aktivieren. Bis zur allgemeinen Verfügbarkeit im Laufe des Jahres soll die Funktion kostenlos nutzbar sein, anschließend wird sie Teil von Cloudflares Enterprise Bot Management sein.

(fo)

Kurz vor der Sommerpause des Bundestages hat die Regierung eine Neufassung des Gebäudeenergiegesetzes und des Gebäude-Elektromobilitätsinfrastruktur-Gesetzes (GEIG) durch Bundestag und Bundesrat gebracht. Teil der Neuregelung sind Vorgaben für den Ausbau der Ladeinfrastruktur. Es unterscheidet dabei zwischen Wohn- und Nichtwohn-Gebäuden, Bestand, Neubau und Sanierung.

Neue Nichtwohn-Gebäude

In einem Neubau mit mehr als fünf Stellplätzen, beispielsweise einem Parkhaus, sollen künftig mindestens 50 Prozent vorverkabelt und die restlichen Stellplätze mit Leitungsinfrastruktur versehen werden. Außerdem soll es wenigstens einen Ladepunkt je fünf Stellplätze geben. Für neue Nichtwohn-Gebäude, in denen vor allem Verwaltungs-, Kommunikations- und Organisationsaufgaben erledigt werden, gelten strengere Vorgaben.

Wenn die Stellplätze in Neubauten öffentlich zugänglich sind, kann der Eigentümer auch öffentlich zugängliche Ladepunkte schaffen, deren Ladeleistung insgesamt mindestens dem Produkt aus der Anzahl der öffentlich zugänglichen Stellplätze und einer Ladeleistung von 2,2 kW entspricht. Bei zehn Parkplätzen wären das also ein 22-kW-Ladepunkt oder eben zwei 11-kW-Ladepunkte.

Nichtwohn-Gebäude im Bestand

Auch im Bestand ändert sich für die Besitzer etwas, und das sogar recht kurzfristig. Sofern mehr als 20 Stellplätze vorhanden sind, müssen ab dem 1. Januar 2027 mindestens 50 Prozent der Stellplätze mit Leitungsinfrastruktur für die Elektromobilität ausgestattet werden. Alternativ kann auch wenigstens jeder zehnte Stellplatz mit einem Ladepunkt versehen werden.

Ähnlich wie beim Neubau kann der Eigentümer auch im Bestand öffentliche Ladepunkte schaffen. Die Vorgaben an die Ladeleistung sind dann weniger streng: Anzahl der Ladepunkte mal 1,1 kW Ladeleistung. Bei zehn Stellplätzen reicht also ein 11-kW-Ladepunkt, um die Pflichtvorgaben zu erfüllen.

Renovierung und Neubau

Wer in größerem Umfang renoviert, muss dabei künftig ebenfalls Lademöglichkeiten für Elektroautos berücksichtigen. Das betrifft Nichtwohn-Gebäude mit mehr als fünf Stellplätzen und Wohngebäude mit mehr als drei Parkplätzen. In beiden Fällen müssen wenigstens die Hälfte der Stellplätze mit Vorverkabelung und die übrigen mit Leitungsinfrastruktur ausgestattet werden. Außerdem muss ab dieser Anzahl von Stellplätzen mindestens ein Ladepunkt geschaffen werden.

(mfz)

Eine Neuerung in .NET 10.0 ist die Methode ExportPkcs12() zum Zertifikatsexport mit AES-Verschlüsselung und Hashing via SHA-2-256:

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);

Die bisherige Methode Export() verwendet noch veraltete Algorithmen (3DES-Verschlüsselung und SHA1-Hashing). Die alten Verfahren (3DES / SHA1) aus Export() sind allerdings ebenfalls über die neue Methode möglich, wenn man es wirklich will:

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);

Folgender Code zeigt ein Beispiel zum Erstellen und Exportieren eines Zertifikats:

public void Run()
{
 CUI.Demo(nameof(FCL10_Certificates));
 
 string certPath = @"c:\temp\meinZertifikat.pfx";
 string password = "meinSehrGeheimesPasswort"; // Passwort zum Schutz des Zertifikats
 
 // Selbstsigniertes Zertifikat erstellen
 using (var rsa = RSA.Create(2048))
 {
  var request = new CertificateRequest(
      "CN=TestZertifikat",
      rsa,
      HashAlgorithmName.SHA256,
      RSASignaturePadding.Pkcs1);
 
  // Zertifikat für 1 Jahr gültig machen
  var cert = request.CreateSelfSigned(
      DateTimeOffset.Now,
      DateTimeOffset.Now.AddYears(1));
 
  // ALT: Zertifikat mit 3DES-Verschlüsselung und SHA1-Hashing exportieren
  // byte[] pfxData = cert.Export(X509ContentType.Pkcs12, password);
 
  // NEU: Zertifikat als AES mit SHA-2-256 exportieren
  byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);
 
  // NEUE Methode, aber alte Sicherheitsverfahren: 3DES mit SHA-1
  // byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);
 
  // PFX-Datei speichern
  File.WriteAllBytes(certPath, pfxData);
 
  Console.WriteLine($"Test-Zertifikat erstellt und gespeichert unter: {certPath}");
 }
 
 if (!File.Exists(certPath))
 {
  Console.WriteLine($"Datei nicht gefunden: {certPath}");
 }
 else
 {
  // Zertifikat laden
  X509Certificate2 cert2 = X509CertificateLoader.LoadPkcs12FromFile(certPath, password);
  Console.WriteLine($"Zertifikat geladen von {certPath}:");
  Console.WriteLine($"IssuerName: {cert2.IssuerName.Name}");
  Console.WriteLine($"Signaturalgorithmus (Hashing): {cert2.SignatureAlgorithm.FriendlyName}");
  Console.WriteLine($"Öffentlicher Schlüsselalgorithmus: {cert2.PublicKey.Oid.FriendlyName}");
  Console.WriteLine($"Key-Algorithmus OID: {cert2.GetKeyAlgorithm()}");
  // Ob für ein Zertifikat-Export (z. B. .pfx/PKCS#12) AES verwendet wurde, steht nicht im Zertifikat selbst, sondern betrifft die Verschlüsselung der Containerdatei. Das Zertifikat enthält nur Infos zu Signatur- und Schlüsselalgorithmus (z. B. RSA, SHA256).
 }
}

(rme)