Authentication and authorization demystified by example and experience

wolfiton

Hello everyone,

Today I would like to ask for your help on authorization and authentication

So at the moment i have the following migration

defmodule PhxApi.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :username, :string
      add :email, :string
      add :password_hash, :text
      add :role, :string
      add :confirmed, :boolean
      add :attempts, :integer
      add :locked, :boolean

      timestamps()
    end


    create unique_index(:users, [:email])
    create unique_index(:users, [:username])
  end
end

The following migration is used to take into account the following scenarios:

User
- registration
- login
- account confirmation
- user block by username and email

What would you add more to this migration and in general to take into account other security scenarios?

Also how you deal with users ip where would you store them?

Would you use ETS or mnesia for account confirmation?

Also other suggestions or you person experiences are welcomed
Thanks in advance

37 comments

/phoenix #ecto #authentication #authorization

0 2872 37

2019-11-22 14:32:08 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

I’d take a look at Pow or phauxth and how they handle things.

Why would you want to store IPs in the database?

I’m wondering why :attempts is a string. Sounds like it should be an integer.
Also while you have a confirmed field I’d additionally propose to separate email from unconfirmed_email, so on a change you don’t loose the already confirmed email until the new one is confirmed as well.

Post #1

wolfiton

Where would you recommend storing the ips?

You are right it should be a integer

Also very cool suggestion by using the unconfirmed_email and the confirmed_email strategy to have both

Thanks for providing your thoughts and ideas on this matter.

Post #2

LostKobrakai

Depends on why you want to store them.

Based on prev. conversations in another topic of yours: If you want to pin sessions to IPs, then it’s only natural to put the IP in the session itself. It will neatly cleanup after itself.

Post #3

wolfiton

Yes but thinking a little bit about attacks and user behavior wouldn’t it be a good idea to store them also somewhere else for the following case:

A non logged in user(bot or human) makes multiple requests just to generate a ddos(DENIAL OF SERVICE ATTACK) attack how can i stop it if they are not logged in?

Post #4

thojanssens1

Can you explain your idea please? (I’m still quite new)
Why do you need some kind of store in addition to the db for account confirmation?

Post #5

LostKobrakai

This is a valid use-case for storing an IP for a bit longer timeframe, possibly in a db, but this has nothing to do with a users table though. This would at least live in a totally separate part/table of your application. Generally I’d also suggest to move prevention of such attacks up the stack and use e.g. fail2ban or similar software or do it even at the dns level with cloudflare. This way your application(s) don’t need to deal with those issues.

Post #6

wolfiton

Mensia and ets are databases that are using the ram of the server so they are much faster for read and delete then a normal db.

Redis is a good example of this.

Also because you need the confirmation token which is basically a secret string to verify if the user that clicked the link form the email you sent for the account confirmation, is who it pretends to be and not someone else that wants to take control over another users account.

This idea is used for the confirmation of the account also if a user forgets a password.

If what i wrote is unclear please tell me and i will try to explain in another way.

Post #7

LostKobrakai

Why would you want to use ets or mnesia for that information though? Either the token can validate itself (signed token) or you need a persistent db, which you already have with ecto.

Post #8

wolfiton

In the past I used redis because those tokens don’t have a very long existence they are only necessary for that verification also they need to expire in let’s say 15 minutes.
So reading and writting to the db may become expensive.

Post #9

thojanssens1

Correct me if I’m wrong, but you did not really explain the reason WHY you want to use mnesia or ets for the account confirmation.

For example: is the reason because you do not want to store that secret token in the database? (security)
is the reason because of some performance optimization? (but then why limit performance optimization for that very specific case?)
etc.

Even if you use the RAM, won’t that create scalability issues (i.e. RAM is not shared among multiple servers) ?

Post #10

Load more posts (27 remaining)