Cloudron Forum

I wanted to share some information acquired from the school of hard knocks...

Background: I found that VaultWarden uses PBKDF2-SHA-256 as its default encryption with 600,000 iterations. One thing I discovered from security experts after being one of the many unlucky LastPass customers (victims of a hacking incident) was an added vulnerability in that everyone had the same number of KDF iterations based on default installation values. While VW's 600,000 is far greater (and better because it requires more calculation resources) than my LastPass default setting, it is unfortunately the same for everyone - unless you change that:)

Suggestions:

• Set a random value > 600,000 for the # of KDF iterations - Account Settings | Security | Keys. Setting a value too high can make VW a bit unresponsive, so increase sensibly based on VW's suggested increments.

• OWASP publishes a recommendation on the # iterations for PBKDF2 encryption . Check periodically to make sure your value is equal to or greater than their recommendation.

• Note: Each user will need to change this setting for their account.

Benefits: A random KDF means a hacker has many more possible combinations to try. With any luck they will move on to an easier target. Staying at or above OWASP recommended iterations makes sense as well.

Hope this helps.

I agree 100% with @igaudette. I do understand that some of the applications voted up on the App Wish List like Zulip (one of the top apps for quite some time) take a lot of resources. And Cloudron seems to support both business and home users. But before increasing my paid Cloudron instances, I am waiting to see some of my business needs met. It's a simple question of "make" vs. "buy". I would much rather "buy" a solidly hosted solution from Cloudron rather than "make" it myself using my company's development resources. But I can't wait forever and have started to investigate Cloudron's competitors to see if they can provide these business solutions. I believe in this platform, the Cloudron team, and our community, but spending time adding apps because they are "easy" seems like a bridge to nowhere. Let's start building to somewhere.

@timconsidine You are so right. The best day for Team Cloudron is one in which there are no updates. I give @girish @nebulon @joseph an enormous amount of credit for the job they do. As someone who rolls out ~ monthly updates to users, every time that happens I pray that me and my team didn't miss something important. But it happens to all of us, despite good processes and best of intentions. But 8.3 will be replaced shortly with 8.3.1 and then 8.4 and then 9.0. And this difficult day will be replaced in everyone's memory by the great things that are yet to come!

@d19dotca Many thanks for sharing this. I'd like to suggest another addition based on one nasty abuse I've seen: unsubscribe links that use http instead of https, hoping that browser security blocks/warnings will cause users not to follow through and unsubscribe. Anyone not using https for anything these days is not worthy of my time:) This puts them where they belong:

# Rule to detect unsubscribe links that do not use HTTPS
body UNSUB_LINK_HTTP /unsubscribe.*http:\/\//i
describe UNSUB_LINK_HTTP Unsubscribe link does not use HTTPS
score UNSUB_LINK_HTTP 10.0

@girish We contributed some code back to Plausible Analytics some time ago to accomplish some things we wanted on our time line rather than theirs. They publish infrequent "official" updates to the self-hosted Docker code in part to minimize the support impact on their small development team. I believe they publish their code (not self-hosted) updates more frequently, which might give visibility to security updates and new features. Their primary source of revenue is from paid accounts that they host on their own infrastructure, so perhaps another reason is to entice customers to use their hosted Plausible solution.

FWIW, we do both, in part to support their efforts. They are solid and I have nothing but good things to say about them as a company, a platform, and as individuals.

@necrevistonnezr Thank you for providing this information. It is really nice to know that although I am not a German taxpayer they are watching my back as well. Much appreciated. @joseph And as usual, Cloudron team is on the ball patching quickly so any exposure is minimized. Well done!

@alex-a-soto Great idea. I'm interested. Let's see if anyone else has a similar interest. In either case, I will reach out as you suggested.

As a relatively new member of the Cloudron community (especially compared to @scooke) I can see both points of view. The current collection of apps is very eclectic, spanning both personal and business. And to a certain extent that reflects the wide range of our community - a strength.

I do not envy @girish and team trying to please all of us. It is both thankless and impossible. But one person's "must have" app is another person's "who cares". The danger is losing members if their needs are not met with the applications they need or want.

Perhaps having a simplified installation process would allow more people to customize their Cloudrons as desired. And yes, despite the warnings that you are on your own, I am sure that support questions will arise. And the spirit of the Cloudron team and the community to help will always prevail. As long as these questions are within reasonable limits, perhaps this will allow the platform to grow more valuable without being overwhelmed. I would suggest that custom-installed apps have its own topic area, especially if the results could be hidden from search engines to prevent prospective members getting the wrong impression about Cloudron's reliability per @scooke 's valid concerns.

Finally, I am personally interested in a business-oriented, custom-app platform where Dockerized applications can be hosted in a well-thought out and architected environment like Cloudron. We are exploring several ideas along these lines, including adding some private applications we have created, others we have paid to license, and some that are open source. And these systems would require incremental Cloudrons - helping to grow the revenue stream. In the end, that's the idea, isn't it...

Agreed. Cloudron is A+:)

@infogulch Looks like you are right. I checked one of my VW backups and searching for the unique KDF iterations revealed that it is in fact stored in the database. So the information I read after the LastPass breach was incorrect suggesting that a random value of similar size provided more protection that just using the default value.

As I recall the default value at that time was 100,000 and OWASP was suggesting a much larger number. In fact some long time users had much smaller KDF iterations, making the hacking effort minimal.

So it looks like OWASP recommendation should be the minimum KDF iterations and to @girish question earlier, perhaps increasing the value based on your own hardware devices in sensible increments.

Thank you @infogulch for correcting my misinformation. But since my random # was higher than 600,000, I'm keeping it:)

@girish It would be really helpful to know on a quarterly basis what apps will be officially packaged in the upcoming quarter and what apps will be deprecated. While votes on the App Wishlist are part of that decision, I'm sure there are other considerations as well. Knowing the team's intent would be helpful in planning our own activities and whether Cloudron can be leveraged to host specific software platforms. I also recognize that bugs, security issues, platform enhancements, etc. can limit the core team's ability to package apps and for that reason, timelines can change. But knowing what is first, second, third on the "intent list" would be a good start.

@girish Thanks for the suggestion. Sounds like I will need to pursue this idea on an app by app basis, rather than signing on as a Cloudron user. If I am successful, I will share the results so that others can benefit as well.

@nebulon @girish I think that user choice would be best with Cloudron recommendation (3 failures in a row) being the default.

I have been playing with packaging Keila. Still needs some more work, though. I am particularly interested in the ability to set sending limits (tied to Paddle plans).

I agree about using an external SMTP relay. In my case, Postmark has been flawless. Because they separate marketing from transactional messages, their deliverability seems better than their competition. I also set up a sub-account (in Postmark jargon, it's called a Server). By doing that, each domain's reputation is isolated. If someone behaves badly, it is easy to delete their server keeping the rest of your infrastructure intact. By adding a "domain-based" Sender Signature with DKIM and Return-Path, any email sender from that domain is permitted. It works really well!

Final solution: Ventoy + Clonezilla + Anker USB Hub = Tested server restore from USB image!

Future solution(s): Terraform (cattle ranching sounds like fun), NetBoot.xyz, Clonezilla with restore images stored on Amazon S3.

Thanks to everyone for helping me solve this one!

@Dont-Worry I am experiencing similar thoughts about the potential for using Cloudron in mission-critical situations. In past years I have preferred "buying" services from larger, known organizations rather than "building" it myself. But I have been disappointed on too many occasions by these companies. The Cloudron team and community is incredible and I think my company's needs might be better served here than in other places. To achieve this goal we must also ask what "we" can do to help the Cloudron team (@girish, @nebulon ) get there. Whether money or time or both, we should be prepared to invest in our future!

@leemuljadi I would use the Cloudron backup. Here is the process I followed successfully:

https://docs.cloudron.io/backups/#move-cloudron-to-another-server

As always, taking a provider snapshot of your old VPS is a good safety measure before starting the migration. But the Cloudron process worked like a charm.

@scooke I totally agree with your points. And I was critical of the lack of business applications. But doing things right (as the Cloudron team always does) is more important than anything else.

Perhaps this is more a process or communication issue. For example, how are new apps chosen for inclusion in the platform? What are the ongoing responsibilities and difficulties of sustaining any particular application?

And lastly, I would be willing to pay more so that the Cloudron team can add resources to accomplish more. That being said, sometimes growing is not the right answer as other things change (and not for the better).

But when you experience a good thing, it is only natural to want more if it, n'est ce pas:)?

There is a meme going around as follows...

"There are two types of companies: those who have already been hacked, and those that don't know it yet". @3246 I laughed when I saw the source of the article you posted. Perhaps you have also seen that CISA itself has been hacked: CISA Hacked - CNN, March 2024. No one is immune. No one is too safe. No one is invincible.

All of your points are valid. I have also seen insurance companies that sell cyberliability policies offer to store a cookie in your browser and bypass 2FA. I have also seen banks do the same. That said, we should do everything we can to strengthen our authentication systems (including Cloudron) and I agree with @necrevistonnezr that balance is the key. A hard to use security mechanism will cause users to scream for a bypass (like the aforementioned cookie fiascos). And lost or forgotten hardware keys will likely require another alternative - reducing the intended level of security.

I have no doubt that Team Cloudron will consider adding more secure authentication mechanisms in the future and I support that effort wholeheartedly. But in the interim, I would encourage others to consider the risk/reward tradeoff offered by Cloudron. Personally, I have not seen a better platform and not found a better community of colleagues to dialogue about issues such as this.