Loading...

Write your own PasswordEncoder. NOT!

29. Juni 2023
2 Minuten Lesezeit
Beitrag teilen:

Hi,

Hast du schon mal einen eigenen Passwort-Encoder geschrieben? Ich zwar nicht direkt - aber ich musste einen selbstgezimmerten benutzen. In einem zentralen User-Management-Service liefen die Kundendaten aller Nutzer zusammen. Und in diesem wurden die Passwörter gespeichert. Bei der Registrierung eines neuen Users musste also der gleiche Encoder genutzt werden.

Es ist uns in der Praxis - zum Glück - nicht um die Ohren geflogen. Aber es war höchst kritisch. Das Encoding war nicht stark. Der Salt basierte noch auf MD5. Das war bereits zu dieser Zeit kein starker Hashingalgorithmus mehr. Die banale Lösung es “sicherer” zu machen: Einfach zwei mal anwenden. Da kommt niemand drauf 🤦‍♂️

So banal das für dich beim Lesen klingen mag - es gibt noch genügend Anwendungen da draußen, die ähnlich “sicher” sind. Vielleicht fällt dir direkt eine ein.

Security-Themen gehören in die Hände von Profis. Deswegen unterhalten viele Firmen ganze Abteilungen mit Security Experten. Wenn du an einem Projekt arbeitest, dass diesen Luxus nicht hat, dann halte dich an Standards. Dein Framework gibt dir die notwendigen Tools mit.

Im Spring Framework kannst du den DelegatingPasswordEncoder nutzen. Wenn du das machst, dann wird die Information über den genutzten Algorithmus mit dem Passwort abgespeichert. Sobald sich der Standard verändert - und das wird er - kann Spring den default algorithmus selbständig umstellen. Du wirst es nicht einmal merken. Vorausgesetzt, du updatest Spring regelmäßig.

Wie das genau funktioniert habe ich 2021 bereits in einem Blog Post beschrieben .

Es muss nicht schwer sein die Sicherheit deines Systems zu erhalten.

In diesem Sinne.

Rule the Backend,

~ Marcus

Top