Write your own PasswordEncoder. NOT!

Hi,

Have you ever written your own password encoder? I haven’t exactly - but I had to use a homemade one. In a central User-Management-Service, the customer data of all users came together. And in this, the passwords were stored. Thus, when registering a new user, the same encoder had to be used.

In practice - fortunately - it did not blow up in our faces. But it was highly critical. The encoding was not strong. The Salt was still based on MD5. Even at that time, it was no longer a strong hashing algorithm. The trivial solution to make it “safer”: Simply apply it twice. No one will think of that 🤦‍♂️

As trivial as this may sound to you while reading - there are still plenty of applications out there that are similarly “secure”. Perhaps you can think of one right away.

Security issues belong in the hands of professionals. That’s why many companies maintain entire departments of security experts. If you’re working on a project that doesn’t have this luxury, then stick to standards. Your framework provides you with the necessary tools.

In the Spring Framework, you can use the DelegatingPasswordEncoder. If you do this, the information about the used algorithm is stored with the password. As soon as the standard changes - and it will - Spring can independently change the default algorithm. You won’t even notice it. Provided, you update Spring regularly.

I described how exactly this works already in a blog post in 2021 .

Maintaining the security of your system doesn’t have to be hard.

On this note.

Rule the Backend,

~ Marcus