t3x-nr-passkeys-be

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 12037 ist in_progress So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12037/badge)](https://www.bestpractices.dev/projects/12037)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/12037"><img src="https://www.bestpractices.dev/projects/12037/badge"></a>


Dies sind die Kriterien das Level Silber. Sie können auch die Kriterien für die Level Passing oder Gold sehen.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 12/17 ●

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    TYPO3 extension for passwordless backend authentication via WebAuthn/FIDO2 Passkeys

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

  • Voraussetzungen


    Nicht genug für ein Badge.

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

    This completed self-assessment still has unresolved or unmet passing requirements; it does not currently claim a passing badge. The badge service calculates the achievement from the saved answers. Evidence: https://www.bestpractices.dev/en/projects/12037


  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    Contribution instructions specify acceptance expectations, development/check commands or commit requirements. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/CONTRIBUTING.md


  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]
    Die DCO ist der empfohlene Mechanismus, weil er einfach zu implementieren ist, im Quellcode verfolgt wird und git direkt eine "signed-off" Funktion mit "commit -s" unterstützt. Um am effektivsten zu sein, ist es am besten, wenn die Projektdokumentation erklärt, was "signed-off" für dieses Projekt bedeutet. Eine CLA ist eine rechtliche Vereinbarung, die die Bedingungen definiert, unter denen intellektuelle Werke an eine Organisation oder ein Projekt lizenziert wurden. Ein Contributor Assignment Agreement (CAA) ist eine gesetzliche Vereinbarung, die die Rechte an einer intellektuellen Arbeit an eine andere Person überträgt; Projekte müssen keine CAAs haben, da CAA das Risiko erhöht, dass potenzielle Mitwirkende nicht dazu beitragen werden, vor allem, wenn der Empfänger eine gewinnorientierte Organisation ist. Die Apache Software Foundation CLAs (die individuelle Contributor-Lizenz und die Corporate CLA) sind Beispiele für CLAs, für Projekte, die bestimmt haben, dass die Risiken dieser CLAs für das Projekt geringen sind als ihre Vorteile.

    The organization default contribution instructions require signed commits and DCO sign-off. Evidence: https://github.com/netresearch/.github/blob/main/CONTRIBUTING.md


    Nicht genug für ein Badge.

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]
    Es muss einen gut dokumentierten, etablierten Weg geben, Entscheidungen zu treffen und Streitigkeiten zu lösen. In kleinen Projekten kann dies so einfach sein wie, "der Projektinhaber und -Leiter trifft alle endgültigen Entscheidungen". Es gibt verschiedene Führungs-Modelle, darunter wohlwollender Diktator und formale Meritokratie; Für weitere Details siehe Governance-Modelle . Sowohl zentralisierte (z.B. Single-Maintainer) als auch dezentrale (z.B. Gruppen-Maintainer) Ansätze wurden erfolgreich in Projekten verwendet. Die Governance-Informationen müssen nicht die Möglichkeit einer Projektspaltung dokumentieren, da dies für FLOSS-Projekte immer möglich ist.

    The contribution instructions do not define a complete project decision-making/governance model. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/CONTRIBUTING.md


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]
    Projekte können das Miteinander ihrer Gemeinschaft verbessern und Erwartungen in Bezug auf akzeptables Verhalten setzen, indem sie einen Verhaltenskodex verfassen. Dies kann helfen, Probleme zu vermeiden, bevor sie auftreten, und das Projekt zu einem einladenderen Ort zu machen. Dies sollte sich nur auf das Verhalten innerhalb der Gemeinschaft/ am Arbeitsplatz des Projekts konzentrieren. Beispielhafte Verhaltenskodizes sind der Linux Kernel Code of Conduct, der Contributor Covenant Code of Conduct, der Debian Code of Conduct, der Ubuntu Code of Conduct, der Fedora Code of Conduct, der GNOME Code Of Conduct, der KDE Community Code of Conduct, der Python Community Code of Conduct, die Ruby Community Conduct Guideline und der Rust Code of Conduct.

    The project has a code of conduct via its repository file. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/CODE_OF_CONDUCT.md


    Nicht genug für ein Badge.

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]
    Die Dokumentation für Governance und Rollen und Verantwortlichkeiten können an einem Ort sein.

    Public author names and CODEOWNERS do not provide a complete documented roster of sensitive-resource access together with the required project roles and responsibilities. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/CONTRIBUTING.md https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/.github/


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    The existing maintainer attests to organization backup access. Authenticated organization metadata confirms three organization owners; repositories and automated release workflows are organization-controlled, supporting continued issue, change and release management if one person becomes unavailable. Evidence: https://www.bestpractices.dev/en/projects/12037 https://github.com/orgs/netresearch/people https://github.com/netresearch/t3x-nr-passkeys-be/actions


    Genug für ein Badge!

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    Retained the project maintainer's existing attestation that multiple team members can continue this project; organization ownership/backup access and documented development procedures remain in place. This is an attributed maintainer assessment, not a conclusion drawn from commit counts alone. Evidence: https://www.bestpractices.dev/en/projects/12037 https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/CONTRIBUTING.md https://github.com/orgs/netresearch/people


  • Dokumentation


    Nicht genug für ein Badge.

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]
    Das Projekt könnte die Roadmap nicht umsetzen, das ist ok; Der Zweck der Roadmap ist es, potenziellen Nutzern/innen und Entwicklern/innen zu helfen, die beabsichtigte Richtung des Projekts zu verstehen. Sie muss nicht detailliert sein.

    No roadmap covering intended and excluded work for at least the next year is published in the inspected project documentation. A list of issues alone does not meet the time-horizon requirement. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/README.md https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]
    Eine Softwarearchitektur erläutert die grundlegenden Strukturen eines Programms, d.h. die Hauptkomponenten des Programms, die Beziehungen zwischen ihnen und die Schlüsseleigenschaften dieser Komponenten und Beziehungen.

    High-level architecture and component responsibilities are documented. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/DeveloperGuide/Architecture.rst https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/docs/ARCHITECTURE.md


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]
    Dies sind Sicherheitsanforderungen, die die Software erfüllen soll.

    Project-specific documentation describes security expectations, deployment considerations and/or limits. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Deployment.rst https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst


    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]
    Die Idee ist, den Benutzern/innen zu zeigen, wie man anfängt und was die Software überhaupt macht. Dies ist entscheidend für potenzielle Benutzer/innen, um loszulegen.

    The overview and installation/usage instructions show how to obtain, configure and use the project. Project-specific security expectations are assessed separately. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/README.md https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Configuration/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Installation/Index.rst


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]
    Die Dokumentation DARF Informationen über Unterschiede oder Änderungen zwischen Versionen der Software und/oder Links zu älteren Versionen der Dokumentation enthalten. Die Absicht dieses Kriteriums ist nicht, dass die Dokumentation perfekt sein muss, vielmehr soll Arbeit investiert, um die Dokumentation konsistent zu halten

    Retained the existing maintainer self-attestation after reviewing current source/policy; no conflicting evidence was found. Documentation is updated with each release. The Changelog documents all changes per version. All 11 RST documentation chapters are kept current with the codebase. See https://github.com/netresearch/t3x-nr-passkeys-be/blob/main/Documentation/Changelog/Index.rst and https://github.com/netresearch/t3x-nr-passkeys-be/tree/main/Documentation Evidence: https://www.bestpractices.dev/en/projects/12037 https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/.bestpractices.json


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]
    Eine Errungenschaft ist jegliche Form von externen Kriterien, auf die das Projekt speziell hingearbeitet hat, um diese zu erreichen, einschließlich einiger Abzeichen. Diese Informationen müssen nicht auf der ersten Seite der Website des Projekts einzusehen sein. Ein Projekt, das GitHub verwendet, kann Errungenschaften auf der Repository-Vorderseite setzen, indem man sie der README-Datei hinzufügt.

    The repository front page hyperlinks its OpenSSF badge achievement/status. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/README.md


  • Zugänglichkeit und Internationalisierung


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]
    Für Webanwendungen siehe Web Content Accessibility Guidelines (WCAG 2.0) und dessen unterstützendes Dokument Understanding WCAG 2.0; Siehe auch W3C accessibility information. Für GUI-Anwendungen sollten Sie die umweltbezogenen Barrierefreiheitsrichtlinien verwenden (z.B. Gnome, KDE, XFCE, Android, iOS , Mac und Windows). Einige TUI-Anwendungen (z.B. `ncurses`-Programme) können bestimmte Dinge ausführen, um sich selbst zugänglicher zu machen (z.B. `alpine`'s `force-arrow-cursor`-Einstellung). Die meisten Kommandozeilen-Anwendungen sind ziemlich unzugänglich. Dieses Kriterium ist oft N/A, z.B. für Programmbibliotheken. Hier sind einige Beispiele, welche Maßnahmen zu ergreifen oder Fragen zu berücksichtigen sind:
    • Stellen Sie Text Alternativen für alle Nicht-Text-Inhalte zur Verfügung, so dass dieser in andere Formen umgewandelt werden kann, wie z.B. Großdruck, Blindenschrift, Sprache, Symbole oder einfachere Sprache ( WCAG 2.0-guideline 1.1)
    • Farbe ist nicht das einzige Mittel um Informationen zu übermitteln, die eine Aktion anzeigen, zu einer Eingabe auffordern oder visuelle Elemente unterscheiden. (WCAG 2.0 guideline 1.4.1)
    • Die visuelle Darstellung von Text und Textbildern hat einen Kontrast Verhältnis von mindestens 4,5:1, außer für großen Text, nebensächlichen Text, und Logos(WCAG 2.0 guideline 1.4.3)
    • Machen Sie alle Funktionalitäten von einer Tastatur aus erreichbar (WCAG guideline 2.1)
    • Ein GUI oder ein webbasiertes Projekt SOLLTE mit mindestens einen Screen-Reader auf der Zielplattform(en) testen (z.B. NVDA, Jaws oder WindowEyes auf Windows; VoiceOver auf Mac & iOS; Orca auf Linux/BSD; TalkBack auf Android). TUI-Programme DÜRFEN die Übermalung reduzieren, um eine redundante Lesung durch Screenreader zu verhindern.

    Documentation and use of the TYPO3 UI do not establish accessibility of all project sites and delivered features; no complete current accessibility assessment was verified. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be


    Genug für ein Badge!

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]
    Lokalisierung "bezieht sich auf die Anpassung eines Produkt-, Applikations- oder Dokumentinhalts, um die Sprache, kulturelle und andere Anforderungen eines bestimmten Zielmarktes zu erfüllen." Internationalisierung ist die "Gestaltung und Entwicklung eines Produkt-, Applikations- oder Dokumentinhaltes, die eine einfache Lokalisierung für Zielgruppen ermöglicht, die in Kultur, Region oder Sprache variieren." (Siehe W3Cs "Lokalisierung vs. Internationalisierung" .) Software erfüllt dieses Kriterium einfach dadurch, dass sie internationalisiert ist. Es ist keine Lokalisierung für eine andere Sprache erforderlich, denn sobald Software internationalisiert wurde, ist es möglich für andere, an der Lokalisierung zu arbeiten.

    End-user labels are externalized into TYPO3 XLIFF language resources, allowing translation/localization through the framework. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Resources/Private/Language/locallang.xlf https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Resources/Private/Language/locallang_csh_be_users.xlf https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Resources/Private/Language/locallang_dashboard.xlf


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, müssen die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z. B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]
    Beachten Sie, dass die Verwendung von GitHub dieses Kriterium erfüllt. Dieses Kriterium gilt nur für Passwörter, die für die Authentifizierung von externen Benutzern in die Projektseiten verwendet werden (inbound authentication). Wenn sich die Projektseiten auf anderen Seiten anmelden müssen (outbound authentication), müssen sie eventuell Authorization-Tokens für diesen Zweck anders speichern (da das Speichern eines Hashes nutzlos wäre). Dies gilt für das Kriterium crypto_password_storage zu den Projektseiten, ähnlich wie sites_https.

    Repository and release hosting use GitHub, explicitly recognized by this criterion as meeting password-storage requirements. Project documentation pages do not implement their own user-password login. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be https://www.bestpractices.dev/en/criteria/1#sites_password_security


 Verbesserungs-/Nacharbeits-Kontrolle 1/1 ●

  • Vorherige Versionen


    Genug für ein Badge!

    Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). [maintenance_or_update]

    The published security support policy identifies supported versions and states which older versions are outside normal security support. This does not assert that every announced fix target was historically achieved. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/SECURITY.md


 Berichterstattung 2/3 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. [report_tracker]

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/issues https://github.com/netresearch/t3x-nr-passkeys-be/pulls


  • Anfälligkeits-Prozessbericht


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [vulnerability_report_credit]

    The disclosure policy does not establish credit for every resolved vulnerability report in the last twelve months; the private report history is unavailable. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_response_process]
    Dies steht im Zusammenhang mit vulnerability_report_process, welcher erfordert, dass es eine dokumentierte Möglichkeit gibt, Schwachstellen zu melden. Es bezieht sich auch auf vulnerability_report_response, welcher eine Antwort auf Schwachstellenberichte innerhalb eines bestimmten Zeitrahmens erfordert.

    The published policy describes coordinated reporting/handling and an initial response/assessment timeframe. Actual historical response performance is assessed separately. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/SECURITY.md


 Qualität 19/19 ●

 Sicherheit 11/13 ●

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). [implement_secure_design]
    Beispielsweise sollten die Projektergebnisse fehlersichere Vorgaben haben (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation von Projekten sollte standardmäßig sicher sein). Die Projektergebnisse sollten auch eine vollständige Vermittlung haben (jeder Zugang, der begrenzt werden kann, muss auf Autorität überprüft werden und nicht umgangen werden können). Beachten Sie, dass in einigen Fällen Prinzipien in Konflikt geraten, in welchen eine Entscheidung getroffen werden muss (z.B. viele Mechanismen können die Dinge komplexer machen, gegen die "Wirtschaftlichkeit des Mechanismus" verstoßen / halten Sie es einfach).

    The security documentation and current implementation describe challenge signing, replay protection, credential ownership checks, rate limiting, enumeration defenses and validation of WebAuthn payloads. These provide project-specific evidence of the maintainer security design/implementation assessment. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    The extension delegates WebAuthn/FIDO2 cryptography to the FLOSS web-auth library and PHP cryptographic primitives, uses HMAC-SHA256 for challenge integrity where applicable, and secure random_bytes-based challenges/nonces. No custom cipher implementation is used. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/composer.json https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/Service/


    Genug für ein Badge!

    Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. [crypto_algorithm_agility]

    The WebAuthn ceremony configuration supports selecting multiple standard secure signing algorithms (ES256, ES384, ES512 and RS256), with the FLOSS web-auth library constructing the allowed algorithm manager. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Classes/Service/WebAuthnCeremonyFactory.php https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). [crypto_credential_agility]

    Registering/revoking public passkey credentials demonstrates replacement but does not by itself establish separate-file storage of every authentication secret/private key. Authenticators own private keys, while server-side challenge secrets are delegated to TYPO3; confirm the applicable storage boundary. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst


    Genug für ein Badge!

    Die vom Projekt produzierte Software SOLLTE sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 SOLLTEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    This authentication extension owns the WebAuthn ceremony and credential validation, not a TLS client/server implementation. HTTPS is a hosting requirement configured by the TYPO3 web server; the extension makes no project-owned outbound TLS connection. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    This authentication extension owns the WebAuthn ceremony and credential validation, not a TLS client/server implementation. HTTPS is a hosting requirement configured by the TYPO3 web server; the extension makes no project-owned outbound TLS connection. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_certificate_verification]
    Beachten Sie, dass eine falsche TLS-Zertifikatsüberprüfung ein häufiger Fehler ist. Weitere Informationen finden Sie unter "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" von Martin Georgiev et al. und "Do you trust this application?" von Michael Catanzaro.

    This authentication extension owns the WebAuthn ceremony and credential validation, not a TLS client/server implementation. HTTPS is a hosting requirement configured by the TYPO3 web server; the extension makes no project-owned outbound TLS connection. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_verification_private]

    This authentication extension owns the WebAuthn ceremony and credential validation, not a TLS client/server implementation. HTTPS is a hosting requirement configured by the TYPO3 web server; the extension makes no project-owned outbound TLS connection. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


  • Sicheres Release


    Genug für ein Badge!

    Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). [signed_releases]
    Die Projektergebnisse umfassen sowohl Quellcode als auch alle erzeugten Ergebnisse, falls zutreffend (z. B. ausführbare Dateien, Pakete und Container). Generierte Ergebnisse können separat vom Quellcode signiert werden. Diese DÜRFEN als signierte git-Tags (mit kryptographischen digitalen Signaturen) implementiert werden. Projekte DÜRFEN generierte Ergebnisse getrennt von Werkzeugen wie git behandeln, aber in diesen Fällen MÜSSEN die separaten Ergebnisse separat unterzeichnet werden.

    The inspected current release publishes versioned ZIP/tar archives, checksums and Sigstore signature bundles. The downloaded ZIP matches its GitHub SHA-256 digest and its GitHub attestation was cryptographically verified for the netresearch/typo3-ci-workflows release workflow. Release notes document verification. Keyless signing uses an ephemeral CI identity, not a private key hosted at the public download site. Verification scope is the current ZIP provenance, not every historical artifact. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/releases/tag/v1.0.0 https://github.com/netresearch/typo3-ci-workflows/blob/main/.github/workflows/release-typo3-extension.yml


    Genug für ein Badge!

    Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. [version_tags_signed]

    The latest release uses an annotated Git tag and GitHub verifies its cryptographic signature as valid. This confirms the current important tag rather than merely a signature on a commit. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/tags https://api.github.com/repos/netresearch/t3x-nr-passkeys-be/git/tags/d0ea12da3ad0c27036c46229243538af2317cd0f


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. [input_validation]
    Beachten Sie, dass der Vergleich der Eingabe mit einer Liste von "schlechten Formaten" (aka einer *Denylist*) normalerweise nicht ausreicht, weil Angreifer oft um eine Denyliste herumarbeiten können. Insbesondere werden Zahlen in interne Formate konvertiert und dann überprüft, ob sie zwischen ihrem Minimum und Maximum (inklusive) liegen und Textstrings werden überprüft, um sicherzustellen, dass sie gültige Textmuster haben (z.B. gültige UTF-8, Länge, Syntax, etc.). Einige Daten müssen möglicherweise "irgendetwas" (z. B. ein Datei-Uploader) sein, aber das ist typischerweise selten der Fall.

    The security documentation and current implementation describe challenge signing, replay protection, credential ownership checks, rate limiting, enumeration defenses and validation of WebAuthn payloads. These provide project-specific evidence of the maintainer security design/implementation assessment. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. [hardening]
    Härtungsmechanismen können HTTP-Header enthalten wie Content Security Policy (CSP), oder Compiler-Flags (z.B. -fstack-protector), um Angriffe zu mildern, oder Compiler-Flags, um undefiniertes Verhalten zu eliminieren. Für unsere Zwecke wird das Prinzip des kleinsten Privilegs nicht als Verhärtungsmechanismus betrachtet (trotzdem ist es wichtig, aber an anderer Stelle).

    The prior justification described CI runner/workflow protections. This criterion concerns mitigations in the delivered software. Applicable runtime mechanisms and their deployment defaults remain to be established. Evidence: https://www.bestpractices.dev/en/projects/12037 https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/Classes/


    Genug für ein Badge!

    Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. (URL erforderlich) [assurance_case]
    Ein "Assurance Case" ist ein dokumentierter Beweis, der ein überzeugendes und gültiges Argument enthällt, dass ein bestimmter Satz kritischer Ansprüche bezüglich der Eigenschaften eines Systems für eine gegebene Anwendung in einer gegebenen Umgebung hinreichend erfüllt ist ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al., NIST Interagency Report 7608 ). Vertrauensgrenzen sind Grenzen, in denen Daten oder Ausführung ihr Vertrauensniveau ändern, z.B. die Grenzen eines Servers in einer typischen Webanwendung. Es ist üblich, sichere Designprinzipien (wie Saltzer und Schroeer) und gemeinsame Implementierungssicherheitsschwächen (wie die OWASP Top 10 oder CWE/SANS Top 25) aufzurufen und zu zeigen, wie diesen entgegengewirkt wird. Die BadgeApp Assurance Case kann ein nützliches Beispiel sein. Dies bezieht sich auf documentation_security, documentation_architecture und implement_secure_design.

    The project documents its WebAuthn threat boundaries and countermeasures, connecting authentication threats to challenge/nonce validation, credential ownership, rate limiting and implementation/test controls. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/Documentation/Security/Index.rst


 Analyse 2/2 ●

  • Statische Codeanalyse


    Genug für ein Badge!

    Das Projekt MUSS mindestens ein statisches Analyse-Tool mit Regeln oder Ansätzen verwenden, um nach bekannten Schwachstellen in der analysierten Sprache oder Umgebung zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache implementieren kann. [static_analysis_common_vulnerabilities]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    The actual CI security job runs Opengrep against PHP security rules on proposed changes; PHPStan additionally supplies type/quality analysis where enabled. CodeQL is not claimed as PHP analysis. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/actions/runs/36537059651/job/109308209427 https://github.com/netresearch/typo3-ci-workflows/blob/main/.github/workflows/security.yml https://github.com/netresearch/t3x-nr-passkeys-be/blob/48785bf47859ad27362620f109940801642e7ae6/.github/workflows/checks.yml


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Wenn die Projektsoftware Software mit einer speicherunsicheren Sprache (z.B. C oder C ++) enthält, MUSS mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Applikationsscanner) routinemäßig in Kombination mit einem Mechanismus verwendet werden, welche Speichersicherheitsproblemen wie Puffer-Cach Überschreibe erkennen. Wenn das Projekt keine Software verwendet, die in einer speicherunsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    The project itself contains PHP/JavaScript/TypeScript/shell/configuration source, not project-owned C/C++ or another memory-unsafe native implementation. Runtime dependencies do not change the language of project source. Evidence: https://github.com/netresearch/t3x-nr-passkeys-be/tree/48785bf47859ad27362620f109940801642e7ae6/



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/12037/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Sebastian Mendel und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Sebastian Mendel.
Eintrag erstellt: 2026-02-25 16:10:18 UTC, zuletzt aktualisiert: 2026-09-29 15:17:25 UTC. Letztes verlorenes Badge: 2026-09-29 15:17:25 UTC. Letztes erreichtes Badge: 2026-02-25 16:42:22 UTC.