Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Sometimes we're stuck to a point where we don't know what to do, and all what we can do is to ask for help.
But sometimes it's the bot coder's fault for having chosen the wrong way since the start. Simple as that.
Do not hard-code your account into the bot, ever!
Because then, if you post your source with your account on it accidentally, there will always be the chance of someone messing with your account.
Even if you changed your password, someone that managed to log in with your account before you changed it, is still able to do what they want with it.
The best way to avoid this, is not to add reminders, not to remove the account data before posting.
The correct way of avoiding future issues with your account while coding, is not to hard-code your account at all.
The System.IO library provides us 2 easy and safe ways to save account details into external files.
Offline
I would like to add that the proper method for this is to use the app.config file. It can be easily accessed through something like ConfigurationSettings.AppSettings["Password"] and its easy enough to not accidentally share the file!
I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.
Offline
But sometimes it's the bot coder's fault for having chosen the wrong way since the start. Simple as that.
This is an excuse to blame AnatolyEE for being a victim.
Offline
Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.
Offline
Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.
Anyone looked into how the EE website saves your login info? Im fairly sure that whatever way they use would be the best (at least best moderately easy) way to do it
HG wrote:But sometimes it's the bot coder's fault for having chosen the wrong way since the start. Simple as that.
This is an excuse to blame AnatolyEE for being a victim.
It was definately AnatolyEEs fault (he should have been more careful), but I definately do feel sorry for him, and think we should do what we can to help him with getting his stuff back
Offline
capasha wrote:Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.Anyone looked into how the EE website saves your login info? Im fairly sure that whatever way they use would be the best (at least best moderately easy) way to do it
Are you talking about this forum or EE.com? If you are talking about how EE.com saves the login data, it's plaintext.
The flash is saving a flash cookie/LSO and if you want anyone's password you can look there. EE.com isn't so much safer.
I can say EE is using PlayerIO. If you login to PlayerIO on a wifi that people can do a MITM, they can read your login details. Because PlayerIO doesn't use a secure connection.
And therefor I don't see a reason to encrypt bot passwords.
Offline
destroyer123 wrote:capasha wrote:Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.Anyone looked into how the EE website saves your login info? Im fairly sure that whatever way they use would be the best (at least best moderately easy) way to do it
Are you talking about this forum or EE.com? If you are talking about how EE.com saves the login data, it's plaintext.
The flash is saving a flash cookie/LSO and if you want anyone's password you can look there. EE.com isn't so much safer.I can say EE is using PlayerIO. If you login to PlayerIO on a wifi that people can do a MITM, they can read your login details. Because PlayerIO doesn't use a secure connection.
And therefor I don't see a reason to encrypt bot passwords.
Oh... Thats quite bad... Especially because PlayerIO is quite a big (or at least was quite a big) thing
I would have thought that there would have been some sort of temporary key which you are given when you log on or something, that can then be used later to log in again
I guess its not as bad as storing them server-side though... unless PlayerIO stores the Usernames / passwords as plaintext too... (hopefully they're better than that though)
I find password safety quite an interesting topic, as there are almost always elegant solutions that can safely store passwords
Offline
HG wrote:But sometimes it's the bot coder's fault for having chosen the wrong way since the start. Simple as that.
This is an excuse to blame AnatolyEE for being a victim.
Nobody is happy about the situation he's in, but he did mess up. We have to learn from his mistake.
Offline
This is an excuse to blame AnatolyEE for being a victim.
This is was what was in my pastebin when I got hacked. Tell me I was asking for it!
Offline
destroyer123 wrote:capasha wrote:Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.Anyone looked into how the EE website saves your login info? Im fairly sure that whatever way they use would be the best (at least best moderately easy) way to do it
Are you talking about this forum or EE.com? If you are talking about how EE.com saves the login data, it's plaintext.
The flash is saving a flash cookie/LSO and if you want anyone's password you can look there. EE.com isn't so much safer.I can say EE is using PlayerIO. If you login to PlayerIO on a wifi that people can do a MITM, they can read your login details. Because PlayerIO doesn't use a secure connection.
And therefor I don't see a reason to encrypt bot passwords.
Wasn't packet sniffing ... uhm .... unethical?
Offline
capasha wrote:destroyer123 wrote:capasha wrote:Can't really say it's safe to store login details in binary either. If someone want to hack anyone, they would do so too.
I had different ways of encryptions for EEditor's account data. But then people would break through that anyway, like I said before.Anyone looked into how the EE website saves your login info? Im fairly sure that whatever way they use would be the best (at least best moderately easy) way to do it
Are you talking about this forum or EE.com? If you are talking about how EE.com saves the login data, it's plaintext.
The flash is saving a flash cookie/LSO and if you want anyone's password you can look there. EE.com isn't so much safer.I can say EE is using PlayerIO. If you login to PlayerIO on a wifi that people can do a MITM, they can read your login details. Because PlayerIO doesn't use a secure connection.
And therefor I don't see a reason to encrypt bot passwords.
Wasn't packet sniffing ... uhm .... unethical?
Wasn't hacking or using accidentally received information in general ... uhm ... unethical?
Offline
Oh... Thats quite bad... Especially because PlayerIO is quite a big (or at least was quite a big) thing
I would have thought that there would have been some sort of temporary key which you are given when you log on or something, that can then be used later to log in again
I guess its not as bad as storing them server-side though... unless PlayerIO stores the Usernames / passwords as plaintext too... (hopefully they're better than that though)
I find password safety quite an interesting topic, as there are almost always elegant solutions that can safely store passwords
Well internally there are temporary and permanent session keys within Player.IO, which has it's own weaknesses and the like attributed towards it.
As for whether they are stored in plain-text within Player.IO, they aren't - however, they were stored in SHA-1 prior to SHA-256. SHA-1, of which, isn't much of an improvement.
I've seen far too many misplaced and naive security concerns like this, which itself requires fairly bold assumptions and/or ludicrous and impractical methods (as is mandating every software to implement local encryption.)
If you have privacy concerns as well as a functional brain, you would already have your software portable in a encrypted container, isolated through sand-boxing. Which sounds difficult, however it really isn't. I'll put out a tutorial sometime, perhaps.
If you are on a shared or corporate network where privacy is moot, you would not only be likely violating their policies, but you'd be incredibly stupid for not tunneling and deserve to be fired for running non-permitted software.
In the event that your local security is so poor that your plain-text credentials stored locally is at risk, honestly, your jumping smiley face game should be the least of your concerns.
*u stinky*
Offline
Well internally there are temporary and permanent session keys within Player.IO, which has it's own weaknesses and the like attributed towards it.
As for whether they are stored in plain-text within Player.IO, they aren't - however, they were stored in SHA-1 prior to SHA-256. SHA-1, of which, isn't much of an improvement.I've seen far too many misplaced and naive security concerns like this, which itself requires fairly bold assumptions and/or ludicrous and impractical methods (as is mandating every software to implement local encryption.)
If you have privacy concerns as well as a functional brain, you would already have your software portable in a encrypted container, isolated through sand-boxing. Which sounds difficult, however it really isn't. I'll put out a tutorial sometime, perhaps.If you are on a shared or corporate network where privacy is moot, you would not only be likely violating their policies, but you'd be incredibly stupid for not tunneling and deserve to be fired for running non-permitted software.
In the event that your local security is so poor that your plain-text credentials stored locally is at risk, honestly, your jumping smiley face game should be the least of your concerns.
Its good to know that your data is stored (at least fairly) securely on the PlayerIO servers, which was my main concern
Im not majorly concerned that the data stored on your local machine is stored as plain text, but would have thought that PlayerIO would have implimented external keys or whatever, failing that, there is not much that the actual EE website could do to improve it, as storing encrypted data in the same place as the key would be basically pointless, and they wouldnt be able to do much else without having access to the PlayerIO servers
Offline
[ Started around 1732708751.0268 - Generated in 0.293 seconds, 13 queries executed - Memory usage: 1.67 MiB (Peak: 1.89 MiB) ]