SRL Archive - MSI Suggestions

Well it does save a file into my Simba folder, off the settings and also my user name and password just how they are typed, without any encryption, quite un-safe. Don't get me wrong, but I want to make sure my account(s) are safe at ANY time.

[Main]
Running=True
Changed=False
Name=MSI Pheonix

[Players]
HowMany=1
Integers=4
Strings=0
Booleans=1

[Integers]
0=Total Loads
1=Break Loads
2=Total Time
3=Break Time

[Booleans]
0=Member

[Strings]
(0)HowMany=0

[0]
User=ThisIsWhat
Pass=IMean
Integer0=0
Integer1=0
Integer2=0
Integer3=0
Boolean0=False
Active=True

It can be obfuscated, but deobfuscated just as easily. If you want to store passwords, then you have to take a security hit..

As long as you have the firewall extension enabled on simba, ANY scripts that access your files/internet/etc must have your permission before they do so.

So I doubt any scripts will search for your MSI folder and that file to take your accounts.


Also since all script are open source and stuff it's pretty impossible for (at least a well used one) to get away with something like that.

But yeah I agree, would be nice if we had some kind of encryption or something on those, but as long as MSI has been around nothing like that has ever happened.

@Markus, would it REALLY be that hard for someone to deob it? Is there no really good safe secure way to encrypt them?

From: YoHoJo
As long as you have the firewall extension enabled on simba, ANY scripts that access your files/internet/etc must have your permission before they do so.

So I doubt any scripts will search for your MSI folder and that file to take your accounts.


Also since all script are open source and stuff it's pretty impossible for (at least a well used one) to get away with something like that.

But yeah I agree, would be nice if we had some kind of encryption or something on those, but as long as MSI has been around nothing like that has ever happened.

@Markus, would it REALLY be that hard for someone to deob it? Is there no really good safe secure way to encrypt them?

I know MSI wouldn't harm, but like lets says a friend of me is at my home and I'm away and he takes a look there… :duh:

I know, pretty much the stupidiest example, but this maybe is also when you got RAT'd that your account(s) are more save, besides they Keylog you… You get the point.

And maybe whenever Simba/SMART/MSI whatever is related to Simba, in every single Script possible Keystroke encryption if using Simba, so lets say Simba writes down "Hello there" for a Keylogger it will come out like this (Simba script used) "JD@#*@$$".

http://developer.pidgin.im/wiki/PlainTextPasswords

I think that's a relevant post.

From: i luffs yeww
http://developer.pidgin.im/wiki/PlainTextPasswords

I think that's a relevant post.

Yes, I said what I wanted to say gaved my suggestion hopefully it's possible to do something like that, it will highly increase the security.

I added this to my MSI fork: https://github.com/Zyt3x/MSI/commit/d1953975a669c228bc6a8c5e0fea0bd81761ba31

I just need NCDS to commit this to the main MSI repo now

From: Zyt3x
I added this to my MSI fork: https://github.com/Zyt3x/MSI/commit/d1953975a669c228bc6a8c5e0fea0bd81761ba31

I just need NCDS to commit this to the main MSI repo now

Thanks for taking my suggestion, means a lot that you wanna do something like that, me and others that like security are thankfull for sure! :)

From: Failure
Thanks for taking my suggestion, means a lot that you wanna do something like that, me and others that like security are thankfull for sure! :)

Note that this isn't really encryption or security towards other scripts stealing passwords or w/e, but humans wont be able to read your passwords by simply looking at your .ini file any more.

From: Zyt3x
Note that this isn't really encryption or security towards other scripts stealing passwords or w/e, but humans wont be able to read your passwords by simply looking at your .ini file any more.

It's a start, and better then nothing if you wouldn't do it, it will remain readable.

From: Failure
Yes, I said what I wanted to say gaved my suggestion hopefully it's possible to do something like that, it will highly increase the security.

:x Did you actually read the post? Because it doesn't agree with you, which is why I posted it.

I think, if anything, adding a stupid Base64Encode() is bad for security. For one, it's not anymore secure at all, since Base64 is very simple encryption and is really more for funsies than anything. It may give users (like OP) a false sense of security, which I think is a bad thing to do.

I'd rather things be stored in plain text. RSBuddy stored some information in base64, and I'm sure people thought they were relatively safe because it was 'encrypted.' I don't see any reason to add 'security' features like encryption.

From: Zyt3x
I added this to my MSI fork: https://github.com/Zyt3x/MSI/commit/d1953975a669c228bc6a8c5e0fea0bd81761ba31

I just need NCDS to commit this to the main MSI repo now

Send a pull request. I'm going to bug Wizzup about adding you and Camo to the repo. again.

From: i luffs yeww
:x Did you actually read the post? Because it doesn't agree with you, which is why I posted it.

I think, if anything, adding a stupid Base64Encode() is bad for security. For one, it's not anymore secure at all, since Base64 is very simple encryption and is really more for funsies than anything. It may give users (like OP) a false sense of security, which I think is a bad thing to do.

I'd rather things be stored in plain text. RSBuddy stored some information in base64, and I'm sure people thought they were relatively safe because it was 'encrypted.' I don't see any reason to add 'security' features like encryption.

I've read it, but I guess understood it wrongly I apologize, I know the Encryption of RSBuddy has already been Decrypted in multiple RAT's to get the user his information. And how about a custom Encryption would that does its job if possible?

Unless you can make something better than AES, I don't think a custom encryption method will work. For one, I find it unlikely that you'd get a closed source encryption method to be used around here for MSI, which is necessary if you want a relatively secure encryption method.

But I still don't see much reason to encrypt the passwords in MSI (and potentially in Simba's account manager). I think that at the most there should be an option to not save passwords. I don't see a situation where more than that is necessary.

From: i luffs yeww
Unless you can make something better than AES, I don't think a custom encryption method will work. For one, I find it unlikely that you'd get a closed source encryption method to be used around here for MSI, which is necessary if you want a relatively secure encryption method.

But I still don't see much reason to encrypt the passwords in MSI (and potentially in Simba's account manager). I think that at the most there should be an option to not save passwords. I don't see a situation where more than that is necessary.

I do agree on the open/closed source, though it's for security purposes.
The reason?

Let's say something got keylogged, he never logins legit on Runescape and only let's get his Character automated by the Scripts from here, they do enter his username and password. Thus the person who keylogged him gets his information.

I agree with luffs, adding b64 is a very bad idea. Common people will think it's safe, but people who grab the file with intent to crack into accounts could decode it easily. Although it might deter the common skiddie.

To me that seems silly for a few reasons.

1. If someone gets keylogged (assuming that it's specifically for a runescape character for some reason, rather than for actually useful information like CC number(s) and other things that will help with acquiring currency), I don't think it should be our (our as in MSI, Simba, SRL, whatever, not trying to take credit for other people's work) to deal with that. To me, that's like saying that if your computer crashes, facebook should save you.

2. If someone for some reason really wants your account information, they can get it one way or another. Things need to be typed in plain text, so the decryption method has to be known somewhere (well, not necessarily, but realistically, yes). In the case that the decryption method is private somehow, the keylogger could just get what characters are typed into the applet.

3. The only case where I can see this necessary is if you share a computer with someone you don't particularly trust, and if they're savvy enough to go looking for that information, they can probably use google and figure it out sooner or later. This is where I think not saving passwords is the best security by far (really it always is).

Not trying to be rude, but I think security is a pretty good thing to talk about, and Base64 encryption really doesn't help anything.

From: i luffs yeww
:x Did you actually read the post? Because it doesn't agree with you, which is why I posted it.

I think, if anything, adding a stupid Base64Encode() is bad for security. For one, it's not anymore secure at all, since Base64 is very simple encryption and is really more for funsies than anything. It may give users (like OP) a false sense of security, which I think is a bad thing to do.

I'd rather things be stored in plain text. RSBuddy stored some information in base64, and I'm sure people thought they were relatively safe because it was 'encrypted.' I don't see any reason to add 'security' features like encryption.

I just read it in its entirety, I agree with the author and you.
@OP, if your computer is not secure then you have MUCH bigger problems to concern yourself with than a few runescape accounts!

From: Failure
Let's say something got keylogged, he never logins legit on Runescape and only let's get his Character automated by the Scripts from here, they do enter his username and password. Thus the person who keylogged him gets his information.

If the person is smart enough to key log someone, they're smart enough to know it's a base64 encryption.

That being said, I don't think it makes a difference as to how the script runs, so it's just setup so people using your computer can't few all your account information.

From: Coh3n
If the person is smart enough to key log someone, they're smart enough to know it's a base64 encryption.

That being said, I don't think it makes a difference as to how the script runs, so it's just setup so people using your computer can't few all your account information.

I know you're not the MSI leader anymore, but I might as well ask you; is there an option to not save player information? If not, I think that'd be a good thing to add (I could send a pull request, shouldn't be hard to add).

Seriosuly, all this discussion simply because I made a function to hide the password for humans who come sneaking at your computer?

Use your energy at something worth it's while instead.

From: Zyt3x
Seriosuly, all this discussion simply because I made a function to hide the password for humans who come sneaking at your computer?

Use your energy at something worth it's while instead.

Did you not even bother to read my post? If you have humans sneaking at your PC who are smart enough to find the password login files, then you have bigger issues. And if they are smart enough to do that, they are more than smart enough to decode it. It's a very false sense of security which is very VERY bad. I thank you for trying to make code about his suggestion, we are just saying why it's not desirable.

From: Zyt3x
Seriosuly, all this discussion simply because I made a function to hide the password for humans who come sneaking at your computer?

Use your energy at something worth it's while instead.

From: Harry
Did you not even bother to read my post? If you have humans sneaking at your PC who are smart enough to find the password login files, then you have bigger issues. And if they are smart enough to do that, they are more than smart enough to decode it. It's a very false sense of security which is very VERY bad. I thank you for trying to make code about his suggestion, we are just saying why it's not desirable.

^ that, and because it's not just about this one instance. I know it's slightly off topic, but I don't think it's off topic enough to make a new thread. I think this can be a good source of information for someone to point to when someone asks why we store passwords in plaintext (at least I hope we will continue to do), especially when we have an account manager. I really hope that the account manager doesn't try to boast that things are encrypted and therefore secure or anything of the sort. A quick lesson in security is far more valuable than a Base64Encode(password), in my opinion.

Also, I'm open to better suggestions than just plaintext, but I don't think there's something better than that (other than not storing passwords at all, which I'd like to see be a feature of MSI if it's not already).

The only thing that I would think to do would be to use a Salt.

Ask the user for a Salt, md5() the salt. Add the salt into the password, base64encrypt() it.

program new;

const
  Password_Salt = 'oggityboogity';

 var
   passwd_Hash: String;
function encrypt(s: String): String;
begin
  Result := '';

  if (passwd_Hash = '') then
    exit;

  s := md5(s);

  Result := Base64Encode(passwd_Hash + s);
end;

function checkpass(p, s: string): boolean;
var
  L: Integer;
  t: String;
begin
  Result := False;

  if (passwd_Hash = '') then
    exit;

  t := Base64Decode(s);
  writeLn(t);

  L := Length(passwd_Hash);

  Delete(t, 1, L);
  Result := md5(p) = t;
end;

var
  x: String;

begin
  passwd_Hash := md5(Password_Salt);
  WriteLn('salt hash: ' + passwd_Hash);
  //WriteLn(sha256('asdf'));

  x := 'ima password';
  WriteLn('Password: ' + x);
  x := encrypt(x);
  WriteLn('Encrypted: ' + x);
  WriteLn('Pass correct?: ' + toStr(checkpass('ima password', x)));

end.

No. When a Pidgin user looks at her accounts.xml file, she can tell immediately that it's a sensitive file and should be treated as such. When an application attempts to 'trick' the user into thinking its passwords are secure by obfuscating it in some way, the user assumes it's safe.

It is an absolute fact that people will share their accounts file, with their supposedly safe passwords, even in very public places: typically so that they can conveniently access their settings remotely. Not only can these passwords be trivially decoded, if you plug those settings files into the same client, it will login without even needing to decode it.

Having our passwords in plaintext is more secure than obfuscating them precisely because, when a user is not misled by a false sense of security, he is likely to use the software in a more secure manner.

When people propose inefficient security, it's because they prefer a false sense of security to a false sense of insecurity. File systems, in general, do a very good job of keeping your information private. For most people, there is no insecurity inherent in plain-text passwords. There's only the perception that, because they can read their passwords with ease, that perhaps others can too. Obfuscated passwords are no more secure than plain text; they can be read, about just as easily with the aid of certain programs. It provides a false perception of security.

We're 100% fine with people having false perceptions of how insecurely Pidgin handles your passwords. We are not, however, fine with sacrificing actual security for false security.

Gonna point to that since it's written better than what I could do. It's from the link I posted earlier (http://developer.pidgin.im/wiki/PlainTextPasswords).

I do thanks you all for putting youe honesty in your comments and basing things out, I do agree with the most now though I just thought it could work out, that every single string that gets typed from Simba can get encrypted, yes I know Simba isn't responsable for the fault from others. I gaved my example on that what if someone only uses Simba it could help, and Coh3n, I highly doubt that every yes trust me… Everyone can keylog easily now a days, and get it FUD. No knowledge needed, therefore they do not know how to decrypt. That being said, about use something else then Base64? But yes I do get the points.

@footballjds you can make your cumputer secure and all, but once in a while everyone is getting lack at his own security, AV's do not 100% keep you virus free, nor ever will since crypters make sure there server is undetectable from the AV's.

From: Nava2
The only thing that I would think to do would be to use a Salt.

Ask the user for a Salt, md5() the salt. Add the salt into the password, base64encrypt() it.

program new;

const
  Password_Salt = 'oggityboogity';

 var
   passwd_Hash: String;
function encrypt(s: String): String;
begin
  Result := '';

  if (passwd_Hash = '') then
    exit;

  s := md5(s);

  Result := Base64Encode(passwd_Hash + s);
end;

function checkpass(p, s: string): boolean;
var
  L: Integer;
  t: String;
begin
  Result := False;

  if (passwd_Hash = '') then
    exit;

  t := Base64Decode(s);
  writeLn(t);

  L := Length(passwd_Hash);

  Delete(t, 1, L);
  Result := md5(p) = t;
end;

var
  x: String;

begin
  passwd_Hash := md5(Password_Salt);
  WriteLn('salt hash: ' + passwd_Hash);
  //WriteLn(sha256('asdf'));

  x := 'ima password';
  WriteLn('Password: ' + x);
  x := encrypt(x);
  WriteLn('Encrypted: ' + x);
  WriteLn('Pass correct?: ' + toStr(checkpass('ima password', x)));

end.

If anything, this.

My best advice would be to use a password window with mirror letters like * then save it to a string. but just as you know it don't give any protection against maleware intended to steal your rs pass.

procedure Crypt(var Data: string; Key: string);
var
  KeyL, I, J: LongInt;
begin
  KeyL := Length(Key);
  J := 1;
  for I := Length(Data) downto 1 do
  begin
    Data[I] := Chr(Ord(Data[I]) xor Ord(Key[J]));
    J := (J mod KeyL) + 1;
  end;
end;

If you wanna store this base64 it first.

From: i luffs yeww
I know you're not the MSI leader anymore, but I might as well ask you; is there an option to not save player information? If not, I think that'd be a good thing to add (I could send a pull request, shouldn't be hard to add).

Now that I think about it, no, there isn't. It automatically saves (if you haven't already) when you click Run. Right now, it just calles ShowMessage, but that can easily be changed to MessageDlg (or whatever it is) so there's Yes, No, and Cancel options.

I get what you guys are saying, but I don't understand how it's bad to use base64 (at least for this application), or why it's better to just use plain text. I don't think it matters what you do, keyloggers will know how to counter whatever security methods being used, but if you simply share a computer with a lot of people, and your files are easily accessible, it's human nature to snoop around. The average person will have no clue how to decrypt a base64 encryption. Heck, the average person probably doesn't even know what it is.

From: Coh3n
Now that I think about it, no, there isn't. It automatically saves (if you haven't already) when you click Run. Right now, it just calles ShowMessage, but that can easily be changed to MessageDlg (or whatever it is) so there's Yes, No, and Cancel options.

I get what you guys are saying, but I don't understand how it's bad to use base64 (at least for this application), or why it's better to just use plain text. I don't think it matters what you do, keyloggers will know how to counter whatever security methods being used, but if you simply share a computer with a lot of people, and your files are easily accessible, it's human nature to snoop around. The average person will have no clue how to decrypt a base64 encryption. Heck, the average person probably doesn't even know what it is.

Well I'd like to see that little addition. :) Not that I would use it, but I think it'd be nice to have.

And the reason I (and others) find something better than nothing bad is because it gives people a false sense of security, which could be bad. Like I said, a short introduction to security seems much more valuable than Base64ing their information and them thinking that it's more secure, when really it's not. The only reason I think plaintext is favorable is because it (hopefully) lets them know that it's just their information, and they won't be so open with it (not sure why they would be, but whatever).

From: i luffs yeww
And the reason I (and others) find something better than nothing bad is because it gives people a false sense of security, which could be bad. Like I said, a short introduction to security seems much more valuable than Base64ing their information and them thinking that it's more secure, when really it's not. The only reason I think plaintext is favorable is because it (hopefully) lets them know that it's just their information, and they won't be so open with it (not sure why they would be, but whatever).

Fair enough. I'll let the developers decide, I don't mind either way.

Create a new suggestion thread for the save thing if you don't mind.

Did yall see my crypt?

I could also add real crypting functions. (to simba)

From: Dgby714
I could also add real crypting functions. (to simba)

Probably not a bad idea. ;)

What was wrong with what I posted? Although, using dgby a is a good plan too as mine doesn't really handle the encryption well as the password ha just base64 still.

Key encryption + salt would be ideal.

From: Nava2
What was wrong with what I posted? Although, using dgby a is a good plan too as mine doesn't really handle the encryption well as the password ha just base64 still.

Key encryption + salt would be ideal.

You lost me??…

I still don't think that (Dgby) would be any more secure. It is a bit better than simply Base64Encode()ing it, but there are then two possible options that people have. They could store the salt (think that's the correct term.. 'password'/'keyword' for encryption), and thus that doesn't solve anything (as with the salt, they have the password). Or they could not store it, and type in the keyword every time they use it. In that case, I don't see how that's favorable over just plain text.

Again, if anything it is just as good as plain text or worse, as it will give people a false sense of security.

Am I genius or is SRL drunk? Just ask for a master password, then encrypt all account information with that! MSI will ask for that password every time you'd run it, thus providing real security.
I doubt users mind entering one pass for all of their accounts.

From: Markus
Am I genius or is SRL drunk? Just ask for a master password, then encrypt all account information with that! MSI will ask for that password every time you'd run it, thus providing real security.
I doubt users mind entering one pass for all of their accounts.

What about the users who aren't using the form or are using CRASHSMART? :/

I think we should offer it as an extra option not make people use it, i for one will not want or need it but thats me, so by having it as an extra option would be best i think.

what do you guys/girls think?

From: i luffs yeww
I still don't think that (Dgby) would be any more secure. It is a bit better than simply Base64Encode()ing it, but there are then two possible options that people have. They could store the salt (think that's the correct term.. 'password'/'keyword' for encryption), and thus that doesn't solve anything (as with the salt, they have the password). Or they could not store it, and type in the keyword every time they use it. In that case, I don't see how that's favorable over just plain text.

Again, if anything it is just as good as plain text or worse, as it will give people a false sense of security.

Luffs, Thought this was for people not to be able to get the file and read it.

From: Markus
Am I genius or is SRL drunk? Just ask for a master password, then encrypt all account information with that! MSI will ask for that password every time you'd run it, thus providing real security.
I doubt users mind entering one pass for all of their accounts.

This is exactly the point. :)

@Dgby, I'm just silly. Your method works fine w/o salt. :)

I do think the passphrase should be sha'd or md5'd before being used, though. :)

From: Nava2
This is exactly the point. :)

@Dgby, I'm just silly. Your method works fine w/o salt. :)

I do think the passphrase should be sha'd or md5'd before being used, though. :)

sha'd =)

Then after crypting and before saving, base64 the result as it has quite a few unprintable characters.

NCDS added the option to save/not save here.

You know, that xor encryption is pretty bad as wikipedia explains:

By itself, using a constant repeating key, a simple XOR cipher can trivially be broken using frequency analysis.

You better use something real there, like a simple stream cipher (I posted my RC4 implementation here once, but it still has the same problem as the basic XOR encryption: same key due to the same output by the PRNG, you need to use a nonce there).
To everyone talking about salts: those are for useful for hashing, not so useful for encrypting. There's no need to grab your buzzword list.