Event Sourcing and password change security implications

Question

I have recently started working towards Event Sourcing, when the question of password updating came up.

My understanding is the following:

1. Events are stored in an event store, which acts as a single source of truth for the current application and object state. We might replay the series of events for a given object since the creation of said object, and find the current state of the object.

2. Events must be stored indefinitely, as a break in the chain leads to potentially inconsistent state. We might make a snapshot of an event chain (i.e. the object's current state) if there are too many events to process every time for some view.

For me, this has clear security implications when it comes to something like user updated password. In this case, we would see something like:

- UserCreatedEvent(user)
- ... // other events that might change the state of the User object
- UserChangedPasswordEvent(updatedPassword)

The problem I see with this approach is that for the application to retain a consistent state, we must store all prior passwords of the user, because we cannot tell whether a given password is the current one or just one of the user's previous passwords (given only the UserChangedPasswordEvent).

For the sake of argument, let's say that the application stores passwords using a weaker algorithm other than BCrypt and that passwords are crackable after a given timeframe (ie. brute-force / rainbow table).

In the case of event sourcing, an attacker that manages to get ahold of the UserChangedPasswordEvent store will now have a list of all the passwords that the user has ever used within the application. In this scenario, it is not unlikely that they would have access to the UserCreatedEvent store consequently the (usually) unique email of the user as well.

Since most casual users unfortunately reuse passwords across various platforms, an attacker would now potentially have access to any number of passwords that the user might have ever used across multiple platforms. This is made even worse if there is a mechanism such as 'mandatory password renewal after X time'.

Despite this, is this the most common approach with event sourcing and password updates, or is there a standardized way to handle this part of the application? I admit the premise of the scenario (weak password hashing) is a weak, but it best gets my point across.

I can think of two ways to handle this:

• Encrypted event stores and/or file system; impacts performance
• UserChangedPasswordEvent only informing of the change itself, password being stored elsewhere through another channel; goes against the idea of event sourcing, however)

Am I overthinking the issue here? Is there an issue here, if proper hashing algorithms are used?

Answer 1

Indeed, storing password inside events is a very dangerous thing to do but you have no real reason to store the password inside the event payload. In fact you may not even use Event sourcing for the UserCredentialsSubdomain or the entire AuthenticationDomain.

If you still decide to use Event sourcing for the AuthenticationDomain (which is not necessarily bad thing), you don't need to store the password inside UserChangedPasswordEvent because you don't need the entire password history (hashed or cleartext) inside your Write model. The last password (or hash) is used only by the Authentication service to verify the identity of an user. No other Read model needs this; the use cases where you would need the recent password history (i.e. to not permit changing to an old password) can be implemented using a password log or something similar, you don't need Event sourcing for this. The UserChangedPasswordEvent could be useful, for example to show to the user the last date when the password was changed, but without containing the password itself.

UPDATE after comments:

You are not required to use ES for the entire application, it's not all ES or all Non-ES. In general, for Authentication, people use a flat model. But if you choose to use ES, you can still use it to rebuild the UserAggregate's state even if you don't have the User's password because you don't actually need that password inside this state.

In this case that I'm referring to, password checking is done before the UserAggregate (the owner of the event stream) handles the LoginCommand, by calling a PasswordCheckingService that uses a flat persistence. This is done in the Application layer: first the password is checked then login is further checked by the UserAggregate (i.e. if the user is still active it may login).

In fact excluding the password from the event stream makes you realize that verifying user identity should be a separate subsystem, along with verification by phone or by biometric scanning. This would change your architecture a bit, making it more clear, in my opinion. The whole identity verification could be hidden behind a simple interface with multiple implementations.

Wouldn't the scenario you describe explicitly make some other kind of call

No, it wouldn't or at least not in the rebuilding of the Aggregate's state. That remote call would be done in the Application layer.

Calling external services when rebuilding state is against event sourcing - the event stream must be sufficient.

Answer 2

Fundamentally, storing a history of passwords isn't really different from storing one password - the same kinds of concerns arise.

To my knowledge there isn't one "standardized way" to handle thing, but a number of different approaches that various people are trying

1. Store the actual password outside of the event stream.

2. Store the password in the event, but encrypt the value so that it is only available to authorized processes.

This is a fairly hot topic right now, because GDPR; what does it mean to store secrets in a persistent data store when data subjects have a right to erasure.

The implementation I've seen discussed most often is the use of a unique encryption key for each data subject, so that if you need to "erase" the data you discard the key. (Note: it's not clear that such an approach will satisfy the courts.)

More broadly, one needs to keep in mind that "events" are serving multiple purposes, and we don't need to use the same events, or the same representations, for both. You've got the "private" persistence store, which allows this domain model to reconstitute its own state, and then you have the "public" representations, that are published for use by other services as they see fit.

So for instance, as the password management service, I might broadcast an event to the world that Bob changed his password, but not include the new password in the public representation.

Review Udi Dahan on service boundaries, or his talk on finding service boundaries in health care.