intro⌗

This is, perhaps unsurprisingly, another article on ft. Maybe, it will be the last one since the project is wrapping up quite nicely and the original roadmap has been pretty much fulfilled.

In this article, I’ll go over the simple authentication method on ft and the reasoning behind such an authentication system.

authentication systems cause ruin⌗

In my opinion, a lot of the attack vectors happen at the authentication level. Perhaps, the developer forgot to sanitize the password field and whoops, you have an SQL injection attack. Maybe, you have HttpOnly set to false and attacker had access to your javascript files, and collected your authentication cookies.

I’d rather not implement an authentication system because I am not up to speed with how to maintain secure authentication systems. Plus, it takes a lot of time to actually implement one. In all of my previous projects, authentication pretty much took most of the time that I developed on the project, and it always left me exhausted.

I didn’t want ft to suffer the same consequences as I will need to use it and there is no other, not that I could tell, remote file transfer system. So, I settled on a pretty simple authentication system that doesn’t even have tests.

ft’s authentication system⌗

ft’s authentication system is quite different in the idea that there is no database to hold user credentials, there is no username/password, there is no password reset and finally no biometric authentication.

ft handles authentication through a connection to the /sse route. Any client that connects to that endpoint is ultimately a user and should be treated as such.

All users have the ability to:

  • Create Operations
  • Modify those their own operations
  • Delete their operation
  • See all operations(include others)
  • Modify the filesystem
  • Delete some files from the filesystem

Essentially, it is passwordless authentication that doesn’t have a permission system. You might be thinking: “But, hey, isn’t this too simplistic, who would want to use this?”

And to that I say: “Lots of people”. Because there is another form of authentication and it is through one api key.

If you set the environment variable API_KEY, that makes it so all requests must have that same API_KEY in the Authorization: Bearer header. Through this form of authentication, outsider applications can get to use ft’s file transferring capabilities without much hassle while assigning correct permissions.

I didn’t want the authentication system to be so brain-dead so I allowed it to be extensible through other applications.

authelia and ft⌗

One thing I like about self-hosted projects is how they can interact with each other similarily to the original unix coreutils. Each service has one specific thing to do and that reduces the security vulnerabilities and allows for even more power than before through combining different services.

authelia, for those who do not know, is an authentication system that hijacks requests from one service, makes the user authenticate, and allows for access control for different routes. You could think of authelia as a middleman that makes sure everybody has access to what they deserve.

With this mind, you could combine authelia with ft to allow for sophisicated operations. For example, creating an operation could be through a third-party app but deleting an operation could only be allowed through authelia with two factor authentication, perhaps only by a select amount of users.

The possibilities are endless when it comes to authelia and ft.

conclusion⌗

Whilst authentication systems serve a great role in securing services, I found implementing a simple one for ft to be the more rational decision in-order to avoid scope creep, security vulnerabilities and other issues. ft’s authentication system can allow for sophisicated authorization and authentication through third party applications such as authelia.