It is good to see the development of new social sites for the fandom. We benefit from increased options, and it's clear that the developer/lead admin of this site really wants to make it one of the better options.
This makes it all the more unfortunate that, despite the concern for security and the now-default use of HTTPS on login, the site retains several core issues which I previously mentioned to the developer:
FurrTrax stores login information in cookies, sent to the server with each request, rather than providing a session-specific cookie. This means anyone with access to your browser has access to your credentials, even if you did not "save" them in your browser.
The cookies are not marked as secure if you login over HTTPS, but are available in HTTP mode, so even if you think you are accessing the site securely, an attacker might cause you to expose them over a public connection by viewing any site where they can embed images.
Moreover, FurrTrax lets you retrieve your password, which suggests that anyone who did manage to break in to it - or gain access to your email account - would be able to retrieve it as well. The one saving grace here is that this feature doesn't actually seem to be working, though I suspect that's just because it can't send you the email.
Writing it all yourself gives you control, but it is not always the best idea when it comes to the foundations. It's been over a decade since it was best-practice to store a one-way salted hash of the password that cannot be feasibly retrieved, and established frameworks do that. There is no need for the password itself to ever hit the database - it just needs to be processed identically on login and the result compared.
Visitors to FurrTrax should not use a password which is used anywhere else (which is good practice in any case).
It is good to see the development of new social sites for the fandom. We benefit from increased options, and it's clear that the developer/lead admin of this site really wants to make it one of the better options.
This makes it all the more unfortunate that, despite the concern for security and the now-default use of HTTPS on login, the site retains several core issues which I previously mentioned to the developer:
Writing it all yourself gives you control, but it is not always the best idea when it comes to the foundations. It's been over a decade since it was best-practice to store a one-way salted hash of the password that cannot be feasibly retrieved, and established frameworks do that. There is no need for the password itself to ever hit the database - it just needs to be processed identically on login and the result compared.
Visitors to FurrTrax should not use a password which is used anywhere else (which is good practice in any case).