jdumont
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?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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.
Phillipp
Then you loose any ability to validate your password against length and complexity. That, for me, is a big no no. And please, please don’t respond with “client validation”.
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
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.
Fl4m3Ph03n1x
Frontend validation also has its issues (I’ll give you that), as it can easily be bypassed. I picked option 2 because from reading the question I understood I could only pick 1 or 2. But it really does depend on the case. If your UI is talking to a public REST API, you may want to have it in both places.
If your app is being used inside a company within their private intranet, UI validation is likely good enough.
It all comes down where you want your validation to happen - sometimes you may even want validation on both sides:
Phillipp
The UI has to communicate somehow with the backend and at some point, something is being sent to the server. If it’s the user-entered password or the generated hash, doesn’t matter since a MITM attack works for both.
Fl4m3Ph03n1x
I just edited my post to remove that comment. It figures your typing skills would superseed mine xD
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
Likely my fault, since I miss understood the question and then directed the topic in the wrong direction from that point forward =(
I will show myself out.
Phillipp
And I got triggered. So, lets agree on 50/50.