Timeline for answer to Is devise's token_authenticatable secure? by Ashitaka
Current License: CC BY-SA 3.0
Post Revisions
34 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 26, 2017 at 15:15 | history | edited | Ashitaka | CC BY-SA 3.0 | Correct answer since Ruby 2.5's SecureRandom is safe! |
| Aug 28, 2017 at 13:29 | history | edited | Ashitaka | CC BY-SA 3.0 | Add note concerning ActiveSupport::SecurityUtils.secure_compare |
| May 23, 2017 at 12:10 | history | edited | URL Rewriter Bot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Mar 16, 2017 at 10:47 | history | edited | Ashitaka | CC BY-SA 3.0 | added 13 characters in body |
| Mar 16, 2017 at 1:45 | history | edited | Ashitaka | CC BY-SA 3.0 | Improved answer - clarified a lot of sections and added even more links |
| Jan 11, 2016 at 0:12 | comment | added | fatfrog | I disagree, if a hacker or disgruntled employee has access to your database, then tokens are the last thing you need to worry about. They already have your data. | |
| Jan 10, 2016 at 22:29 | comment | added | Ashitaka | @fatfrog No. Token == password. If a hacker or a disgruntled employee has access to your database he should not be able to authenticate as a certain user or admin. | |
| Jan 10, 2016 at 14:10 | comment | added | fatfrog | token != password. There is nothing wrong with storing a token in plain text. The problem with storing passwords in plain text is the password can be used somewhere else, that shouldn't be the case with your token. | |
| Sep 24, 2015 at 5:20 | history | bounty awarded | Aaron Gray | ||
| Dec 31, 2014 at 12:50 | comment | added | Ashitaka | That is what I meant when I originally wrote this answer, but I edited that part out a while ago. I hope that is clearer now. | |
| Dec 31, 2014 at 12:48 | history | edited | Ashitaka | CC BY-SA 3.0 | Add link to GitHub session management and reword phrase |
| Dec 31, 2014 at 2:46 | comment | added | Segfault | @Ashitaka this is a very good answer, but will you please clarify what you mean in your second point? It says "one-time random token" which I took to mean it should only be used one time and then be invalidated. But from the context of the rest of your answer I don't think this is what you mean. Also the phrase "cryptographic strength" isn't clear to me, I think you mean "cryptographically strong" or something right? | |
| Aug 18, 2014 at 23:48 | history | edited | Ashitaka | CC BY-SA 3.0 | Created link to SecureRandom stdlib and updated Devise link |
| Aug 18, 2014 at 23:42 | history | edited | Ashitaka | CC BY-SA 3.0 | Removed recommendation to use a token only once. That mostly applies to systems with use-once refresh tokens like OAuth |
| Jul 6, 2014 at 2:14 | history | edited | Ashitaka | CC BY-SA 3.0 | added 121 characters in body |
| Mar 13, 2014 at 23:52 | comment | added | Ashitaka | user = User.find(id) or user = User.find_by_email(email) followed by Devise.secure_compare(user.auth_token, params[:auth_token]). | |
| Mar 13, 2014 at 22:16 | history | edited | Ashitaka | CC BY-SA 3.0 | Added link to Devise's secure_compare method |
| Mar 13, 2014 at 22:08 | comment | added | LightBox | What is the timing safe alternative to User.find_by_auth_token(params[:auth_token])? | |
| Feb 28, 2014 at 12:57 | history | edited | Ashitaka | CC BY-SA 3.0 | added 582 characters in body |
| Feb 20, 2014 at 23:38 | history | edited | Ashitaka | CC BY-SA 3.0 | Added link to blog post about timing attacks |
| Feb 5, 2014 at 18:42 | history | edited | Ashitaka | CC BY-SA 3.0 | added 214 characters in body |
| Feb 4, 2014 at 14:20 | history | edited | Ashitaka | CC BY-SA 3.0 | added 485 characters in body |
| Dec 17, 2013 at 23:41 | history | edited | Ashitaka | CC BY-SA 3.0 | added 97 characters in body |
| Oct 17, 2013 at 16:09 | history | edited | Ashitaka | CC BY-SA 3.0 | added 34 characters in body |
| Oct 7, 2013 at 22:29 | comment | added | Ashitaka | While both methods generate a random string, urlsafe_base64 generates a url-safe string. It's all in the name. Unless you want to use your token in your url (which you shouldn't), use hex. | |
| Oct 7, 2013 at 20:03 | comment | added | DiegoSalazar | What's the benefit of SecureRandom.hex over say SecureRandom.urlsafe_base64? | |
| Oct 7, 2013 at 14:46 | history | edited | Ashitaka | CC BY-SA 3.0 | Fixed link |
| Sep 13, 2013 at 3:44 | history | bounty awarded | Jeff Escalante | ||
| Sep 13, 2013 at 3:43 | vote | accept | Jeff Escalante | ||
| Sep 11, 2013 at 16:19 | history | edited | Ashitaka | CC BY-SA 3.0 | added 1268 characters in body |
| Sep 11, 2013 at 15:12 | comment | added | Ashitaka | What I described is the most secure way to handle API authentication, dunno what you mean by "best". But I'll try to be as specific as I can. | |
| Sep 11, 2013 at 3:42 | comment | added | Jeff Escalante | Awesome, this helps a lot - thank you! This will almost definitely get the right answer. Bounty is yours if you add to this your opinion/recommendation (specifically) on the best way to handle API authentication : ) | |
| Sep 9, 2013 at 9:39 | history | edited | Ashitaka | CC BY-SA 3.0 | added 473 characters in body |
| Sep 9, 2013 at 9:27 | history | answered | Ashitaka | CC BY-SA 3.0 |