I’m about to start a new project based on the excellent Phoenix framework (great work btw !) but I’m having a hard time deciding what auth lib I should deploy. Guardian/JWT is not really an option right now (session-based client/server).
Stateful sessions will be stored in Redis.
Phauxth was the first library I tested because I knew comeonin. But it lacks many features compared to Coherence and only 1 release so far (few commits, not very active). What about security ?
Based on hex.pm stats coherence 0.5.0 was downloaded almost 5,000 times. If the security issue reported by GriffinMB is not fixed that makes a lot of hackable websites/apps
I’m looking at coherence source code right now to see if I understand this issue correctly. I’ve been learning FP/Elixir for 2 months now but I did not expect that it would be that hard to find a suitable/secure auth lib.
I had experimented with Phoenix first time some 2 years ago, in the recent 2 months I invested more time in it. Correct, there should be more fully developed libraries. But things are getting better fast.
Do you use some library for storing sessions in Redis and do you aim at validating sessions server-side on every request?
Nothing yet regarding Redis. I’ve used clustered Redis/memcached stores with Java/Go before, not with Elixir.
But first I must choose an authentication library. Coherence seemed ok but this changeset issue is a no-go (no pun intended) right now.
I will update the original issue to include additional information in the next week or so. But, at a high level (for anyone reading this in the mean time), anything in the user’s changeset method can be updated by any of the library’s user-update functions. That could be registration, or updating the user profile, etc.
For example:
def changeset(model, params \ %{}) do
model
|> cast(params, [:your, :params] ++ coherence_fields)
|> validate_required([:name, :email])
|> unique_constraint(:email)
|> validate_coherence(params)
end
Here, :your, :params, and any coherence_fields can be set by a user updating an account, or registering. If you have any sensitive fields exposed in the changeset function, or are relying on any of the default fields (like confirmed_at) not being user-editable, your application is vulnerable to this issue. If you only allow login, but not registration or account updates, this issue may not be exploitable within your app.
This should be a fairly simple change in Coherence. I just need go update the coherence helpers to remove some of the fields, so only the ones that should be changeable are exposed in the appropriate controllers. In the interim, its would be pretty simple to resolve this in your application. Generate the coherence controllers and replace the coherence_fields with your own list of the appropriate fields.
@merlin Thanks for raising your concerns here. I really do need to get this resolved! I appreciate you lighting a fire under my butt to deal with these security issues.
Correct me if I am wrong, but this issue concerning Coherence is found in any situation where a User model is exposing a path to update User changeset parameters.
This forum is the bog-standard Discourse, it loads a lot of javascript though once loaded you should be able to navigate around pretty instantly.
I tend to choose Ueberauth as it does not have any front-end stuff messing things up, it is just an interface.
However, that does mean you need to set up more things. If however all you need is local logins (no OAuth like Google or Facebook or Steam or whatever) then Coherence is fine, but if you need others then Coherence is not as useful (and becomes pretty useless when you don’t need local at all, it is local-auth only, currently). Coherence also mandates a shape of the stored data, which may be fine for you or not too. ^.^
@smpallen99 Thanks for this library and for all the work/time you spend on improving its code !
We see so many hacks these days that I believe security is of utmost importance esp. for an auth library. Sorry for your butt
@acrolink That’s precisely what I’m trying to understand because I see many code samples with role field on user model. Maybe it’s possible to bypass the cast function by injecting specially crafted values.
With Safari on iOS 11 it takes between 6 and 8 seconds to render any page, even with js cached.
Time to ditch Discourse and install Firestorm
Except for the security issues Coherence should be perfectly fine for my project, I don’t need any kind of external auth. I’ll split my user model in public/private interfaces to avoid a potential injection.
Firestorm lacked a lot of features last I saw though. ^.^;
Plus the heck are you talking about with 6 to 8 seconds?!? Does Safari really suck that much (though it would not surprise me considering apple…)… Here is my phone, and I’ve not loaded elixir forums on it in at least a few weeks and I am on the very slow wifi at work:
That’s the problem, use at least a half-decent device! ^.^
For note, even my old Nexus 6 (also a 2014-era phone) loads this site at the same speed as the above animation as well, so it is not an ‘era’ thing.
Yeah, Discourse uses Ember, which is quite questionable in my opinion, but eh… >.>
What I understood is that you need to use different changeset definitions for various action paths. Example, OAuth2 library can use one changeset definition which allows it to set the email field (based on the one obtained by the external authentication provider). Another (updating profile data by user), allows him to set first name, last name, gender etc but not role_id / role name or email address.
Inside the action code in controller, you choose which changeset definition you send the params to.
For anyone looking for oAuth integration with Coherence, take a look at the coherence_assent package someone showed me yesterday. I have not tried it, but I was pretty impressed after reviewing the code.
I’ve been brewing some ideas for the last couple days about a serious rewrite of coherence. @OvermindDL1 I’m interested with your comment [quote=“OvermindDL1, post:11, topic:10221”]
Coherence also mandates a shape of the stored data
[/quote]
I’d love to see an example of a data shape that causes a problem with Coherence.
For those interested, I have three main items that I’m looking to solve at this point (hope to expand this list)
The security issues (probably doesn’t require a redesign, only some API changes)
Reduce the effort required for upgrades (for examples, custom controllers should pull in the default actions with a using macro that are overridable)
Reduce the complexity for adding/removing options after the initial coherence mix task.
Well in the system I have to deal with the user data exists spread across a dozen tables (not kidding) in an oracle database that I do not control, it has to match that. ^.^;
In addition I don’t need email password resets or anything else like that, password resets are handled by the employee ID number and some personal information about them.
Etc…
Honestly if no mix tasks were needed at all that’d be best, a pure library driven approach, no out-of-context code gen.
