The assembly

[neodammer]

I must say im having all kinds of fun working with assembly language. Its super hard but fun because I now have a better understanding of how things are done in the CPU and RAM etc.. I have also noticed that VB.Net programs are very non-secure due to the ASCII code that is plain as the nose on my face :p I was wondering if there was a way to hide it from the ASCII code like make a password in a textbox encrypted or binary? Because doing the simple

 

if password = textbox1.text then

 

msgbox("yea!")

 

else

 

msgbox("try again")

end if

 

this sort of code is too simple to detect any suggestions on hiding the source from assembly/hex ?

[IngisKahn]

"Non-secure due to ASCII code" -- not sure what you mean by that.

The SecureString class is great for dealing with passwords. Obfuscation tools are another option, thou you'll have to spend some dough. Finally, putting up a message box right after password validation is a flashing "Start looking here" sign to crackers.

 

I've been coding and hacking ASM and P-code for years and I can say that while you can make it harder, you can never (untill we all start using secure processors) make code hack-proof.

[Joe Mamma]

__________________

"Who is John Galt?"

An end unto himself!!!

[Joe Mamma]

Imagine the look of suprise of my once prospective, and now current, client when I opened the exe of a competitors app they were using in notepad and did a search on "p a s s w o r d" and got the dbo login credentials to their Security Application database.

 

And then there is the case of another client where I instanced, in Outlook, one of our competitor applications ActiveX data objects they were using and emailed them the connection string with a couple of lines of code.

[neodammer]

ROFL thats why I wont use vb.net for database applications. The username/password is too easy to pull out.

[thenerd]

Imagine the look of suprise of my once prospective' date=' and now current, client when I opened the exe of a competitors app they were using in notepad and did a search on "p a s s w o r d" and got the dbo login credentials to their Security Application database. [/quote']

 

Psst. This is a joke.

[Joe Mamma]

Psst. This is a joke.

no its not! They had the connections string hardcoded in the app with the password!

[mskeel]

The Linux way of holding passwords works pretty well. A non-recoverable MD5'd password is held in a text file that is human readable (/etc/password). In that file is a colon delimated list of users -- username:MD5'd passwrod:home directory:shell preference. There are variants to this for this file format.

 

The use of MD5 (and similiar hash algorithms) is great becuase so long as your password string is sufficiently long and diverse (uppers, lowers, numbers, symbols) it is essentially impossible to crack the password. A specific string will yeild a unique hash that only that string can create. The trick is that if you don't know the original string that created the hash, it is very hard to determine what the string was --you essentially have to do a brute force analysis of passwords for a particular hash algoirthm seeded in a particular way.

 

With current computers and techniques it takes a little over a year to crack an 8 character password with lowers, uppers, and numbers. That is enough to thwart all but the most dedicated attackers and I doubt you are creating an app or have access to anything that someone will be willing to spend a full year trying to break into.

 

So, when a user logs in to your app, they enter a string, the string goes through a hashing algorithm that relies on psuedo-random numbers and primes to create a new string. If the new string matches the one stored, then the user gets access -- If they don't then the original string was not the correct password.

 

The really cool thing is that .Net provides basic MD5 and a few other hashing algorithms in the System.Security.Cryptography namespace. Pretty neat stuff. Still not completely hacker proof, though becuase you can still insert a jmp over the hash checks and get into the rest of the program and I'm sure Microsoft didn't include the strongest MD5 algorithm. (MD5 is actually on it's way out, but newer stronger hashing algorihtms are available)

[IngisKahn]

ROFL thats why I wont use vb.net for database applications. The username/password is too easy to pull out.

 

How is that different from an application written in any language?

[IngisKahn]

I'm sure Microsoft didn't include the strongest MD5 algorithm. (MD5 is actually on it's way out' date=' but newer stronger hashing algorihtms are available)[/quote']

 

AFAIK there is only one MD5 algorithm.

The framework also provides SHA1, SHA256, SHA384, SHA512, and RIPEMD160 algorithms.

[mskeel]

AFAIK there is only one MD5 algorithm.

Right... I meant to say hashing. But it looks like they have all the goods, so never mind. I've only messed with the MD5 stuff but I'm sure it all works the same, yes?

 

Also, can't you change the level of encryption based on the size of the prime numbers you use to create the hash? I don't recall ever seeding a radomizer (random mouse clicks and keyboard hits), so maybe it all uses the same stuff? At least, that sort of stuff you have to do for SSH which I thought uses MD5..?

[neodammer]

How is that different from an application written in any language?

 

 

Im not sure to be honest but I heard rumors that vb was coded in c++ which was coded in asm. This is what ive learned but not sure. I would assume which such a high level language (if this is all true) that it would be simple to extract information. However the more i code asm im finding out that lower level is easier in some cases.

[IngisKahn]

Also' date=' can't you change the level of encryption based on the size of the prime numbers you use to create the hash? I don't recall ever seeding a radomizer (random mouse clicks and keyboard hits), so maybe it all uses the same stuff? At least, that sort of stuff you have to do for SSH which I thought uses MD5..?[/quote']

 

MD5 is just a hash -- a stronger version of CRC32 if you will. You can define any sort of process you'd like to generate an IV or key for your favorite encryption algorithm. IMO, what SSH does is a bit silly.

[IngisKahn]

I would assume which such a high level language (if this is all true) that it would be simple to extract information. However the more i code asm im finding out that lower level is easier in some cases.

 

I think the point is that data is data and when you get down to it, everything runs in asm. The same anti-cracking precautions should be followed no matter what language you program in.

Hide (encode/encrypt) sensitive strings.

Avoid obvious �key accepted/failed� message box popups.

Delay verification of passwords.

Never publish cripple-ware.

 

It�s still fairly easy to crack but you might dissuade the average script kiddies.

[mskeel]

IMO' date=' what SSH does is a bit silly.[/quote']Of course you are entitled to your opinion, but I think the only thing funny about it would be if it didn't work... Randomness is a pretty big deal and having a user create the seed is as good as anything else. At least until I get my quantum desktop which would pretty much make this whole conversation a moot point.

[neodammer]

The only database software ive used in my day is MySQL and PHP. I am not very sure if ASP is the same but you normally make the db connection early in the code which would make it normally easy to obtain for script kiddies. Of course you cant easily view the php code but its not very hard to obtain if you have the write tools. I was curious if .net languages hide the credentials automatically since they are very important or do you have to encrypt them yourself?

[Nerseus]

Passwords embedded anywhere, encrypted or not, for a mid to large sized project is just stupid programming - or stupid engineers.

 

Here's a simple way to keep the password secure:

Limit access to the DB through stored procs. Create a trusted user account that only has access to stored procs. Assign the webserver to use this user account as a trusted connection. The connection string just has "...Trusted_Connection=Yes". No userid, no password. If you put the SQL server on its own domain, you've essentially "hidden" the SQL box and locked it down.

 

Now that's just one architecture that's pretty secure - there are lots of books on the subject. The bottom line is that putting a password on a client machine, encrypted or not, is just a VERY bad idea.

 

If lack of security weren't reason enough, if you embed a password (or even something like a server name) in an executable, you're asking for a maintenance nightmare. If you find that password compromised, you have to send out new EXEs - which is kinda pointless since that's probably where the password was stolen from in the first place.

 

Encryption has it's purposes - but not in the realm of hiding a password. If you put anything on the client box, you have to assume someone is going to be a jerk and decrypt it. As Michael Howard put it "All input is evil". So are users. You'd better think that at least, when you're writing your code.

 

-ner

[neodammer]

I suppose checksum's etc.. and called authorized procs are the way to go at least for small progs that will not cause the end of the world should they be hacked into hehe.

[neodammer]

I couldnt help but wonder if anybody knew a good asm compiler? I herad of Borlands but I dont think they even sell/distribute their asm software anymore. Was tasm "Turbo Assembly" i think.