AshAuthentication 3.9.1

jharton
2023-02-12

jharton:

Hi folks.

Thanks to <@816769011533742100> for noticing a pretty bad security issue where any token could be used for authentication regardless of it’s original purpose, meaning that password reset, confirmation and magic link tokens could all be used to authenticate a user against an API endpoint.

Obviously, this is a pretty big deal so please upgrade immediately.

zachdaniel:

In terms of “bad” I’m not so sure this is quite as bad as you’re making it sound. In all of these cases, acquiring one of these tokens would require access to the users email account, at which point they are pretty screwed already. Everyone should absolutely update to the new version, but we don’t want to oversell the danger there either.

jharton:

Yeah but the sender mechanism makes these transport agnostic. They could be sent via SMS or painted on the side of a bando for all we know. I agree that it’s pretty unlikely but we have to take potential security issues seriously

zachdaniel:

Agreed 👍

zachdaniel:

We could theoretically mark the previous releases as invalid which will warn people to upgrade.

jharton:

That would require yanking nearly all previous versions which I think is probably overkill.

zachdaniel:

Yeah…you’re probably right, but FWIW the packages would still be usable, just providing a warning. So a script could probably be written that would do mix hex.retire ash_authentication version security or w/e. So it wouldn’t break anyone’s current workflow, just provide a warning on mix deps.get IIRC.

zachdaniel:

but I agree that it might be a bit dramatic

zachdaniel:

Main point for readers though is that by “any token regardless of its original purpose” above doesn’t mean “a token for a different user”, or anything like that. It is highly unlikely that your users could or would be affected by this, but upgrade anyway 🙂