store password secure in INI
Has NSIS the possibility to encrypt passwords for storing them into INI files - then to read out the pw and decrypt it?
Archive: store password secure in INI
store password secure in INI
Has NSIS the possibility to encrypt passwords for storing them into INI files - then to read out the pw and decrypt it?
There is no such built in possibility, but if you find a nice command line program that does it you can use it with nsExec. You can also create a plug-in.
not easy - there seems no dos program for that.
i found this one
http://www.di-mgt.com.au/cryptoMySecret.html
my idea is now to put the pw into his own ini and to encrypt it.
for decryption it will decrypted into a temporary ini-file which is read out and then destroyed.
in case i find a program which can en/decrypt with output - how can i fetch this output (like the errorhandler on dos)?
Use nsExec::ExecToStack to get the output and the return value.
There are still a couple problems. 1st, how do you do the encryption to make it effective? User gives you a password and you read it from an inifile in the clear. Next, you take the password send it through the encryption program and out comes the encrypted hash. What method will the encryption program use? If you decide to use a one-way hash like md5 then great. But, if you will need the password in the clear again later, you have to use a two-way algorithm and a key. So either your installer has to know that key or the encryption program has to know the key. You can't rely on the security of the compiled installer to protect the key. Can you rely on the security of whatever other binary you're going to use to do the encryption?
I just re-read your post and it seems you need to go both ways and that you'll have to store the key in the installer (the installer is not a secure place to store a key). If this is important enough that you already considered all of this, I bet this isn't the right solution. Why couldn't you use md5 sums and compare hashes from there after?
The other problem I see with your scheme is that you assume no one can recover inifiles once the installer deletes them. I haven't tested this yet but I'm pretty sure it isn't hard to retrieve these files. Lots and lots of programs can find deleted files (even old swap and virtual memory files... always scary).
the password is not very important till now.
my old program (wich is very functional) offers input to a password which is NOT stored till now.
The newer version should do this (store pw) but i want prevent anyone to use or crack it on first sight.
The pass is used later on a RAR-archiv with 128bit AES encrytion.
password will only be asked on "saving" not on restoring.
I have thought of no schema what so ever. You've asked to encrypt and decrypt and I have merely told you how to do it. Deciding which method to use it up to you. I am on security expert and thus can't really help you in this matter. All I can say is that if I needed something like this I would have surely not used anything that's bidirectional unless the key is to be supplied by the user. But that's exactly the same as one-directional because you merely compare the results of the algorithm and the input of the user.
If you do come up with a working system it would be nice if you can create an Archive page for it.
BTW, to make sure no undelete programs recover your files you can try filling them with bogus data over and over again.
@kichik
>> to make sure no undelete programs recover your files
So this was my purpose in asking for a routine.
i put also a request on my german board if someone know where to get this
<program -e|-d password|plaintext>
Output is put onto the stack i read out with nsexec
i am concious about deleted files and recovery programs (i am using such stuff from time to time).
If the password is only for the purpose of protecting a rar file later... I wouldn't spend that much time on this. Do a ROT13 or something because rar files do crap job of protecting the password anyway. Checkout Elcomsoft. If you just want to say, AES encryption well then that's fine too. Still, if you're keeping the key in the compiled installer which it sounds llike you have to do, these things are reversible. Kichik has given fairly straightforward instructions for it on this forum in the past.
When I'm done with my current project I'll look into writing a function for doing an md5 sum in NSIS or finding a suitable and small DLL and posting the code to use it. In a dream world of mine I'd write PGP support but...
7-zip offers AES-256 encryption.
still i wonder if the archive-method is really important. i gues one could find out the password the second your installer decompresses the encrypted password.
was looking for a way to encrypt a password in an ini-file myself, so i will keep an eye on this thread :)
Storing keys safely- Methods explored
If you want to encrypt stuff in a way that is reversible then you must have a key or keys. Where is the key to be stored?
The installer compression is necessarily reversible and more or less documented. There isn't a tool for it per se (except the compiled installer itself, which works great). This method cannot be relied upon except to keep the kids out.
The external DLL method. If you have an external DLL that is compiled in such a way as to protect the key safely, fine. This of course means the external dll also performs the encryption and the key never leaves it. This would be used as follows: Call DLL encryption function giving it the clear text. The output of the DLL function is the cipher text. Later you would call the same function to do the reverse. Still, this is a target for hackers. While it is doing its thing in memory someone can try and figure out the key. In this case, that is dangerous because assuming you use the same dll in every installer you distribute, one person cracks it and everyone has cracked it.
The Microsoft method. Security through obscurity. In this protected DLL instead of storing a key, make a thousand (exaggeration?) registry calls get system specific information. In some crazy fashion you would take parts of all of this information and make a key out of it. It is still possible for Joe hacker to figure out the key and possibly though if done properly more difficulty the method for obtaining the key. It just makes it take longer to figure out.
Much better security. If you can assume Internet access exists or if you have an offline channel connecting you and the user of your installer you would use asymmetric cryptography. In this method you would have a public key in the installer that encrypts whatever it is you're interested in protecting. Later, when the user needs to decrypt it, they send the cipher text to your web server or whatever and it return the clear text having decrypted it with the private key on the server. Since the private key is never even on the client's system it is as secure as the server it sits on.
Copy protection schemes that don't rely on hardware devices or users getting challenge text encrypted by a server are always broken. Whether you're trying to do copy protection or something else, if you have the secret that is used to protect something stored in the place where the attacker has access, you are going to get your stuff reversed if the attacker has the time and skill to do it.
Remember key size counts but.. it isn't the size of the key so much as it is how you use it. I guess that applies to a lot of things but...
@bSecRes
My program is only for a backup from some existing data which is NOT secure (data is kept in plain text)
In any case data is better kept in a datacontainer like drivecrypt or bestcrypt so each access of a new session must be permitted.
But that is not my purpose - i only want to give the opportunity to backup files 'cause the main program cannot do this. Backup files can be stored everywhere and restored everywhere (incl moving)
I use rar instead ZIP because i use recovery percent for secure archiving and i almost work with winrar instead crappy winzip.
BTW RAR has i big advantage - i can cover the complete content instead getting a file list with asterixes.
But still to mention - password is important for my backup program. but it would be nice to have the opportunity ;)
I wasn't so much discussing your specific problem, as I was addressing the issue of encryption and the NSIS installer in general.
<castle metaphor>
I still don't have a very clear idea about what you're trying to do but it sounds to me like you're building the castle walls at different heights. Castle walls should all be built to the same height with regard to the concern of someone going over them.
</castle metaphor>
If you are creating some code you hope to be reusable and in the future you would like it to work with more secure things than it is working on right now, great. Otherwise, without a plan for fixing the security of the stuff you're backing up, I think you're time might be better spent doing other things.
>> Has NSIS the possibility to encrypt passwords for storing them into INI files - then to read out the pw and decrypt it?
the answer is NO till now so i have to work without it i did the last year
:D
It would be nice if InstallOptions had an encription Flag.
I'm not sure how it would work...
-Stu
My point is that it can't work two-way as long as there is no protected memory. I am writing an md5 hasher now for people that want to use that somewhere in their installer. Obviously that won't work on a custom page before the value gets written to the hard disk which I think is a weakness.
I agree that it would be cool if there was a one-way hash that NSIS could use when storing the value in the file. I would like to see that hash be md5.
The only way to make two-way work is to go asymmetric, whereby we would have to give NSIS a public key to use to encrypt and store the password. Afterwards, though what good is it? If you put the private key on the system game over.
There is already a MD5 hasher plug-in:
http://nsis.sourceforge.net/archive/...=md5plugin.zip
Would there be any reason to rewrite it as a .nsh file or code people can copy and paste? Would it in the end yield smaller installers? Would it in the end be really slow compared to the DLL?
And is there anyway to use it prior to the passwords getting written to the iniFiles? (Not that I could do that either...)
Writing the plug-in in a .nsh (assuming you mean a function that will use System.dll) is absolutely insane. It'll be way slower than the plug-in. Why would it yield smaller installers? If anything, the code will be much more complicated.
You can't get InstallOptions to write it this way without changing InstallOptions. If you want to write it from the script then it's very much possible.
That's what I thought. Well, when I get that C compiler on my NSIS workstation I'll get to work on the InstallOptions thing.