Post by Shadowcat on Apr 10, 2014 17:47:48 GMT
Proboards have mentioned that Heartbleed does not effect Proboards server's
I would still recommend changing passwords just in case
I would still recommend changing passwords just in case
The risk isn't really to regular users in the way it might make it sound. The bigger risk is to the companies at the other end, and as a result, thats where the bigger potential risk to the users comes in.
The issue allows malicious users to grab a random 64k chunk of data from the ram of a running server process that uses the affected libraries. The big risk here, is that it can allow compromise of the keys used to decrypt that servers SSL traffic (Since the server needs to be aware of its key, in order to use it to communicate with users). Also those web processes would likely have some form of database access keys in memory which could also be retrieved.
With that, they can then either spoof the server itself, or intercept data. Of course, the process of getting in between 2 points for that kind of interception isnt trivial to begin with, much less when combined with getting anything useful from the memory of the server (The ram would also contain program code, system information, logging data etc which has a much higher chance of being returned than the handful of bits containing keys)
Personal data on an affected server would only be vulnerable while it is in memory. In the case of PB for example (we are safe from the issue for the record) that data is only partly loaded during login for user validation and it is only there for a fraction of a second.
Even if we were affected, it would take huge luck to happen to get the right random portion at the exact moment you were logging in before the data is cleared out again.
As I say though, the bigger risk is if a company was vulnerable, and database access was discovered. This could result in all user data on that service being obtained.
Thats not to downplay the severity of the issue, it is a significantly large issue, but the risks directly for a single user (on most types of services at least) is much much lower than the risk to the company, and at that point, transitively the users.
The issue allows malicious users to grab a random 64k chunk of data from the ram of a running server process that uses the affected libraries. The big risk here, is that it can allow compromise of the keys used to decrypt that servers SSL traffic (Since the server needs to be aware of its key, in order to use it to communicate with users). Also those web processes would likely have some form of database access keys in memory which could also be retrieved.
With that, they can then either spoof the server itself, or intercept data. Of course, the process of getting in between 2 points for that kind of interception isnt trivial to begin with, much less when combined with getting anything useful from the memory of the server (The ram would also contain program code, system information, logging data etc which has a much higher chance of being returned than the handful of bits containing keys)
Personal data on an affected server would only be vulnerable while it is in memory. In the case of PB for example (we are safe from the issue for the record) that data is only partly loaded during login for user validation and it is only there for a fraction of a second.
Even if we were affected, it would take huge luck to happen to get the right random portion at the exact moment you were logging in before the data is cleared out again.
As I say though, the bigger risk is if a company was vulnerable, and database access was discovered. This could result in all user data on that service being obtained.
Thats not to downplay the severity of the issue, it is a significantly large issue, but the risks directly for a single user (on most types of services at least) is much much lower than the risk to the company, and at that point, transitively the users.
