[Features] Update App btn & OTP enabled

[ZicPL]

I use shared hosting. The fact that I could run your server app is something amazing. Maintaining the current software version is one of the basics of security. It would be great to be able to do this in an easy way :) If I understand correctly, the current solution is to replace the files manually?

[0xGingi]

If you use docker, you can just setup this container, will auto update for you https://github.com/containrrr/watchtower

[MarkusDeland]

I'm a messy person because I've many of my apps and files in different places 🤪 So far I've only launched apps based on guides. I would like to keep the application up to date faster and easier. Github is new to me, but I'm making progress. I think I'll soon know how to manually update the app, but for now "update button" saves my ass :)

@ZicPL "Auto Update" in the self-hosted version is good idea for newbies like I. In "application health" has version app info and that's fine. Ofc If there was an "update" button in the "app settings" that would be great. I would be grateful if you could edit the topic to include an OTP request -> I wouldn't have to create another issue.

@zigazajc007 Could you give labels to this issue and define a roadmap for these features?

[ZicPL]

@0xGingi I didn't reply but I missed the notification. I've Passky applications in a LAMP stack. LAMP, like Dockers, has its pros and cons - in this particular case I didn't want Docker.

@MarkusDeland Here you go ;)

[zigazajc007]

@0xGingi I didn't reply but I missed the notification. I've Passky applications in a LAMP stack. LAMP, like Dockers, has its pros and cons - in this particular case I didn't want Docker.

@MarkusDeland Here you go ;)

Hello,

The main goal of a Passky server is to use as little code as possible, including only the most important features. Therefore, it only uses four libraries. You should occasionally check if any of these libraries have received security updates and update them using Composer.

Secondly, always keep your PHP version up-to-date. We chose PHP as our programming language to minimize the use of external libraries and rely on PHP's built-in functions. Thus, the security of a Passky server is closely tied to the security of PHP itself.

The project is currently three years old, and I don't recall any security vulnerabilities that required immediate updates. However, I still recommend you occasionally check for new versions and updates.

An "Update App" button would require code capable of replacing PHP files automatically. This could create a significant security vulnerability if exploited by bad actors. Sometimes, it is better not to include such features at all to completely avoid worst-case scenarios.

Enabling the OTP feature through the Admin Panel would require PHP code that can edit the .env file or environment variables. This approach can introduce significant risks if exploited by bad actors. The safest and most secure method would be for users to manually enter the 2FA secret into the .env file. However, this method would make it much harder for users to set up.

While I love making Passky more convenient for users, I still prioritize security over convenience.

[ZicPL]

@zigazajc007 Thanks for Your answer with solid arguments. I absolutely understand the approach of maintaining less code without unnecessary features that increase risk of security. I approve✋ I didn't intend to increase costs.

Every time someone can submit a request for a new feature in this app that will be impossible to maintain by a small number of developers. I didn't want that and I don't think my request is more important than others. I'm really grateful for Passky 😍

It wasn't just convenience that made me create an issue. I often ask myself if I'm paranoid about security, so I understand what You wrote - otherwise you wouldn't allow app in version: Shared Hosting / docker / etc. because most users here don't have a server with a fast connection and keep files in service providers who are a bigger risk (otherwise only You would host a server app). I could argue that requesting an "update version app" button:

• is elementary;
• will allow You to update the application without access to SSH;
• the update is done via a secure channel, i.e. we bypass the administrator's OS, where the new version app files are downloaded from Github. Unauthorized persons may have access to device or OS may have a Virus.
• etc but that isn't point.

You're a security expert (this app confirms that) and the final word is Yours (because maintaining this feature will take Your time). I and I guess other people (topic likes) didn't want to impose on You. Please consider this as a voice of Your users who will be grateful for fulfilling their requests. Thank You for understanding me.

[zigazajc007]

The "Update App" feature is very easy to implement and maintain, so there shouldn't be any issues here.

If you own the server or VPS, I recommend disabling SSH on the external firewall and only enabling it when needed or using SSH keys. Updating your server should be as important as updating PHP or Passky.

There is one strong argument for implementing this feature: if another person has access to the Admin Panel, it would be much safer to have an "Update App" button than to give them access to the server.

You can expect these two features to be implemented in August.

[MarkusDeland]

This is what you wrote (1st)

Enabling the OTP feature through the Admin Panel would require PHP code that can edit the .env file or environment variables. This approach can introduce significant risks if exploited by bad actors. The safest and most secure method would be for users to manually enter the 2FA secret into the .env file. However, this method would make it much harder for users to set up.

and that (2nd)

While I love making Passky more convenient for users, I still prioritize security over convenience.

are inconsistent with each other.

1st or more precisely, "make it much harder for users to set up." you sacrifice security for easy configuration but in 2nd that safety is more important than comfort. 2fa and better TOTP can't be quantified in term safety for me because it's important on my mental well-being. Ofc maybe there are ways to make the process of adding a secret simpler and automated or well described 😃

minimize the use of external libraries and rely on PHP's built-in functions. Thus, the security of a Passky server is closely tied to the security of PHP itself.

I still lack the skills and experience to comment but what you wrote was a big surprise to me. The 1st thing after starting the Passky-Server application (when I was looking for 2fa/totp settings) was the lack of an update button.

You can expect these two features to be implemented in August.

Cool thanks. It was a very thoughtful discussion. Through the use of these arguments, I came to understand how seemingly simple things can be dangerous.

[zigazajc007]

To clarify the difference between application security and user security because they are both super important but quite distinct.

Application Security:

• This is something developers have full control over.
• Application security should always be a top priority, especially when adding new features.
• Responsibility falls on developers.

In our example this would be how we decide to implement 2FA in Admin Panel. The most secure way would be for users to manually insert 2FA secret to .env file or set it as environment variable.

Another option that we discussed is to have it similar as in Passky applications. Easiest way to enable it (on Admin Panel), but it would require the code to edit .env file or environment variables (potentially increases risk).

Setting 2FA on Admin Panel would most likely be a one time process when deploying Passky Server. If we go with the first option (my recommendation), we could also add an option to enable or disable 2FA in installation script.

User Security:

• This is something developers can not fully control.
• Developers could only recommend users to use long passwords (enforceable), enable 2FA (enforceable), not to share their passwords with others (can't be enforced), keep master password in a secure place [brains] (can't be enforced), not to download suspicious programs (can't be enforced)...
• Responsibility falls on users.

From a security perspective, allowing the application to edit the .env file / environment variables could increase the attack surface for bad actors. If they manage to edit other environment variables like the password and 2FA for Admin Panel, they could potentially bypass both security measures entirely.

While 2FA would increase user security, depending on the implementation, it could be worse than not having 2FA at all. In this example, both options are secure and used by many applications, but one is simply more secure than the other.

I'm sorry for any confusion in my previous message. I was specifically talking about application security.

[ZicPL]

I'm sorry for any confusion in my previous message. I was specifically talking about application security.

If any apology is necessary, it should come from me. I understand that my request may have led to a more vigorous exchange of ideas than intended. You're an amazing job. Thanks for the effort! The focus on simplicity and transparency in Your apps is particularly valuable, and I'm sure the security auditing community would agree. Can't wait for August to see the new features in action 🙏 I see now, that the installer.sh file plays a crucial role in the server app after installation process. Unfortunately, I wasn't aware of this until after I installed the application incorrectly - I thought this script was needed once at the beginning and I moved many files to one folder because I didn't know the rest would be important:

I think I'll reinstall the application 😢 Upon installation, it appears that several files remain, such as the "docker" folder. The installer.sh script could potentially remove these during execution, depending on the user's configuration (e.g., LAMP or Docker). Information from these files could be integrated directly into the installer.sh script and README.md for user reference. Additionally, the information could be displayed within the "About Passky" tab after installation (on website). It's worth considering renaming the "src" folder to a more user-friendly name, such as "public_html," to enhance clarity for non-devs.

(...) we could also add an option to enable or disable 2FA in installation script.

Could You describe what the role of the "installer.sh" file will be? Maybe it would be better to create another new file like reconfigure.sh?