Authentication DIY

[0x01]

I decided to hand-roll the authentication for my rails app and wonder what are some gotchas I should know about? I have read the rails security guide/owasp and skimmed through the Sorcery codebase. I will be using the builtin has_secure_password and has_secure_token

I am aware of the session fixation attacks, so in order to prevent them, I reset the session every time user logs in. Also, password reset tokens have very short expiry time and can be used only once (tokens aren't hashed though, see: https://news.ycombinator.com/item?id=5033266). I have also read about timing attacks, but not sure whether it is a material thing to worry about (i.e. leaking info about the system)

Assume all usual suspects are covered: TLS, HSTS, strict CSP, CSRF tokens, samesite cookies (lax) with "__Host-" prefix + secure/httponly flag, security headers, encrypted DB at rest, password hashing with bcrypt with high number of iterations.

P.S. I know that there are several gems that provide auth functionality, but i still want to roll it myself.

[İsmail Arılık]

You can get help from here:  https://www.railstutorial.org/book

In this book, the author implements authentication without using a package.

Also Devise which is the most popular authentication package for Rails recommends this way to beginners: https://github.com/plataformatec/devise#starting-with-rails (You can also get help from the links in this link.)

0x01 <mansur.m...@gmail.com>, 5 Nis 2019 Cum, 13:17 tarihinde şunu yazdı:

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/85710628-c592-44cb-a251-1d919f9ddee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

İsmail Arılık about.me/arilik.ismail

[0x01]

Thanks for taking the time to write in!

I have already perused resources that you have linked before writing this post. I was looking for more advanced material, hence decided to write to here.

All the best!

You can get help from here:  https://www.railstutorial.org/book

In this book, the author implements authentication without using a package.

Also Devise which is the most popular authentication package for Rails recommends this way to beginners: https://github.com/plataformatec/devise#starting-with-rails (You can also get help from the links in this link.)

0x01 <mansur.m...@gmail.com>, 5 Nis 2019 Cum, 13:17 tarihinde şunu yazdı:

I decided to hand-roll the authentication for my rails app and wonder what are some gotchas I should know about? I have read the rails security guide/owasp and skimmed through the Sorcery codebase. I will be using the builtin has_secure_password and has_secure_token

I am aware of the session fixation attacks, so in order to prevent them, I reset the session every time user logs in. Also, password reset tokens have very short expiry time and can be used only once (tokens aren't hashed though, see: https://news.ycombinator.com/item?id=5033266). I have also read about timing attacks, but not sure whether it is a material thing to worry about (i.e. leaking info about the system)

Assume all usual suspects are covered: TLS, HSTS, strict CSP, CSRF tokens, samesite cookies (lax) with "__Host-" prefix + secure/httponly flag, security headers, encrypted DB at rest, password hashing with bcrypt with high number of iterations.

P.S. I know that there are several gems that provide auth functionality, but i still want to roll it myself.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/85710628-c592-44cb-a251-1d919f9ddee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fatih Orhan]

Chrome does not expire cookies, ever. Even when you set correct parameters. So don't rely on the browser to invalidate cookies after browser closes or after some duration offline. We keep last request time in session data and expire sessions server side.

Users will have their password stolen. log successfull and failed logins with IP to investigate later. And be prepared to add IP white listing and 2 factor auth later.