Durcir la comparaison du HEALTH_TOKEN (timing-safe) #17
Labels
No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: maximus/vps-health-api#17
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Le controle actuel compare le token de lecture par
auth !==+ interpolation, ce qui fuit la longueur et le prefixe par le temps de reponse. Aligner sur le helpertokenMatches(timingSafeEqual sur empreintes SHA-256, longueurs toujours egales).Fichiers concernes
index.js(modifier)Depends on
tokenMatchesarrive avec #13 ; sinon l'ecrire ici)Criteres d'acceptation
HEALTH_TOKENpasse partokenMatches()timingSafeEqualfuiterait la longueurReview caveats
fastify-bearer-auth(GHSA-376v-xgjx-7mfr) ou untimingSafeEqualmal utilise laisse deviner la longueur du token.Decisions prises en planification
status:ready: dette de securite tracee, a prendre quand tu veux.Spec source
la-compagnie-maximus/spec-plan-monitoring-postes.md + spec-decisions-monitoring-postes.md (Issue 8)