Question about security and data encription

[H00G0]

Hello Guys!

I've already posted about my project earlier, since it's coming to it's completion (meaning all the features are implemented and everything works as it should, bugs have been removed as I noticed them so there shouldn't be many of them left).

To give you a gross explanation of what my program does, It's a program that acts sort of like a windows gadget, only it's -- for now (I plan on making a GUI with SDL_2) -- a plain and ugly console. The program does many things, I can elaborate if you're interested, let me know.

One of the features I'm a bit concerned about is one that allows the user to enter credential data to the program, which gets written on a binary file, and can be retrieved by the user, should he wish to see them because he forgot them. It's sort of a mega post-it where you can write all your online accounts and passwords to have a place to find them easily.

Keep in mind, to use this feature, I've implemented a login system to the program, which asks for a username and password. Each credential binary file is attached to a user and can only be read with the user being logged in the program.


My question about security now : How (not) safe is it to have such important information (consider even bank account info) on a file on your computer. Were you to be hacked, and stumble upon this file, is it easy to read the binary file without knowing the size of the data to be read in binary from the file? What precautions would you advise regarding that?

Also would you think this would be a good idea to implement encryption to write such data to a file, and if so, would you care to elaborate on how you would do so. I would preferably not rely on external libraries such as CryptoPP, even If I have to write a complicated encrypt function I'd rather do that for both fun and why the hell not? Also I would like to use a key written somewhere on a file for said encryption/decryption.

Thanks in advance for all insight and advice,

Regards,

Hugo.

[salem c]

I would strongly suggest you use pre-written libraries for encryption.

> and why the hell not?
- The amount of effort gone into securing the implementation of a library will run into many man-years of effort. You're not going to be able to match that.
- If you roll your own standard algorithm, and make a mistake that makes it far less secure than you imagine, it might be very hard for you to tell a "good" random block from a "bad" random block.
- Even if you manage that much, you're likely to have more side-channel attack vectors than a library.

Do NOT try and invent some "secret" algorithm.
https://en.wikipedia.org/wiki/Snake_oil_(cryptography)

[jonnin]

My question about security now : How (not) safe is it to have such important information (consider even bank account info) on a file on your computer.

The phase I use here is not if, but when. If you insist on having important data stored on a computer that has internet access, someday it will probably be compromised.

If I hacked your machine and found some binary file called pwd.bin I could pop that sucker open in a hex editor and see if I found something useful in seconds. Good HE can translate the bytes into a number of ways all at once (its this string, this Unicode string, that double, this int32, that int64, … all shown at once)

I don't put anything on my machine that I don't want to shout from the rooftops. I may be a low tech Neanderthal, but I also have nearly zero traceability (no spy-phone either, did you see the latest on face time, or the one a couple months back where they found 20k commonly used apps with spyware?). But hey, Im extra paranoid.


that said, there is a low hanging fruit thing for hackers. No hacker is going to try too hard to decrypt john q smarty's files when jane moron has it in plain text next door, unless John has been targeted for a reason (hacker knows he knows something worth stealing beyond his credit card or yahoo email password). Even if your encryption is vulnerable, why bother, it would still take some time to crack it.

All that to say, vulnerable encryption, or great encryption, the most common attacks bypass it anyway. They watch your keyboard, wait for you to type in your password, that's a lot easier than trying to dig it out of some file in some folder somewhere with some unknown garble algorithm on it...

[H00G0]

@salem c

Yeah I pretty much figured that out.. How risky would you say it is to leave such critical information on a binary file on your computer? I mean to read it would take 'some' effort, you would have to know what file you're looking for and where to find it, I'm curious.

@jonnin

Right, what you're saying makes sense to me, I feel like either I would completely paranoid as you said or I might feel happy about having something 'save' from non-targeted hacking. To my understanding, as you pointed out as well, if you're targeted, it's not a matter of if but when the hacker gets what he wants...

I guess if I do anything I'd better use a competent encryption library then.

I have several other questions that may sound stupid, but hey:
_can you from an exe file (program created from compiling some c++ code for instance) retrieve the code that compiled it and see how the program operates from the inside?
_can having the cryptographic key on a separate device or some cloud storage make it any harder for cracking an encrypted file?

Thanks for the replies,

Regards,

Hugo.

[jonnin]

some virus programs data mine, seeking specific patterns and keywords.
binary or text, it will see it.
write a binary file with text in it, and that part is readable in notepad. Its the literal text, quite easy.
if its just numbers, they may overlook it. but other programs watch what files you access most frequently...

again, its your risk to take. odds are that random.bin stuffed in the windows system folder containing your credit card number as a flat number (no dashes, no text) is pretty safe, and more safe if you did even something basic like xor it with your SSN. And again, that isn't where they will get you, they will get you when you decrypt it and type your credit card on the keyboard or paste it into a browser...

and if you typed visa:123-456-789 it may find it faster...

[H00G0]

>write a binary file with text in it, and that part is readable in notepad. Its the literal text, quite easy.

Lol that's what worried me, out of curiosity I opened one of the files containing some data written in binary, and all my char arrays were clearly readable in the file...


> and more safe if you did even something basic like xor it with your SSN.

I'm unfamiliar with those two things, would you care to explain what they are or link ressources?

[pSystem]

If your program is not encrypting right now and you do still end up using it for the purposes you described anyway, and if the program is just storing passwords in plain binary format, please at least offset all your bytes by some amount. So your password is at least not immediately recognizable in a hex editor, like 'ђї⌂⌂Ω▲РτšŢţ' rather than 'password123' =)

(Sorry if this was common sense)

And obviously I'm not recommending this as an acceptable solution, but if your program is just storing plain binary, at least make this simple change for now. :)

@jonnin Lol @ "john q smarty" and "jane moron"

[jonnin]

^ is XOR
xor is reversible... if c = a^b, then a can be found by a = c^b. B can be a constant for each byte or a random stream you can predict (like resetting a random number generator to the same seed).

SSN is just an example of a number. Its an americanism identification number so not really a great password, but people use it because they remember it.

This isn't good encryption, but its better than plain text and its only10 or so lines of code. I used this in school to keep my peers out of my code (we had some cheater problems, and being lazy, they didn't have the energy to hack it, so it worked. With enough effort, its breakable.)

[H00G0]

@pSystem

My passwords are hashed and stored on binary files as well, only the usernames are stored on binary file but as char arrays.

>please at least offset all your bytes by some amount.

How would you do that, is it something one can do manually?
Edit: I just read jonnin's explanation for xor, is that what you were referring to?


@jonnin

Thanks for the explanation. I see what you mean, I think that if anything I'll consider using proper tools and not just some simplistic function I make myself :)

[pSystem]

Hi, by offset byte I just meant take your plain char data, for your username or whatever is plain text, and add or subtract some arbitrary value (which only your binary packer program knows!) to every char/byte.

So for example if you are storing a username as "TimDude2044" in the binary file -- which is obviously easily recognizable as valid data if somebody sees that in a hex editor -- but if you were to have offset each char in the username by 41 for example, then the string is, instead: "}Æûm₧ìÄ[Y]]" which is not easily recognizable as anything valid. Super cheesy/lazy modification but it's at least better than plain text =)

Edit: Keep in mind since a char is 0-255, this concealment could be easily discovered/circumvented by just outputting all data in the hex editor, with all of the possible offsets, that is: +0 thru +255. Doing that, eventually they'll find the one where the ascii/text is right (eventually they'd find "TimDude2044" again). So you can do other things on top of the offset, maybe incrementing the offset by another arbitrary value as you iterate through them.

Obviously still crackable too....but it would take more dedication.

[H00G0]

Thanks pSystem, I had never considered doing that, and it's quite interesting actually. I'll try doing that for my usernames.

Actually since I implemented hashing for my passwords, I could even hash the usernames as well, since it doesn't change much and doesn't add much code.

[jonnin]

the xor / random one is much stronger than a fixed offset for the same effort.
its literally (quick C rand here for example)
cin >> numpassword;
srand(numpassword);
for(all the bytes)
data[j] ^= rand(); //each byte garbled by a different value, not a fixed one

and the exact same code reverses it if numpassword is the same.

or you can tweak the constant offset version too:


for(all the bytes)
data[j] ^= offset; offset+=7; //annoying moving offset even if it starts at the same value each time.


or whatever. anything you want to do with 1 more line of code to avoid having a fixed offset. If you used Unicode instead of ascii, it becomes quite entertaining to have to crack.

hashing works too. have fun with it. See if you can hack yourself after you write it.

[H00G0]

Thanks for the examples jonnin, I've just implemented your example for xor to generate my file names, instead of "userData.dat" it looks more like a series of random numbers which is is really.

See if you can hack yourself after you write it.

Wouldn't you need particular skill to attempt cracking something that's hashed or encrypted? I mean, I have no idea of how one would attempt to do it, the only thing I can think of is a sort of bruteforce program to which you feed a string of garble and tries different operations on said string and outputs all attempts?

EDIT: I mean, look at this for instance "~ázûDø´Üp" This is a hashed username and password, how would you go about attempting to crack such thing?

[dhayden]

I mean, look at this for instance "~ázûDø´Üp" This is a hashed username and password, how would you go about attempting to crack such thing?

Skills.

There's a whole industry devoted to cracking encrypted data. Almost any encryption algorithm that an amateur can think up could be broken in the 1920's with pencil and paper in a weekend. You don't have to know what the methods are, just believe that they exist.

Can you from an exe file (program created from compiling some c++ code for instance) retrieve the code that compiled it and see how the program operates from the inside?

You can't retrieve the C++ code, but you can retrieve the machine code. That can be reverse engineered to determine the decryption algorithm. It's also possible to modify the program to crack it. For example, I ... uh ... know a guy ... uh ... who would crack games in the late 80's. Frequently programs did this:

get_key_from_user();
do_all_sorts_of_clever_stuff_with_the_key_to_thwart_hackers()
if (resultingModifiedKey == secretKey) {
    allowGameToRun = true;
}
...
// occasionally recheck resultingModifiedKey 

This ... guy I knew ... would change the machine code so that

if (resultingModifiedKey == secretKey) {
    allowGameToRun = true;
}

became

resultingModifiedKey = secretKey;
allowGameToRun = true;

I he could often do this by modifying a single "compare" instruction to a "move" instruction.

can having the cryptographic key on a separate device or some cloud storage make it any harder for cracking an encrypted file?

It might actually make it easier. Instead of the key being located on a single machine, now it's accessible to the internet. And anyone watching your internet packets flying around can see the key when you transfer it from the server to the local machine.

[H00G0]

Skills.

Right lol, that's what I thought, no way I'm going to attempt cracking even my own code with no background and skills in that area I guess..

You can't retrieve the C++ code, but you can retrieve the machine code. That can be reverse engineered to determine the decryption algorithm.

I see, that's actually clever what you your friend did with those games. I wouldn't have imagined that you could just basically bypass the exe file in itself and change how and what's making it work.

It might actually make it easier. Instead of the key being located on a single machine, now it's accessible to the internet. And anyone watching your internet packets flying around can see the key when you transfer it from the server to the local machine.

Right, Does it make any difference -- security wise -- if the key is on your computer's hard-drive or a usb key? (i mean obviously apart from the program having to go and fetch the key from the usb key when you insert it, instead of having it ready to use on your machine)?


EDIT:

I ... uh ... know a guy ... uh ... who would crack games in the late 80's. [...] This ... guy I knew ... would change the machine code so that [...] I he could often do this by...

Haha this was gold!

[mbozzi]

I ... uh ... know a guy ... uh ... who would crack games in the late 80's.

Say, that guy might get a kick out of this guy:
https://www.youtube.com/playlist?list=PLzLzYGEbdY5nEFQsxzFanSDv_38Hz0w7B

[jonnin]

well, it takes a bit more to crack the unknown. You wrote the darn thing, so you should have a pretty good idea of what its doing. If you can't crack it and you know how it works, its probably going to fall into the too much aggravation for a random hacker unless, again, you have been targeted for some reason OR they have a keylogger that bypasses the trouble and shows them how YOU decrypted it so they can just repeat the process.

in the 90s games were easy to crack. Often you could literally replace the input code with a 0 string terminal and then press enter to bypass the security check. Other times you could cut the call to the security check out of the code, and it just didn't happen anymore (either by jacking a return statement into the checker routine or bypassing the checker routine). I hacked a few, and ironically they were not stolen, it just got very, very old doing the 'find your manual that you lost, its behind your desk where it fell, then go to page 143, paragraph 5, line 13, word 2 and type that in'. I also hacked a few to cheat; wizardry I 'locked' an inventory slot to set the value of anything placed in it to 255 which reloaded rare ammo for me. Around the time games moved to CDs they started getting more serious about it. Early on, you could directly hack dos games with the built in 'debug' program! https://thestarman.pcministry.com/asm/debug/debug.htm

[H00G0]

If you can't crack it and you know how it works, its probably going to fall into the too much aggravation for a random hacker

Well I didn't in fact write the actual hashing function, I followed your advise. All I know about the final format of what I posted : "~ázûDø´Üp" is that it's a size_t number written on a binary file. However I have no idea or skill to read bytes from a file let alone interpret them to get a variable back from them, which I guess would be the first step in cracking said hashing..

[jonnin]

ah, ok. If you didn't write it, skip cracking it. That was just for fun. Whatever you used is likely too complex to unravel as an exercise.

If you want to go down the path, a good hex editor that shows the various options data in a file can be is where to start. But it won't help much here.

[H00G0]

Right, thanks for the info, I'll still look up how to use hex editors. I'm always keen on learning new things, when they sound so interesting.

Are you aware of any tutorial ressource on hex editors and why/how to use them?