TLDR: In its current state, Foxverse has critical security vulnerabilities that could lead to password breaches, which the developer refuses to fix. Additionally, PokeAcer, a user who has previously stolen and sold other people's exploits, and has used services he was an administrator on to read people's personal messages, is an administrator on this new Foxverse project. In short, as it is right now, Foxverse cannot be trusted.
Well, apparently it's that time of the month again, as I have the pleasure of making Yet Another Drama Blogpost(TM). This time, I'm going to detail security vulnerabilities in the new Foxverse service, which, for the uninformed, is a Miiverse replacement developed by ninjafox/ctrninja/xkyup/ste (did I miss any of his old usernames?). Additionally, PokeAcer is back and working on this Foxverse project. I'll explain why I think that's bad news for the project, and why as long as PokeAcer is working on it, I won't trust it at all.
To start with, I'll discuss the potential security vulnerabilities. Unlike last time, where the screenshot dump was at the end of the post, I'm going to put these screenshots at the beginning, so you can have some context going into what is a somewhat technical explanation: https://imgur.com/a/fVYsK
Password validation security is hard to get right - there's a lot of moving parts, and a lot of the security methods are difficult to understand. However, it's the most important part of any web service, as an exploit and password leak in your service could lead to users' passwords being leaked for multiple sites, including potentially harmful things like bank accounts. For this reason, no matter what service you're implementing, if it deals with passwords, it has to be secure.
Unfortunately, Foxverse isn't secure in its current implementation. There are two main issues:
First, client-side hashing. Client side hashing, in and of itself, is not a bad thing. In fact, it's probably a good idea to do some amount of client side hashing, especially using a secure key-stretching algorithm such as bcrypt. However, client side hashing is by no means a replacement for server-side hashing. If the password is hashed on the client side and uploaded to a password database and stored in that database, logically, the client-side hash becomes the user's password. In the event of a database breach, an attacker doesn't even need to crack the hash - all they have to do is upload said hash, and they can instantly get into any user account. For this reason, client side hashing without any server side hashing is no better than storing passwords in plaintext. That being said, all this would allow an attacker to do is gain access to their Foxverse account - it wouldn't give an attacker the user's actual password. However, it's still a rather large security risk, and one that should be considered and patched. The solution is simple - hash on the server as well as on the client.
Secondly, there's a much bigger issue - the use of HTTP over HTTPS. The use of HTTP means that none of the data sent between the console and the server is encrypted. Any attacker could simply read all of the data in plaintext, and, if they Man In The Middle (MITM) the connection, modify that data. This means two things: first, any attacker can get the password with ease (if it's hashed client side, which Forxverse does right now, only that service will be compromised). The much bigger danger, however, is the danger of an MITM. It's trivial to modify the javascript sent over HTTPS to not include the hashing + salting algorithm. This means that a potential attacker could get the plaintext password of anyone using this service with relative ease. Confronting ninjafox over this vulnerability got me nowhere, and given my belief that this issue is paramount to public security, I've decided to publicly post it.
Now for the layman's explanation: Foxverse does not securely store passwords, leading to two major vulnerabilities. The first is that anyone with a password database dump doesn't need to crack the hashes, but instead can access anyone's account instantly. The second is that an attacker can MITM the connection between the server and the console, perform a trivial modification of the JavaScript served, and get the plaintext password through that route (which could lead to the compromise of other services).
Please note that this is not an attempt to kill the project like ninjafox seems to believe it is. I would be ecstatic to get a proper Miiverse replacement. However, password security is something extremely important and I strongly believe that any such Miiverse replacement needs to have strong security. This is simply an attempt at making sure that this happens.
And now, onto the second part of the post: the return of PokeAcer.
At this point, it's fairly common knowledge that PokeAcer cannot be trusted - see my link at the top of the post. He stole and sold an exploit, begged for forgiveness, and then did the same thing again, and stole and leaked an exploit (ugopwn) ahead of time. However, something I had forgotten about myself was that PokeAcer also stole and read private flipnotes, abusing his position as a Project Kaeru administrator. See my quote from the last post:
In short, I cannot, and don't believe anyone should, trust Foxverse, both due to the security issues, and the personnel involved.
Well, apparently it's that time of the month again, as I have the pleasure of making Yet Another Drama Blogpost(TM). This time, I'm going to detail security vulnerabilities in the new Foxverse service, which, for the uninformed, is a Miiverse replacement developed by ninjafox/ctrninja/xkyup/ste (did I miss any of his old usernames?). Additionally, PokeAcer is back and working on this Foxverse project. I'll explain why I think that's bad news for the project, and why as long as PokeAcer is working on it, I won't trust it at all.
To start with, I'll discuss the potential security vulnerabilities. Unlike last time, where the screenshot dump was at the end of the post, I'm going to put these screenshots at the beginning, so you can have some context going into what is a somewhat technical explanation: https://imgur.com/a/fVYsK
Password validation security is hard to get right - there's a lot of moving parts, and a lot of the security methods are difficult to understand. However, it's the most important part of any web service, as an exploit and password leak in your service could lead to users' passwords being leaked for multiple sites, including potentially harmful things like bank accounts. For this reason, no matter what service you're implementing, if it deals with passwords, it has to be secure.
Unfortunately, Foxverse isn't secure in its current implementation. There are two main issues:
- Client-side hashing
- Use of HTTP over HTTPS
First, client-side hashing. Client side hashing, in and of itself, is not a bad thing. In fact, it's probably a good idea to do some amount of client side hashing, especially using a secure key-stretching algorithm such as bcrypt. However, client side hashing is by no means a replacement for server-side hashing. If the password is hashed on the client side and uploaded to a password database and stored in that database, logically, the client-side hash becomes the user's password. In the event of a database breach, an attacker doesn't even need to crack the hash - all they have to do is upload said hash, and they can instantly get into any user account. For this reason, client side hashing without any server side hashing is no better than storing passwords in plaintext. That being said, all this would allow an attacker to do is gain access to their Foxverse account - it wouldn't give an attacker the user's actual password. However, it's still a rather large security risk, and one that should be considered and patched. The solution is simple - hash on the server as well as on the client.
Secondly, there's a much bigger issue - the use of HTTP over HTTPS. The use of HTTP means that none of the data sent between the console and the server is encrypted. Any attacker could simply read all of the data in plaintext, and, if they Man In The Middle (MITM) the connection, modify that data. This means two things: first, any attacker can get the password with ease (if it's hashed client side, which Forxverse does right now, only that service will be compromised). The much bigger danger, however, is the danger of an MITM. It's trivial to modify the javascript sent over HTTPS to not include the hashing + salting algorithm. This means that a potential attacker could get the plaintext password of anyone using this service with relative ease. Confronting ninjafox over this vulnerability got me nowhere, and given my belief that this issue is paramount to public security, I've decided to publicly post it.
Now for the layman's explanation: Foxverse does not securely store passwords, leading to two major vulnerabilities. The first is that anyone with a password database dump doesn't need to crack the hashes, but instead can access anyone's account instantly. The second is that an attacker can MITM the connection between the server and the console, perform a trivial modification of the JavaScript served, and get the plaintext password through that route (which could lead to the compromise of other services).
Please note that this is not an attempt to kill the project like ninjafox seems to believe it is. I would be ecstatic to get a proper Miiverse replacement. However, password security is something extremely important and I strongly believe that any such Miiverse replacement needs to have strong security. This is simply an attempt at making sure that this happens.
And now, onto the second part of the post: the return of PokeAcer.
At this point, it's fairly common knowledge that PokeAcer cannot be trusted - see my link at the top of the post. He stole and sold an exploit, begged for forgiveness, and then did the same thing again, and stole and leaked an exploit (ugopwn) ahead of time. However, something I had forgotten about myself was that PokeAcer also stole and read private flipnotes, abusing his position as a Project Kaeru administrator. See my quote from the last post:
Although I glossed over it last time, I believe it's extremely relevant to consider now. As long as someone who has a history of stealing private messages is involved in a service like this, I cannot trust any data that is on said service. And yes, PokeAcer is involved as a developer in this.
In short, I cannot, and don't believe anyone should, trust Foxverse, both due to the security issues, and the personnel involved.
)
