Beiträge von Spin

@Win98SE4ever - Wenn du interessiert bist, kann ich dir noch Auszüge aus einer Privaten Konversation posten, die etwas tiefer in die Materie geht.

WebAuthn (1FA oder MFA)?
WebAuthn ist ein Framework. Dieses kann man den eigenen Anforderungen und Bedürfnissen anpassen. Wenn WebAuthn nur als 1FA (bzw. als 2. Faktor zu etwas anderem) eingesetzt wird, würde man es derart konfigurieren, dass von einem Authenticator "User Presence" verlangt wird. Wenn man hingegen "User Verification" vom Authenticator verlangt, soll dieser einen weiteren Faktor wie Knowledge oder Biometrie gewährleisten, und dann erfüllt ein Passkey ("Passwortlose Anmeldung") eigenständig die Anforderungen an MFA. Die 2FA-Authentifizierungsfaktoren werden hierbei nach NIST SP800-63B durch einen einzelne Authentifizierungstransaktion von einem Multi-Faktor-Authentifikator erbracht. Siehe nebenbei auch den Vergleich User Presence vs User Verification (yubico.com).

WebAuthn Attestation

Ein Hardwaremodul wie bspw. das integrierte Trusted Plattform Modul (TPM) wird vom Hersteller mit einem Endorsement Key (EK) - einem Private Key - ausgeliefert. Der öffentliche Schlüssel - der EKPub - wird von einer Zertifizierungsstelle verifiziert. Passkeys die mit Windows Hello geschützt werden, basieren auf der Sicherheit, die das TPM bietet. Deshalb steht hierbei dann eine WebAuthn-TPM-Attestation zur Verfügung (andere Plattformen wie Android haben andere Attestation-Typen), welche vom Serviceprovider auf eine gültige Zertifizierung geprüft werden kann. Dadurch ergibt sich eine geschlossene Vertrauenskette - da sollte ein Authenticator nicht das erforderliche Sicherheitsniveau zum Schutz der Passkeys erfüllen - keine Zertifizierung besteht oder diese ggf. zurückgezogen wird.

Dies ist die Grundlage dessen, weshalb Passkeys auch Authenticator Assurance Level 3 (AAL3) erfüllen können - nämlich genau dann - wenn der Authenticator für das entsprechende Sicherheitsniveau zertifiziert ist. Es kommt ganz darauf an, welche Zertifizierungsstufe das Hardwaremodul erfüllt und ob diese gültig ist. Die meisten Passkey-Authenticatoren garantieren Authenticator Assurance Level 2 und damit jene Sicherheitsebene, welche für MFA-Szenarien geeignet ist. Es stellt sich damit nicht die Frage, ob ein Anbieter Passkeys unterstützt oder nicht, sondern vielmehr, welche Sicherheitsstufe und Restriktionen für die Passkeys bestehen.

WebAuthn Attestation Beispiele

Die technischen Parameter können zum Beispiel auf Yubico demo website getestet werden. Der Authenticator-Response enthält das Attribut `authenticationObject`, welches base64-enkodierte Daten nach RFC 8949 enthält.

Für KeePassXC enthält dieses folgende Daten ("none" = keine Attestation):

{"fmt": "none", "attStmt": {}, "authData": h'...'}

Während wiederum Windows Hello auf den TPM-Chip zurückgreifen kann und eine entsprechende TPM-Attestation mitsendet:

{"fmt": "tpm", "attStmt": {"alg": -65535, "sig": h'....', "ver": "2.0", "x5c": [h'....', h'...], "pubArea": h'...', "certInfo": h'...'}, "authData": h'...'}

Merke allerdings: Der Passkey kann bei KeePassXC exportiert werden (respektive ist die KDBX-Datei selbst portabel). Ein Passkey der durch den TPM-Chip geschützt wird, ist nicht exportierbar und sollte der TPM-Chip den Zugriff verweigern, ist auch der Passkey nicht mehr zugänglich. Immerhin bürgt der Chip respektive die Attestation für die Sicherheit des PassKeys und des Authenticators.

WebAuthn Attestation ggf. Overkill

Derzeit wird davon abgeraten eine WebAuthn-Attestation zu verlangen oder zu validieren. Die offizielle Implementierungsempfehlung ist hierzu, die Attestations bei der Registrierung eines Passkey zu speichern. Sollte man dem Sicherheitsniveau eines Authenticators nicht (mehr) trauen (ergo: Blacklisten), kann man dann auch Nachträglich die entsprechenden Passkeys identifizieren und invalidieren. Dies gehört ganz regulär zur sauberen Implementierung von Passkeys mit dazu! Siehe Attestation (yubico.com). Nach NIST SP800-63B ist es für Authentification Assurance Level 2 (AAL2) (aka: "gewöhnliche MFA-Authentifizierung") nicht erforderlich, die Exportierbarkeit / Synchronisierbarkeit / Transportabilität von in diesem Fall Passkeys zu unterbinden.

Regulatorische Einordnung

Das üblicherweise eingesetzte TOTP erfüllt nicht die Anforderungen der DIN EN ISO 9241 Teil 110 (Usability) und ebensowenig wird es die Anforderungen des Barrierefreiheitsstärkungsgesetz, respektive der EU-Richtlinie 2019/882 erfüllen, welche ab 2025 von verschiedenen Einrichtungen und Institutionen eingehalten werden muss. Das Problem an Time-based-One-Time-Passwords ist deren Konzept selbst, dass nur für eine kurze Zeitdauer gültige TOTP-Codes abgetippt werden müssen, welche alle 30 Sekunden wechseln. Dadurch stellt das TOTP unzulässige zeitliche als auch kognitive Anforderungen an den Benutzer, weshalb es verschiedene Regulatorische Anforderungen, wie zum Beispiel die BITV 2.0, nicht erfüllt. Es gibt also nicht nur das umgangssprachliche "Es tut besser und ist angenehmer", sondern auch verbriefte Gründe, die dafür sprechen, alternative Verfahren anzubieten. Bei PassKeys wiederum handelt es sich dann um Implementierungsdetails des Authenticator, welche Faktoren genau und wie geprüft werden (bspw. ob PIN oder Fingerabdruck oder Muster oder Gesichtserkennung oder ...) eingesetzt werden.

Win98SE4ever

Ich habe mal eine eine kleine Linkliste für interessierte erstellt:

• Passkeys (Begriff)
  • Wayback Machine (archive.org) (hierzu sollte die NIST SP800-63B. bekannt sein)
• 2FA (Begriff)
  • Terms | passkeys.dev
• MFA
  • What the !#@% is a Passkey? | Electronic Frontier Foundation (eff.org)
  • User Presence vs User Verification (yubico.com)
  • W3C
  • About passkeys - GitHub Docs
  • Passwortlose Anmeldung mit Passkeys  |  Authentication  |  Google for Developers
• MFA Attestion
  • Attestation (yubico.com) <-
  • Attestation and Assertion - Web APIs | MDN (mozilla.org)
• Ich hole jetzt nicht mit der DIN EN ISO 9241 Teil 110 (Usability) aus. Ich verlinke mal einfach Mike Kuketz 🛡: "Passkeys wird das Passwort übe…" - Mastodon (tchncs.de)

Win98SE4ever hat es in diesem Beitrag erfasst. Bei Passkeys anstelle von Passwort+TOTP würde die Erforderlichkeit einen Challenge-Code zu signieren dazu führen, dass ein Angreifer nicht mehr stupide phishen kann, sondern er müsste Proxy für den Challenge-Code spielen, was aber dann bei netcup durch eine vielzahl von Challenge-Code-Anfragen auffallen würde - neben dem - dass für die Zuordnung eines Passkeys ggf. ein Domain-Abgleich stattfindet (daher würde der Authenticator melden "für diese Webseite kenne ich keinen passkey"). netcup könnte dann Maßnahmen gegen einen Phishing-Angriff ergreifen. Auch bei einem Keylogger (Android-Tastatur), bei einem MITM (Virenscanner) usw. wäre kein Replay-Angriff mehr möglich. Größtes gelöstes Problem durch passkeys ist die Mehrfachverwendung von Passwörtern.

Passkeys erzielen auch eine höhere Inklusion, da sich auch Menschen die eine (Touch-)Tastatur weder treffsicher noch schnell bedienen können oder kognitiv Schwierigkeiten haben sich etwas über längeren Zeitraum zu merken (Passwort), das Verfahren nutzen können - was insbesondere bei älteren Menschen ein Problem ist, die ggf. mit einem Smartphone (statt einem Laptop) arbeiten und ggf. derzeit auf die Webbrowser-Passwortmanager als Vendor-Lock-in-Silo-Lösung zurückgreifen. Passkeys geben nicht vor, welche Faktoren und welcher Typus (PIN oder Muster?) genau verwendet werden muss, daher können Menschen mit Einschränkungen ganz regulär sich die für sie beste Anmeldemethode (bspw. Gesichtserkennung statt Fingerabdruck) entscheiden. Im Zweifel sind Passkeys maschinell verarbeitbar und es ließen sich auch spezielle Authenticatoren für Menschen mit besonderen Anforderungen entwickeln. Normale Passwort-Manager haben ebenso wie andere Verfahren (bspw. GPG) eine gewisse Einstiegshürde, Passkeys bieten dagegen eine wesentlich höhere universelle Gebrauchstauglichkeit (Usability).

Zitat von dodeka

Solche Aussagen sind einfach nur AUA.. 😑

Ich bin überzeugt das nicht. Ob bei der Anmeldung an der ePA, Elster, eID, usw. ist es immer das selbe Spiel: Die (in diesem Fall Karten-PIN) wird nicht an den Server geschickt , sondern dient der Freigabe der Karte (Krankenkassenkarte/Personalausweis/SIM-Karte/Kreditkarte/Girocard). Dennoch ist das Ergebnis eine sehr starke 2FA-Authentifizierung, obwohl der Server die PIN nie gesehen hat, sondern nur die digitale Unterschrift aus der Karte hat.

Man könnte höchsten die stärke und schwäche bestimmter 2FA-Merkmalen untereinander abwägen (bspw. Handvenenscanner ist sicherer als Fingerabdruck als Biometrie-Merkmal; eine Software-Schlüsseldatei ist schwächer als ein Hardware-Modul als Ownership-Merkmal, usw), was aber nicht Gegenstand der reinen Betrachtung ob 2FA vorliegt oder nicht ist, sondern uns Offtopic führen würde in eine Art Debatte "Wie lang und welche Zeichen muss ein Passwort haben, um sicher zu sein." - nur eben bezogen auf die anderen MFA-Faktoren. Genau dafür gäbe es im Bedarfsfall die WebAuthn-Attestation, die ich bereits erwähnte.

Zitat von ulf8000

Zum Testen wurde mir "https://passkey.org/" genannt, Aber mit Firefox oder Chromium komme ich mit KeePassXC auf der Seite nicht weiter. Nutze Linux.

Hast du in der KeePassXC-Browser-Extension die Einstellung geändert, dass Passkey mit KeepassXC genutzt wird?. Da dies das Webbbrowser-Standardverhalten ändert, ist es per Default deaktiviert. Zudem brauchst du mindestens KeepassXC 2.7.7 und solltest dann entsprechende Einstellungen innerhalb von KeePassXC haben.

Du kannst es auf GitHub.com oder webauthn.io ausprobieren.

Zitat von ulf8000

Ich bin gegen Passkeys, weil man damit aktuell die Kontrolle an Google Apple und MS abgibt. [...]

Du kannst genauso KeePassXC unter Linux verwenden. Passkeys sind ein offener Standard, der dir die Freiheit gibt, eigenständig individuell einen für dich geeigneten Authenticator zu wählen. Wenn du einen YubiKey einsetzt, werden die Passwörter zum Beispiel auf diesem gespeichert.

Zitat von Zoey

Da finde ich MFA Zwang schon angebracht.

Selbstverständlich. 8 Daumen hoch für ein Strohmann-Argument. Das einzige worüber wir herumdiskutieren ist, dass der W3C-Standard auf dem Passkeys aufbauen, besagt, dass ein Authenticator die Sicherheitsfaktoren überprüft, du aber MFA auf dem Server überprüft wissen willst. Ein konkretes Beispiel für einen Authenticator ist Windows Hello, welcher eine 2FA aus Ownership+Biometrie bietet und daher ohne Knowledge (das klassische Passwort) als Faktor auskommt, weshalb Passkeys als "Passwortloses Anmeldeverfahren" bezeichnet werden. Deine Kritik an der Sache ist lediglich, dass der Server quantitativ nur einen einzelnen Passkey empfängt:

Das deine zählweise für die Anzahl der vorliegenden Faktoren verkehrt ist, und sowohl

Zitat von Zoey

1. Besitz Gerät mit PW Manager 2. evt. PW/Biometrie für Zugriff auf Gerät 3. Wissen Masterpasswort/Biometrie 4. Besitz Handy mit TOTP App 5. evt. PW/Biometrie für Zugriff auf Gerät 6. Biometrie zur Entsperrung der App. Heißt das wäre 6FA (was natürlich unsinn ist).

als auch

Zitat von Zoey

[...]das bewerben eines "1FA" Verfahrens durch das BSI [...]

falsch gezählt wird, habe ich bereits versucht, zu erklären. Spätestens wenn Passkeys auf einem YubiKey gespeichert werden, genügt dieser auch den höchsten Anforderungen (AAL3) der NIST SP800-63B.

Meinungen verändern keine Fakten. Aber Fakten sollten Meinungen verändern. Ich kann dir versuchen es zu erklären, verstehen musst du es aber selber. Es gibt nur 3 Faktoren, daher ist das maximum eine 3FA. WebAuthn (mit "n") ist ein Framework, dass MFA unterstützt. Der Authenticator gibt Auskunft darüber, welcher Verifikationsgrad durchgeführt wurde, respektive kann der Serviceprovider festlegen, welche Anmeldetypen er zulässt. Wenn es ein Bedürfnis ist, kann überprüft werden, ob der Authenticator zertifiziert ist, respektive mit einer Blacklist ein Authenticator ausgeschlossen werden. All das, was du verlangst, wird durch WebAuthn erfüllt und ist möglich. In der Regel wird man aber für den Alltag nicht solch strenge Sicherheitsrichtlinien umsetzen. Auch bei herkömmlichen Verfahren kann man den Benutzer nicht beliebig bevormunden, der durch "123456" als Passwort, schwache Zufallszahlen für einen Private-Key, oder durch das Veröffentlichen der Token-Generator-Ausgabe mit einer WebCam, immer die Sicherheit schwächen kann. Auch die TOTP-QR-Codes kann man per WhatsApp verschicken oder ausdrucken und an die Tafel pinnen - dieses Problem wird immer bestehen. Aber, genau das ist der Punkt von Passkeys: Warum machen das Nutzer? Weil die bisherigeren Sicherheitskonzepte Nutzerbedürfnisse nicht befriedigten. Ein Sicherheitskonzept lässt sich nicht gegen einen Benutzer durchsetzen, sondern genau hier setzen Passkeys an, und möchten mit ihm, ein hohes Sicherheitsniveau erreichen.

Zitat von cltrmx

...YubiKeys...

Passkeys sind einfach ein standardisiertes maschinelles Anmeldeverfahren. Worauf die Keys gespeichert werden, kann man frei auswählen. Ob nun in Windows Hello, auf dem Smartphone, in einem Passwortmanager wie KeePassXC oder einem Hardwaretoken wie dem YubiKey. Serviceprovider müssen nur einen Standard für alles implementieren, während Benutzer die Kontrolle und freie Auswahl haben, ob sie Handvenenscanner oder Hardwaretokens einsetzen. Der aktuelle YubiKey unterstützt derzeit glaube ich 25 Passkeys, wobei dessen Kapazität in zukünftigen Versionen vergrößert werden soll

Zitat von Zoey

Aber ich finde es immer noch keine gute Idee von MFA auf einen Faktor zurückzuwechseln. Von mir aus Passwort und WebAuth als zweiten Faktor, [...]

Du verwechselst die Quantität der von dir getätigten Eingaben mit dem tatsächlichen vorliegen verschiedener Sicherheitsfaktoren. Jeder Faktor ist am Ende nur ein Teilschlüssel - MFA zielt darauf ab, dass diese zumindest aus 2 von 3 Faktoren (Ownership, Knowledge, Biometrie) bestehen. Wenn du Teilschlüssel auf verschiedene Geräte verteilen möchtest, so ist das kein MFA, sondern "Secret Sharing". Ein Beispiel: Es gibt Menschen, die argumentieren, dass man zusätzlich zum SSH private Key auch noch TOTP einsetzen sollte, um einen "2. Faktor" zu haben. Tatsächlich handelt es sich aber um Secret-Sharing, da beide Komponenten nur Ownership abdecken. Umgekehrt verlangst du, die wie das BSI titelt "Passkeys - anmelden ohne Passwort" nur als 2. Faktor für eine Passworteingabe einzusetzen, was bereits dem Namen nach das Konzept ad absurdum führt. Denn ein Passkey (Ownership) funktioniert nur mit einem Authenticator, der ein weiteres Sicherheitsmerkmal verifiziert (i.d.R. Biometrie). Hierzu sollte man sich verinnerlichen, dass MFA nicht voraussetzt, dass alle Faktoren serverseitig verifiziert werden (und eben dafür dann dein Fingerabdruck an den Server eingeschickt wird), sondern, dass eine Authentifizierung nur mittels mehrerer Faktoren stattfinden kann.

Daher sind Passkeys eine MFA-Authentifizierung und werden von Internetanbietern (bspw. Google) auch als solche behandelt, wenn man MFA aktiviert. Da Passkeys vergleichbar zu Transaction-based-OTP einen Challenge-Code signieren, statt einem Time-based-OTP, sind sie neben den Problemen unsicherer Passwörter, erheblich sicherer als reguläres 2FA mit Passwort+TOTP

Präambel: Bei einem Anmeldeverfahren geht nicht einfach darum maximale Sicherheit zu erzielen, diese ist bei einem nicht verwendeten Dienst oder bei einem bei dem man das Passwort im Meer versenkt, immer am höchsten. Ein Sicherheitskonzept, dass Nutzerbedürfnisse ignoriert und deshalb aus Bequemlichkeit oder Ungeschick vom Nutzer kompromittiert wird, verfehlt seine Zielsetzung. Zum Beispiel entschlüsselt nur ein IT-Anfänger seine SSH-Keys individuell mit Passwort (oder hat gar nur einen einzigen für mehrere Server), in der Realität nutzt man einen SSH-Agent, und am Ende ist dieser schnell an eine Single-Sign-On-Lösung oder bspw. KeePassXC angebunden, damit Sicherheit auch praktikabel wird.

Die gleiche Magie bieten Passwortmanager, wobei Passkeys (siehe Passkey Developer Resources | passkeys.dev) ein nativer Weg ist, wie man sich mit einem Passwortmanager anmelden kann. Ein Verfahren, dass derzeit in rasantem Tempo Verbreitung findet, einschließlich Open-Source-Lösungen wie bspw. kürzlich KeePassXC.

Es gibt für Multi-Faktor-Authentifikation potentiell 3 Faktoren: Knowledge, Ownership und Biometrie. Ob diese nun Serverseitige (Passwort+TOTP) oder Clientseitig (Masterpassphrase/Fingerabdruck+Passkey) abgefragt werden, ist dabei unerheblich. Passkeys sind eine sichere Anmeldemöglichkeit und wahrscheinlich sicherer als 2FA, denn in der Praxis werden Username+Passwort+TOTP oftmals in der gleichen KeePass-Datenbank abgespeichert und mit AutoType runtergerattert. Wenn man sich verklickt, rasselt KeePass ein anderes Passwort runter und leakt dieses; dann unterstützt jeder Dienst andere Passwortzeichen und Passwortlängen; die AutoType-Sequenz muss für jeden Dienst angepasst werden, usw. Das Verfahren Passkey ist dagegen Standardisiert: Auf github.com wählt man nur die Anmeldemethode aus und von der Zuordnung des richtigen Passkeyeintrags bis zur Zuordnung des korrekten Benutzerkontos erfolgt alles automatisch - Bedienfehler werden ausgeschlossen. Gerade die Anmeldung mit QR-Code löst Bequemlichkeitsprobleme: Häufig verwendete Passwörter werden meist einfacher und kürzer gewählt, bei einem Passkey muss man gar nichts mehr abtippen. Auf manchen Endgeräten möchte man nicht seine vollständige Passwortdatenbank entsperren, nur um sich selektiv bei einem einzelnen Dienst anzumelden (bspw. Firmenlaptop oder Netflix-Anmeldung bei einem Freund), andere Geräte haben keine Tastatur (bspw. SmartTV), sodass man geneigt ist in Netflix 123456 als Passwort zu setzen, sodass die Anmeldung mittels QR-Code viele Probleme addressiert. Eine Passkey-Anmeldung kann zudem auf die explizite Wahl von Identifiern wie Benutzernamen, E-Mail-Adresse, etc. verzichten, sodass auch datensparsamere 1-Klick-Registrierungen bzw. 1-Klick-Logins möglich werden, was erheblich besser ist, als bisherige "Login wie Facebook"-Lösungen, denen genau dieses Bedürfnis zugrunde liegt. Dies könnte auch öffentliche Passwortdatenbanken (bspw. für Internetforen) erübrigen, die nur entstehen, damit man nicht überall einen 0-8-15-Registrierungsprozess mit E-Mail-Adresse (und manchmal Moderatorenfreigabe) durchlaufen muss.

Am Ende des Tages sollte man nicht vergessen, dass ein Nutzer mehrere Passkeys für verschiedene Geräte einrichten und hinterlegen kann, dies aber gleichsam den Vorteil bietet, dass beim schon immer dagewesenen Bedürfnis des Account- und Passwortsharings jedes Gerät seinen individuell Passkey nutzen und der Passkey auch wieder individuell entzogen werden kann. Der Realität, dass Passwörter (einschließlich TOTP) weitergegeben oder öffentlich auf Whiteboards geschrieben werden, muss man sich einfach stellen und die Nutzerbedürfnisse dahinter adressieren. Gerade Domain-; Web- und Serverhosting gehört im Privat- und Hobbyumfeld zu einer besonders von Account-Sharing exponierte Serviceart - ihr möchtet nicht Wissen, wie viele uralte Root-Zugänge, Domain-Admin-Zugänge, usw. sich in meiner Passwortdatenbank anstauen, die über Jahre nicht geändert werden.

Ich befürworte Passkeys und würde mich freuen, wenn auch netcup diese unterstützen würde, um das Sicherheitsniveau regulärer Anmeldungen auf das Fundament von Public-Key-Kryptografie zu stellen.

snax Gleiches Problem bei mir: Bei zwei Domains ist - soweit ich die RRSIG-Records korrekt lese - DNSSEC seit dem 20.11. abgelaufen. Ich würde das nicht weiter als Problem empfinden, wenn man nicht das Gefühl hätte, dass die Ausfälle für netcup unbemerkt bleiben. Ich habe jetzt Mal doch den Support angeschrieben, da es schon wieder auf Ende der Woche zugeht und von Seiten netcup sich von alleine nichts rührt (keine Benachrichtigung oder sonstetwas - als würde man kein eigenes Monitoring durchführen).

Zitat von nkk

[...] Für diese Kunden war es wohl die erste Info, dass sich die Preise erhöhen werden.

Zitat von E-Mail

Bereits im Oktober haben wir in einem News-Beitrag auf diese hingewiesen

Exakt, es war die erste E-Mail, die im ersten Absatz gleich offensiv darauf hinweist, dass man den Newsblog ggf. gelesen haben sollte.

Zitat von Loxley

Ich habe jetzt verstanden, dass Du Dir von netcup professionellere und, zumindest gefühlt, ehrlichere Kommunikation gewünscht hättest. Habe ich das richtig verstanden?

Sorgfältiger und Effizienter trifft es eher, da die Missverständnisse damit beginnen, dass eine längere E-Mail mit vielen Absätzen ohne jegliche Strukturmerkmale wie Überschriften daherkommt. Die hälfte der Lesezeit beschäftigt man sich damit, das Prozedere zu erörtern, hervorzuheben wie sehr man seine Bestandskunden in der Entscheidung berücksichtigt und den Kündigungsmodalitäten. Die eigentlich Vertragsanpassung geht darin nicht nur wie Kleingedrucktes unter, sondern netcup überlässt es dem Kunden, anhand der proklamierten Vorgehensweise herauszufinden, zu welchem Datum die Änderung in Kraft tritt. Wenn das eigentlich relevante nicht unmissverständlich drinne steht, ist das für mich ein "Thema verfehlt". Ein gedanklich suggestives: Echt jetzt? Und dafür 15 Absätze?

Zitat von H6G

Es gibt genügend Fitnessstudios die interessieren sich nicht das Geringste für Sonderkündigungen und dem BGB, da musst du mit dem Anwalt hinterher sein.

Zitat von ASS

Das Rückwirkend bezieht sich selbstverständlich nicht auf einen vergangenen Zeitraum, sondern auf die Zeit vom 1.1. bis zu [...]

In einer personalisierten Kommunikation ist die größte Herausforderung, dass alles auf die eigene Situation und Person übertragen wird. Die also generische Information von netcup lässt sich nicht mehr auf die von ASS dargelegte Leseweise interpretieren, wenn der Kontext ist, dass der eigene Vertrag Anfang Januar endet. Dann gibt es unter rückwirkend nur noch den Zeitraum vor 2023. Im Newsblog mit generischem Leser hatte ich auch kein Problem, einfach deiner Interpretationsweise zu folgen. Es scheint so, dass ich diesem Leseverständnisproblem aber nunmehr nicht alleine unterliege:

Zitat von NaN

Na das ist doch nett, dass man nicht einfach mal rückwirkend die Preise erhöht. Als wenn das eine Möglichkeit gewesen wäre.[...]

Zitat von Bud

[...] aber soweit ich das verstanden habe bekommt man 3 Monate vor der erneuten Abrechnung eine E-Mail mit dem 3-Monatigem Sonderkündigungsrecht, [...]

Dies wird in der Tat suggeriert bzw. ein Sonderkündigungsrecht gilt (für mein Verständnis) erwartbar bis zu dem Tag, an dem die Vertragsänderung eintritt. Hier spezifiziert netcup die Frist mit 3 Monaten (90 Tage), bis zum 01.01.23 sind es aber nur noch 51 Tage. Netcup führt sogar in einem eigenen Absatz aus, welche Kündigungsregeln in einem solchen Fall greifen. Ich glaube aber, dass es Unwirksam ist den Vertrag vor Verstreichen der eingeräumten Sonderkündigungsfrist anzupassen. In jedem Fall wirkt die Durchführung durch diese Berechnungsdiskrepanz unsauber geregelt. Auch wenn dies ein Entgegenkommen zu den gesetzlichen Anforderungen ist, so kommt es nicht gut an, die ausgestreckte Hand noch im gleichen Schreiben wieder zurückzuziehen.

Meine Frage war, ob ich die Angelegenheit zu eng sehe, denn natürlich hängt es vom Text und dem Leser ab, wie ein Text verstanden wird. Ich weiß nicht, wie ich die "Reaktionen"-Smiley deuten soll. Wenn es heißen soll "Schlaf mal drüber" - wäre es cool, wenn das auch jemand schreiben würde - denn es beantwortet meine Frage auch bereits vollkommen und das Thema ist erledigt.

Zitat von ASS

Alle Sachen über die du dich beschwerst sind Kundenfreundlich und zum Nachteil von NC. Nur weil du etwas nicht verstehst, sind nicht die andren blöd...

Nein, du missverstehst.

Es gibt verschiedene Arten, wie man einen Text auffassen kann, die über die reine fachliche/sachliche-Ebene hinaus gehen. Das Modell das dazu glaube ich jeder in der Schule lernt ist dashier: https://de.wikipedia.org/wiki/Vier-Seiten-Modell

Ich habe versucht kenntlich zu machen, dass mir die sachliche/fachliche Ebene (auf die sich soweit alle Antworten beziehen) ziemlich egal ist, wobei dies Schwierig ist - in einem Text steckt mehr Botschaft drinne, als das reine Behördendeutsch.. Ein Beispiel wäre bereits das Wort "Preisanpassung", dass bereits ein Euphemismus (also ein rethorisches Stilmittel) für "Preiserhöhung" ist. Auch in Regelwerken steckt mehr Botschaft, als die reinen Regeln, da deren Darstellung und Wirken nicht von Robotern sondern von empfindsamen Wesen verspürt wird, was sicherlich jeder in einem Brettspiel wie "Mensch Ärger dich nicht" merkt [Der Ärger, das ist eine Emotion, die durch das Regelwerk bedingt wird. Bei einem anderen Gesellschaftsspiel - mit anderen Regeln - würde es anders verlaufen. ;)]. Dieses Wirken darf man nicht unterschätzen: Zum Beispiel haben die Kulturpflanzen Weizen und Reis - durch ihre unterschiedlichen Anbaumethoden - die jeweiligen Gesellschaftsstrukturen in bspw. Deutschland in Kontrast zu Asien mitgeprägt.

Die E-Mail von netcup wirkt nun hierbei ziemlich unbedarft, was ich im Falle eines offiziellen - und nicht von einem individuellen vielleicht Support-Mitarbeiter - sondern wirklich nach Template, Review und vorbereiteten Prozess verschickten Schreibens kritisiere. Würde ich es einem Autisten verständlich machen wollen, würde ich versuchen ihm zu erklären, dass nicht bedacht wurde, was Leute von so einer E-Mail erwarten: Dem Text fehlt es an Formattierung, wirkt dadurch zu lang und wenig zuvorkommend und mühsam. Ein Beispiel: Jemand der nur 10 Sekunden Lesezeit opfern möchte (weil es nur um Peanuts geht), kann nicht alle relevanten Informationen erfassen: Es stehen grundsätzliche Dinge nicht drinne, wie bspw. das Datum ab wann die nächste Abbrechnungsperiode anbricht und damit der neue Preis effektiv in Kraft tritt. Es bestehen zudem Probleme, wenn Zeiträume sich überschneiden: Also wenn der Vertrag angepasst wird, ehe die Sonderkündigungsfrist verstrichen ist: Zum Beispiel: Welcher Preis wird zwischen dem 01.01.23 und 09.02.23 berechnet, würde man zum 09.02.23 vom Sonderkündigungsrecht Gebrauch machen, jedoch am 01.01. bereits eine weitere Rechnungsperiode angebrochen sein. Alleine die Präsenz einer derartigen Unklarheit kann verschiedene Interpretationsweisen beim Leser hervorrufen, selbst wenn dieser Fall einen selbst nicht betrifft. Das sind die Dinge, die sich sachlich gut quantifizieren ließen.

Ja, netcup macht seinen Bestandskunden ein Prima angebot. Dieses war aber nie Gegenstand meiner Kritik, sondern das netcup den besonderen Anforderungen der personalisierten Kommunikation nicht gerecht wird. Ein Newsblog für generische Leser hat eben ganz anderen Anforderungen, als eine personalisierte Kommunikation, für die Teile des Blogs - unter Auslassung der Überschriften - abgeändert übernommen wurden

Ich weiß nicht wohin mit dem Thema, also landet es unter Smalltalk:

Heute gab es Post von netcup. Ich gehe mal davon aus, dass alle Kunden die gleiche erhalten und bin mir unsicher, ob ich sie im Forum veröffentlichen darf.

In dem Schreiben wird eine Preiserhöhung angekündigt, die eigentlich nur eine Frage der Zeit war, jedoch die Art & Weise WIE diese Kommuniziert wird, missfällt mir allerdings , weswegen ich einmal sinngemäß wiedergebe, wie ich die Dinge aufgefasst habe [Achtung: Kann Spuren von Ironie, Sarkasmus oder anderer Rhetorik enthalten!]

• Wir haben ja eigentlich schon darauf hingewiesen [Habe ich etwas verpasst!? Ist das eine Mahnung?]...
• jetzt kommt die Preisanpassung um 9% [10%+ fand wohl die Marketing-Abteilung aus offensichtlich Gründen zu doof. Bekomme ich dann November 2024 die übrigen 1-99%?].
• Sie dürfen sich freuen, wir haben die Preise für Neukunden erhöht, aber beschlossen Preise nicht rückwirkend auch für Sie als Bestandskunden zu erhöhen [Wie bitte? Ihr habt intern also darüber diskutiert bspw. die Preise rückwirkend ab August 2022 höher zu berechnen - und ich soll euch jetzt Dankbar sein, dass ihr euch überlegt habt die Preise doch erst zu erhöhen, nachdem man einen informiert? Oder wie soll man das verstehen?].
  
• Wir wollen ihnen nun 3 Monate Sonderkündigungsrecht einräumen, aber wir haben ja jetzt schon November und verpennt im Oktober zu schreiben, deswegen hier eine überkomplitzierte Regelung. [Es wird wohl schon niemand nachrechnen, dass das dann für einige Kunden 52 Tage statt 90 Tage sind, bis zur potentiell nächsten Abrechnungsperiode am 01.01.2023 Die sollen sich mal nicht beschweren, in der AGB standen sogar nur 4 Wochen!] _{Wir sind davon überzeugt, dass unsere Individualbehandlung der Kunden von hohe Qualität, fair und marktgerecht sind! Jahwohl - das bekommt jetzt eine GANZ NEUE Bedeutung}!

[/RETHORIK ENDE ] Versteht mich nicht falsch: In meinem Fall zahle ich nun 2.16€ mehr im Jahr , also kein Problem! Ich finde es aber schon sehr Albern, was man sich alles ausdenkt, um rhetorisch zu sagen "Du bekommst als Bestandskunde einen Lolie " und im nächsten Satz zu sagen: "Ach, der der vor dir dran war, der hat zwei Lollies bekommen ". Dadurch konterkariert man alles - jezt schmeckt mir dir Lutscher auch nicht mehr!

Und das ist Punkt, den ich für ziemlich unprofessionell halte: Von der Redewendung "Wir haben bereits hingewiesen" mit der ein Bezug zum Newsletter hergestellt wird; bis zur überkomplitzierten Regelung, um von 457 Tage (12 Monate Vertrag mit Abrechnung zum 31.12.) auf 90 Tage (3 Monate Sonderkündigungsrecht statt 4 Wochen laut AGB) - und selbst das dann nichtmal - auf 52 Tage (Vertrag mit Abrechnung zum 01.01) Kunden individuell zu behandeln. Und dafür hat's jetzt Wahnwitzig mehr als eine DIN A4-Seite E-Mail-Text gebraucht , statt in 3 Sätzen anzukündigen: "Wir haben gestiegene Energiekosten, weshalb wir die Preise ab 01.01.2023 um 9% erhöhen. Sie haben ein Sonderkündigungsrecht von 4 Wochen. Für Bestandsverträge greift die Preiserhöhung erst mit ihrer nächsten Abrechnungsperiode..."

Was meint ihr? Bin ich hier zu sensibel oder ist die Kritik angebracht?

Hallo,

ich möchte gerne den Vorschlag machen, eine zukünftige Root-Server G10-Serie mit den künftigen ARMv9-CPUs auszustatten. Was würdet ihr von dieser Idee halten?

Viele Grüße,

Spin

Nun, irgendwie müssen sich die Server allerdings auch refinanzieren. Wobei die "Verteidiger" von netcup irgendwie etwas Realitätsfern argumentieren. Ein Steal von 40% ist völlig Normal (hatte jetzt schon 2 vServer). Unter Last geht der Steal bis auf 60% rauf.

Hier ein Screenshot vom vServer den ich mal Testweise unter Last gesetzt habe, um den Steal von 60% zu messen:

DeepinBildschirmfoto_Bereich auswählen_20200127205334.png

Ich sehe darin aber auch keinen Grund mich zu beschweren oder den Support anzuschreiben. Das System tut schließlich was es soll. Und wenn ich mehr Leistung benötigen sollte, gibt es schließlich auch noch weitere Tarife. Das Preis/Leistungsverhältnis ist in jedem Fall unschlagbar.

Ich habe mich vertan. auto wird nicht funktionieren.

Zitat

auto (NEW) If this option is specified ndppd will attempt to detect which interface to use in order to forward Neighbor Solicitation Messages, by reading the routing table /proc/net/ipv6_route.

Dann werde ich wohl dauerhaft static verwenden, da ich zurzeit keinerlei Server nutze, der für das Interface wg0 auf NDP-Anfragen antworten würde. Verbesserungsvorschläge sind willkommen.

Vielen Dank H6G für die Erklärung. Das ist des Rätsels Lösung (und danke für die leicht verständliche Anleitung).

Ich habe nun folgende /etc/ndppd.conf

route-ttl 30000
proxy ens3 {

   router yes
   timeout 500
   ttl 30000

   rule 2a03:4000:26:9c:1::/96 {
      auto
   }
}

Ich habe es zunächst mit iface wg0 ausprobiert (probieren kann nie schaden), doch am Interface wg0 ist die Konfiguration vollständig statisch (kein NDP im Einsatz) und entsprechend hat es damit wie erwartet nicht geklappt. Mit static hingegen hat es auf Anhieb geklappt, aber ich möchte nicht die Routingtabelle stresstesten.

Jetzt ist der Router einmal hinterlegt und ich glaube auto (und damit Antworten auf Basis der IPv6-Routingtabelle) wäre die beste Konfiguration, weswegen ich zu der zitterten Konfiguration kam. Da allerdings erstmal die Route zwischengespeichert ist, kann ich jetzt nicht testen, ob dies explizit so funktioniert. Ich werde es nur irgendwann merken, falls IPv6 wieder Probleme hätte.

Ich möchte gerne einen Teil eines IPv6-Subnets innerhalb einer virtuellen Netzwerkkarte nutzen und habe dazu unter Arch Linux in /etc/systemd/network/ folgende Dateien für den Dienst systemd-networkd hinertlegt

ens3.network

[Match]
Name = ens3

[Network]
Address = 2a03:4000:26:9c::1/128
Address = 185.243.8.149/24
Gateway = fe80::1
Gateway = 185.243.8.1
DNS = 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
IPForward = ipv6

wg0.network

[Match]
Name = wg0

[Network]
Address = 10.200.200.1/24
Address = 2a03:4000:26:9c:1::1/96
IPForward = yes
IPMasquerade = yes

[Route]
Gateway = 10.200.200.1
Destination = 10.200.200.0/24
Gateway = 2a03:4000:26:9c:1::1
Destination = 2a03:4000:26:9c:1::/96

Mit dieser Konfiguration kann ich vom Netzwerk innerhalb des Adapter wg0.network wunderbar IPv4-Anfragen ins Internet schicken, allerdings über IPv6 erhalte ich ab dem 2. Hop keine Antwort. (Der 1. Hop ist 2a03:4000:26:9c:1::1).

Könnte mir jemand auf die Sprünge helfen, wie auch das IPv6-Forwarding klappt?