jdumont
When to hash password in event sourced system
Hey all,
I’ve been learning event sourcing with Commanded lately and wanted to double-check when to hash a password — I think I already know the answer though!
I have an Accounts context with User and Credential aggregates. The RegisterUser command is passed the users name, email address and plain-text password. The User aggregate only handles their name, with email and password heading to the Credential.
I had originally planned to hash the password in the CreateCrendential command, as that seems the most logical place. However, because the CreateCrendential command is triggered by the UserRegistered event, that would mean that the unhashed password would get serialised into that event — obviously a big no-no!
That leaves me with two options:
- Hash the password as soon as it hits my system, which at the moment would be in the
RegisterUsercommand. - Change the order. The form submission (or endpoint submission) issues the
CreateCredentialcommand, which hashes the password (more logical place for this to take place) and then theRegisterUsercommand responds to theCredentialCreatedevent.
Option 1 feels like a bodge, so I’m inclined to go with option 2. Only issue is that the User UUID is created/assigned in the CreateCredential command, rather than the RegisterUser command. I don’t see this as much of an issue though as both aggregates would store this UUID anyway.
Thoughts? Does changing the order of commands/events make the most sense and avoid storing unhashed passwords in a logical way?
Most Liked
NobbZ
He is right, sending unencrypted passwords is a NONO, no one should use HTTP anymore with letsencrypt beein available for free.
But I do support you, in the regard, that one should not hash client side. This will not only make you loose the validation opportunities as you say, but it will basically leak the hashing secret…
Or even worse, the hash itself becomes volatile as a plain text password, and an attacker that gains access to the database gains access to all user accounts.
Phillipp
And I got triggered. So, lets agree on 50/50.
Phillipp
Hashing client side means, that the hash is the “new password” and a MITM attack would just work fine. All ya need is the hash then.
LostKobrakai
I’m actually wondering how this went to a client/server side discussion. The initial poster asked about eventsourcing and how to structure password hashing in an event sources system without storing the pw in an event. There’s no “client” involved at that stage. It’s all server side.
Fl4m3Ph03n1x
When it comes to passwords and security, you want your passwords to be hashed as soon as possible. Having your UI sending an un-encrypted password to your backend for processing is a big no no, as it makes your system vulnerable to man in the middle attacks.
I would personally go for option 2.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"