Im making an application in cocoa and wanted to see if some strings in it were easily accessible so I ran OTX on it and sadly all of my code was found. Is there a method I can use to make my code more "secure" or at least encrypt/hide the strings? The reason I want to encrypt the string is it's a password for a server. I don'd need it really secure I just don't want the password to be so easy to find.
Thanks for any help
You should never put a password into an executable.
This is like putting the password on a sticky note next to the monitor. If a malicious hacker has your application they can eventually extract the password regardless of what language or API you use to write it.
For example, if I know that your application connects to a password protected server but the application never ask for a password, then I know you've made the mistake of including the password. To find the password, I need only monitor the operation of the program to see what areas of code are active around the time it connects to the server. This will tell me where to focus the search for the password regardless of how big your application is. Then it is only a matter of time until I track the password down. Encrypting the password does no good because the encryption algorithm must also be in the app and I can unravel that as well.
Remember that there are many people out there who can unravel your code using only the raw machine code. For those people it doesn't matter what language or API you use because they all distill to machine code in the end. Those people are the scary skilled gods of programming and they laugh at mere mortals such as you or I. Unfortunately, some of them are evil.
Did I mention that you should never put a password into an executable? If I didn't, let me repeat that you should never put a password into an executable.
In your particular case, as novice programmer, you have no hope of hiding of the password from someone with even a little bit more experience than yourself. This is yet another good reason why you should never put a password into an executable.
1. Avoid ObjC in secure code.
Because ObjC's class system depends heavily on runtime reflection, the whole interface needs to be included alongside the executable. This allows tools like class-dump to easily recover the source #interface of the binary.
Therefore, the secure code functions should be written as a C function, not an ObjC method.
2. Use strip.
By default the compiler will keep all the private symbols (which allows stack trace to be more readable). You can use strip to delete all these symbols.
3. Obfuscation.
The above steps can only hide the code logic. But if the password is a constant string, it is immediately visible using the strings utility. You may obfuscate this by constructing the password in runtime (e.g. store the password encoded in ROT-13 in the file.)
4. Or just change your design.
No matter how good your protection system is, as the hacker have total control on their machine, given enough time, they always win. It's better to revise your design, like why the password must come with the executable? Or why a global password even needed?
Related
I am in need to build a secure application for Mac. For that I am using a master password that only exists in the head of the creator.
To retrieve it the password first needs to be entered in a secure textfield* it can then be used to encrypt and decrypt files. While the application remains open that master password will be stored in a variable, meaning it exists in memory. Would encrypting this password in memory be overkill?
The reason why I am asking this question is that before the master password can be encrypted for memory it already exists as a variable, meaning it's already open for memory scanning attacks. Is this something I should be worried about?
I read the following on https://www.apple.com/macos/security/:
Runtime protections defend at the core. The technically sophisticated
runtime protections in macOS work at the very core of your Mac to help
keep your system safe. Built right into the processor, the XD (execute
disable) feature creates a strong wall between memory used for data
and memory used for executable instructions. This protects against
malware that attempts to trick the Mac into treating data the same way
it treats a program in order to compromise your system. Address Space
Layout Randomization (ASLR) changes the memory locations where
different parts of an app are stored. This makes it difficult for an
attacker to do harm by finding and reordering parts of an app to make
it do something it wasn’t intended to do. macOS brings ASLR to the
memory used by the kernel at the heart of the operating system, so the
same defenses work at every level in your Mac.
Can I conclude that Mac has already build in protection against memory scanning and hijacking?
(* I am aware this might cause keylogger vulnerability)
In every case, you would first derrive a key from the user password, and use this key to encrypt the files. So instead of holding the password in memory, you can immediately calculate the key with a key-derivation-function, and hold the key in memory. The advantage you get is, that an attacker can only learn the key, which allows to decrypt the files, but not the original password, which can possibly be reused.
Some OS offer a specialized SecureString, which is probably the nearest you can get to what you want, it holds a string encrypted in memory and can remove it from there. I do not know whether OSX provides anything like this.
I doubt that an encrypted key in memory is of much use. If an attacker is capable of analysing the memory, (s)he will probably be able to decrypt the memory as well, the application must be able to decrypt the key after all. But certainly it raises the bar and needs more work to do.
The linked article addresses another problem in my opinion, it prevents to place executable code in memory (as input data) and trick the processor to execute it afterwards.
The existence of tools such as mach_inject and Cycript clearly indicate your program's memory is never safe. In iOS world the security of keychain comes from the fact the key is engraved in a separate hardware chip and it's never copied to application memory. If you're doing the encryption/decryption inside your program by definition it's prone to being hijacked in some form. Key things to consider:
what do you want protect? The data? The encryption method? Both?
having access to your binary program an attacker is likely to reverse engineer it, what are the implications?
Do you need the actual encryption/decryption to happen in your program? If at least one crucial step required for the data to be useful would be moved to a external backend it could be way safer
Supplementing your solution with file system encryption like FileVault or TrueCrypt will always improve security
If I built an application that accessed some of the data from say Gmail, Twitter and Facebook, and I want the user to be able to only have to enter their authentication info once, and it's reset after some days or weeks, what is the best way to do this, dynamically, in Ruby?
I see a lot of people just having a config file of their clients'/users' credentials like so:
gmail_account:
username: myClient
password: myClientsPassword
This seems a) like it's very insecure, and b) it wouldn't work if I wanted to store this kind of information for thousands of users. What is the recommended way to do this?
I would like to be able to build an interface on top of these services, so having to enter credentials every time the user made a transaction isn't feasible.
If you're comforatable with the potential liability when a hacker gets into your database / filesystem, then go for it. And in all fairness, you should also disclose to your users that their passwords will be stored on your system, and let them decide if they want to give your program that level of trust.
But why do this in the first place? Facebook Connect and Twitter & Google using OAuth there's no need for you to store user passwords at all. At some point a user's cookies will expire (or they'll try to access your site from another computer) and they'll have to re-authenticate. You can't prevent re-authentication - instead, you should make it as easy for the end user to handle as possible.
Such services are providing OpenAuth authorization. You are strongly recommended to have a look at it.
Security
I assume your application needs to know the password in plaintext. Then there is no way around storing it in some kind of plain way.
Store in some kind of encoded way eg. Base64, this protects you from knowing password when looking through the database with your eyes, but it does not protect you from anything else.
Ensure that the files are not readable from any other user
Encrypt your harddrive, so nobody can get the passwords from stealing your harddrive. Your computer will require inputung you the password during booting.
Storing
There is nothing wrong with storing much data in your filesystem. For better performance you can do the following
One file for each user, so the filesystem and not ruby needs to search for the data
Make a lot of subdirectorys. Some filessystems performance suffer's if you put to many files into one directory. eg. put the file 'abcd' into 'a/b/c/d'
You could use a database instead of the filesystem
This is the way it works for instance for fetcmailrc which has to be chmod to 600 (readeable and writable only by his owner). And yes, it contains the plain password.
I would strongly suggest you to use OAuth, but if you have to store the passwords (please be absolutely sure that you need to do it) you could use the OpenSSL library to encrypt the passwords. The OpenSSL library is quite poorly documented in Ruby, but as far as I know they are quite similar to the C OpenSSL library. Since I think you should use OAuth, and not storing the passwords I'll let you find the documentation yourself.
However, for the OAuth approach, you want to take a look at the OAuth gem. Google, Twitter (which I recommend you to use the excellent twitter gem for) and facebook (which has two seemingly good alternatives: RFacebook and facebooker)
My google search has led me to here: How to create a virtual file?
In that article, people suggested the author to extract the file to a temp directory and work with it from there.
Actually, what I would like to do, is something similar to what the author was originally asking - create a "virtual" file and assign a "path" to it, such that would be understandable by other applications calling standard windows filesystem API. The purpose of this is to prevent copying and unauthorized use.
A concept of what I would like to do:
In our company, we have developed a program - but it's not a standard EXE application, it has an internal format (let's assume the 'application' format's extension is .MDL) and is executed by runtime environment, so the runtime must be installed on the client machine. This concept is similar to Java (although this is not java; just comparing, so that you can better understand). What I want to do now, is to encrypt this .MDL file and include it as a resource in a regular .exe file. This .exe file would check if it's okey to run (check license conditions, keys, authorization etc...) and then, if authenticated, decrypt and extract the .MDL file, exec the runtime and pass the virtual path of the .MDL file as an argument to the runtime.
For obvious reasons, i don't want to write the decrypted .mdl file somewhere on the disk, because somebody could just start the application, wait for the decrypter to write .MDL to temp, copy it from the temp and distribute it.
So, any idea how to do this?
PS: I've got inspired from EA Games' games... when you run them and look into your process table, you see a regular game's exe, and, after certain time, it spawns a new process with name like ~A003.tmp
You should use boxedapp packer. It must help.
I am not aware of any method to have a virtual file associated with a path without using some kind of driver component; that is hard work.
Why don't you have the runtime do the decryption? Then you don't have to worry about decrypting the file on disk. Or you could create an unnamed inheritable section object to which to decrypt the item and pass the handle value to the runtime as a command line parameter.
Whatever you do, people will still be able to bypass it so it seems like a waste of time to me. Every EA game ever made has been cracked; people will either think your product is useful and worth the money or they won't. I don't think it is worth the time or effort to implement schemes more complicated than a very simple registration key check (just to make it look like you did something).
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.
Is it possible to store passwords on the local system (Windows XP) that can only be accessed by the application itself?
My instinctive answer would be "no". Even if some kind of hashing or encyption is used I would think that as long as the source code is available then the determined seeker could always use this to retrieve the password.
I'm working on a personal open source hobby project in which I would like to give users the option of storing passwords on disk so that they don't need to type them every time they use the software. One example of a password that could be stored would be the one used to authenticate on their network's proxy server.
There are a few related questions here on Stack Overflow and the most appropriate solution sounds like using an operating system service like DPAPI.
Is the basic premise correct that as long as the password is retrievable by the software without any user input, and the source code is open source, that the password will always be retrievable by a (suitably technically and willfully inclined) passer-by?
You could read about the Pidgin developers' take on it here:Plain Text Passwords.
Using the DPAPI in UserData mode will only allow your account on your machine to access the encrypted data.
It generates a master key based off of your login credentials and uses that for the encryption.
If the password is retrievable by the software without any user input, then the password will always be retrievable by a (suitably technically and willfully inclined) passer-by. Open or closed source only affects how much effort is involved.
Absolutely, you can write a program to store passwords securely.
Using AES, you could have your program generate an AES Key, and have that key stored in an operating system protected area. In WinXP, this is the registry, encrypted with DPAPI. Thus the only way to access the key is to have physical access to the machine.
You need to ensure that when you generate your AES key that you do so in a cryptographically secure manner. Just using RAND won't work, nor will generating a random character string.
Open Source has very little to do with security (in my opinion). Given the level of sophistication in tools for reverse engineering source code, even if you had a closed source solution, people determined to snoop at your code could do so.
Your effort is better spent ensuring that you follow best practice guidelines while using the chosen encryption scheme. I would argue that having your code openly looked at by a larger community would actually make your code more secure; vulnerabilities and threats would likely be identified sooner with a larger audience looking through your code.