Any reason not to use filen if I don’t care about the slow upload
Why8337
January 14, 2023, 4:13pm
2
Not really. I’ve been using it for a while and it has been great. The only thing I can think of is, they are still a very new company therefore, they can’t be compared to larger, more established cloud services.
Despite this, they are growing very well (from my view) and they are planning to offer B2B (Business to Business services), this means that there will be more income therefore, increasing the ability for Filen to grow.
Here is an interesting conversation concerning them. You need to decide for yourself if you’re willing to trust them.
privacyguides:main ← DanielProg39:DanielProg39_Filen
opened 08:00PM - 19 Nov 21 UTC
It is a PR for Filen cloud storage. I am an enthusiast, no one is paying me for … this and there is no affiliate links in commit (even though I have one). I just think that it is a great cloud storage as it puts privacy and security first. No other traditional cloud storage put this much attention to it, except ProtonDrive, Sync and MEGA. However, each of them have significant drawbacks compared to Filen. For example, Sync is proprietary and MEGA has a little tangled [Terms](https://mega.io/terms) and [Privacy policy](https://mega.io/privacy) and has some [privacy issues](https://apps.apple.com/us/app/mega/id706857885).
Filen site: https://filen.io/
sec76
January 15, 2023, 4:15pm
4
Filen has Poor implementation of cryptography. Bad security.
Why8337
January 15, 2023, 4:35pm
5
Could you please provide evidence of this?
Another thing to keep in mind, they have said that they are planning to get an audit in the near future. This audit will reveal any security problems (if any).
I think they have fixed it
sec76
January 17, 2023, 3:45am
7
privacyguides:main ← DanielProg39:DanielProg39_Filen
> > This actually has a [discussion](https://github.com/privacyguides/privacygui… des.org/discussions/67). I don't recommend listing it considering the vulnerabilities I found, some of which were severe. They've improved since then, but I still wouldn't trust it to necessarily be vulnerability free. That discussion also points out that Filen is [not](https://github.com/FilenCloudDienste/filen-desktop/blob/master/LICENSE.md#modified-read-only-license) [free and open source](https://opensource.org/licenses/alphabetical).
>
> My my... I wonder what those vulnerabilities were related to?
I've been tempted to write up a blog post considering how many people seem to be promoting Filen. I've been extremely busy though, and I hoped they'd disclose the issues publicly. They never did as far as I'm aware.
In summary, they weren't authenticating ciphertexts when using AES-CBC (an unauthenticated mode), they used an insecure password-based KDF, the way they derived IVs was very weird and may have led to reuse, they weren't doing client-side password hashing properly, and they used an insecure random number generator. Things like lack of authentication and an insecure random number generator are cryptography 101 type things a developer should know about from doing basic reading (e.g. just library documentation, not even touching blog posts, online courses, or books).
I’ve been tempted to write up a blog post considering how many people seem to be promoting Filen. I’ve been extremely busy though, and I hoped they’d disclose the issues publicly. They never did as far as I’m aware.
In summary, they weren’t authenticating ciphertexts when using AES-CBC (an unauthenticated mode), they used an insecure password-based KDF, the way they derived IVs was very weird and may have led to reuse, they weren’t doing client-side password hashing properly, and they used an insecure random number generator. Things like lack of authentication and an insecure random number generator are cryptography 101 type things a developer should know about from doing basic reading (e.g. just library documentation, not even touching blog posts, online courses, or books).
According to this person, assuming he is infact telling the truth, Filen is not transparent about their internal problems with security.
privacyguides:main ← DanielProg39:DanielProg39_Filen
> > > > This actually has a [discussion](https://github.com/privacyguides/privac… yguides.org/discussions/67). I don't recommend listing it considering the vulnerabilities I found, some of which were severe. They've improved since then, but I still wouldn't trust it to necessarily be vulnerability free. That discussion also points out that Filen is [not](https://github.com/FilenCloudDienste/filen-desktop/blob/master/LICENSE.md#modified-read-only-license) [free and open source](https://opensource.org/licenses/alphabetical).
> > >
> > >
> > > My my... I wonder what those vulnerabilities were related to?
> >
> >
> > I've been tempted to write up a blog post considering how many people seem to be promoting Filen. I've been extremely busy though, and I hoped they'd disclose the issues publicly. They never did as far as I'm aware.
> > In summary, they weren't authenticating ciphertexts when using AES-CBC (an unauthenticated mode), they used an insecure password-based KDF, the way they derived IVs was very weird and may have led to reuse, they weren't doing client-side password hashing properly, and they used an insecure random number generator. Things like lack of authentication and an insecure random number generator are cryptography 101 type things a developer should know about from doing basic reading (e.g. just library documentation, not even touching blog posts, online courses, or books).
>
> Holy wackamoly... have they fixed most of that yet?
They should have fixed all of those yes, but that doesn't mean there aren't more things, like I was concerned about the ciphertext chunks potentially being able to be rearranged since they're using random nonces rather than a counter nonce. You're not even really meant to use a random nonce with AES-GCM, but it's ok if each key is unique or you don't encrypt much data. I haven't looked into that though. The app.js file is 7,763 lines long. They told me they were planning on getting an audit, but I don't know how they'd afford that.
I should also mention that they ignored some of my questions when I was reporting the vulnerabilities, they didn't follow my primary algorithm recommendations, they didn't have a whitepaper until I complained, they used a personal GitHub account until I suggested they set up an organisation, they took weeks to fix spelling/grammar mistakes on the website, and they use RSA encryption rather than hybrid encryption, which is no longer recommended.
sec76
January 17, 2023, 3:46am
8
They already had an audit.
Why8337
January 17, 2023, 7:50am
9
They have stated that they are getting another audit in the near future as, the previously audited area has been completely re-written.
privacyguides:main ← DanielProg39:DanielProg39_Filen
> > > > This actually has a [discussion](https://github.com/privacyguides/privac… yguides.org/discussions/67). I don't recommend listing it considering the vulnerabilities I found, some of which were severe. They've improved since then, but I still wouldn't trust it to necessarily be vulnerability free. That discussion also points out that Filen is [not](https://github.com/FilenCloudDienste/filen-desktop/blob/master/LICENSE.md#modified-read-only-license) [free and open source](https://opensource.org/licenses/alphabetical).
> > >
> > >
> > > My my... I wonder what those vulnerabilities were related to?
> >
> >
> > I've been tempted to write up a blog post considering how many people seem to be promoting Filen. I've been extremely busy though, and I hoped they'd disclose the issues publicly. They never did as far as I'm aware.
> > In summary, they weren't authenticating ciphertexts when using AES-CBC (an unauthenticated mode), they used an insecure password-based KDF, the way they derived IVs was very weird and may have led to reuse, they weren't doing client-side password hashing properly, and they used an insecure random number generator. Things like lack of authentication and an insecure random number generator are cryptography 101 type things a developer should know about from doing basic reading (e.g. just library documentation, not even touching blog posts, online courses, or books).
>
> Holy wackamoly... have they fixed most of that yet?
They should have fixed all of those yes, but that doesn't mean there aren't more things, like I was concerned about the ciphertext chunks potentially being able to be rearranged since they're using random nonces rather than a counter nonce. You're not even really meant to use a random nonce with AES-GCM, but it's ok if each key is unique or you don't encrypt much data. I haven't looked into that though. The app.js file is 7,763 lines long. They told me they were planning on getting an audit, but I don't know how they'd afford that.
I should also mention that they ignored some of my questions when I was reporting the vulnerabilities, they didn't follow my primary algorithm recommendations, they didn't have a whitepaper until I complained, they used a personal GitHub account until I suggested they set up an organisation, they took weeks to fix spelling/grammar mistakes on the website, and they use RSA encryption rather than hybrid encryption, which is no longer recommended.
“They should have fixed all of those yes” and its from 2021
sec76
January 18, 2023, 10:54am
11
I would still not trust a new player who have made bad cryptographic decisions and isn’t transparent totally. I would consider it in the future maybe.
Understandable
I would wish I could wait but can’t