Zequez
Security Issues
- Site is not served over HTTPS
- Account recovery page exposes account enumeration vulnerability (It says when an account doesn't exist, it should behave the same as if you had entered a valid account)
- Account recovery email should send a code which is to be entered on the page following the enter your email address page (Users should not be encouraged to click links in emails and then enter their password)
To be honest I find Ruby really hard to read so I'm unable to review this site in full, but if there's one thing I've learnt from working on authentication / authorisation systems it's that they are far from trivial.
I would strongly recommend moving over to a well-known OpenID Connect provider such as Google. These days sites (Especially small ones such as this which don't have security teams and robust review processes) should not be expecting users to entrust them with their credentials.
I would be happy to advise on integrating with an OpenID Connect provider, although it would have to be general language-independent advice I'm afraid.
The project is in the process of being ported to Python, and the authentication will be handled by the official API, so this will probably not be an issue in the future.
Most password recovery workflows work in that way, you get an email with a link, you click it, and then you enter the new password. You expect users to copy and paste a code somewhere to recover it? Seems quite counterproductive.
I agree with the account enumeration issue though, but it's not really such a big threat, and it's going to be deprecated anyway.
Didn't realise that it was getting re-written, thought it was a little strange that there hadn't been any commits in the past few months but that makes sense now.
Regarding password recovery, there are the two methods which are very similar in end result but have a subtle but, in my opinion, important difference.
Consider the verification code workflow:
- The user enters their email address in the account recovery form.
- Regardless of whether or not the email address exists, the user is taken to a page saying that an email has been sent and to enter the verification code from the email into a field on the page. (There's usually also a resend button on this page)
- The user receives an email with a code (Usually 6 characters or so) which they enter in the page which they still have open.
- The user enters their new password and confirm it.
I work on the single sign-on platform for Sage and this is the flow that we use for account recovers in that system. You'll also notice that it is similar to how Steam Guard works and a number of multi-factor systems. The main advantages are:
- The user isn't trained to blindly click links in emails and enter their password.
- The recovery initiation (Where you enter your email) and verification (Where you enter the verification code) can be tied to the same browser session which you can't do with the recovery link workflow.
It's a subtle difference and I doubt a penetration tester would pull up anyone for using the recovery link method, but please do consider the alternative.
I'd be happy to review the new site once it's done as I can follow Python much better.
I was planning on making a server browser but it sounds like the official stuff is well on its way so that might be a waste of time for me to do ?
@Zequez If you need help with porting to Python I'd be happy to contribute!
