I am working in powerbuilder IDE is it good idea to encrypt a value in inifile or encrypt the entire file in order to protect user id and password ?
Encrypting passwords within text files appears to be an acceptable practice in the IT industry. It is also common to find encrypted passwords stored as a column in a database.
I have not heard of encrypting the entire file and the reason it's probably not done is that you'd end up with a file name with unsupported characters for the OS.
I recently rewrote the crypto api example so it should work better.
Related
I have a Pascal Script code in Inno Setup script to get the DBURI from user inputs, and save it to file, so the application can read this string and connect to database.
DBURI :=
'Databaseserver//'+DatabaseUserName+':'+DatabasePassword+'#'+
Host+':'+Port+'/'+DatabaseName+'"';
SaveStringToFile(dbconf, DBURI, True);
It works perfectly. But the problem the string not encrypted, and anyone who browses to the file can get the database password. I want to use an encryption method with a predefined key within Pascal Script code, and write the output value (encrypted string) to the file.
So, I can include the encryption method and key in my application code to decrypt value and start using DBURI string.
So, my question how to use an encryption method (anyone) with a predefined key within Pascal Script code?
I found many articles in Pascal documentations but I didn't know how to use?
Your question is rather broad, so I will answer it broadly too.
Some facts:
In general, there's no really safe way to encrypt data (the DB password), so that they can be used automatically. Even if you use an encryption key. It's not that difficult to retrieve the key from the binaries. Particularly Inno Setup code is easy to disassemble. See Disassembling strings from Inno Setup [Code]. Though as you seem to be willing to accept even plain key-less Base64 encoding, your security needs are probably not that high.
There's no support for encryption in Inno Setup (or its Pascal Script code). You have to use external functions or applications. Though some simple encoding (not encryption), like Base64, can be implemented in Pascal Script code.
What you can do:
If you will be decrypting the data using the same local account as encrypting them (the same user installs and uses the software), use Windows CryptoAPI. This is really secure, as it uses a key that associated with the local account and protected by accounts password. But that limits the use, as mentioned.
See Simple AES encryption using WinAPI.
I didn't try to implement this in Pascal Script, but I believe it should be possible.
I believe you can use CryptoAPI even with a known key (shared between the installer and the application), but I do not know details.
Another way to encrypt data with a known key is by invoking an external application for that. You can use PowerShell and .NET classes for implementing encryption. Or you can add a hidden feature to your own application, that you will call from Inno Setup to encrypt and store the data.
If you are happy with Base64 (or maybe hex) encoding, see:
Encode string to Base64 in Inno Setup (Unicode Version of Inno Setup)
Can anyone explain how this string has likely been encrypted at all?
AES256:29://(Hex://5B18C3AD8CFR4D38)
I've never seen an encryption has like this before in my life. Would it be possible to replicate with PHP? (Providing I can get what salts etc may have been used etc).
This is for a migration of data from one website to another - currently this data is stored in a MSSQL DB but will be used in MySQL if PHP can handle the encryption.
It appears to be part of a 256bit hash with some metadata around it. I'm not familiar with the php libraries for encryption but know that you can create a 256bit sha with php and there should be a toHex() method.
To check a password, encrypt the users entry with sha256 and check its hex value against the one stored. Have you checked to see if its the first 1/4 of a sha? Maybe they just truncate for lack of security?
If I had the guess, the 29 is probably userid, but could be a salt or something.
I'm trying to crack winrar's password using some methods as explained below.
Because rar uses AES-128 encryption, brute-force and dictionary attacks are useless as they would take years.
But, if we convert a password-protected rar file into an SFX archive (I'd prefer to winconsole because GUI takes much memory) that is an EXE format, I'm quite sure that it would be out of protection from winrar's gates.
Even then rar writes the encryption keys to that exe file.
So, if we could use an exe debugger or disassembler, can't we knock out the key that contains the password?
I used w32dasm, olly dbg & pe explorer to modify these exe files.
All I could find are the strings like "Extracting, CRC failed, Encrypted" and some other things. I used several sfx archives as test files (with different passwords) and tried it through disassembly. Those hexadecimal keys are looking quite similar!
So do I need a better disassembler or debugger? OR, someone tell me that if this method is useless and why?
Another question.. Does this following image has any link to winrar encryption? If yes, please explain how.. It would be very helpful.
When you create a password-protected SFX it does not store the password. It asks you for it.
You can't just "convert" password-protected content into not-protected content. If that was possible the encryption scheme would be completely worthless.
I think the problem is that trying to change the file to an SFX does nothing to decrypt the already encrypted content of the file hence it won't work. The data is already encrypted. Unless the data is NOT encrypted, then you would have to undergo the decryption process to get to your data no matter what you did to the file. No?
It is not easier to attack an SFX file versus a RAR file. A RAR archive consists of your compressed and (optionally) encrypted data. An SFX file is, like RAR, a package of compressed and encrypted data, but it also includes a miniature form of WinRAR that can decrypt the packaged data after the user enters the password.
The SFX file needs your password to decrypt your data; when you enter the wrong password, it's not because it tested your password against one embedded in the file. It means that when it tried to decrypt the data with the supplied password, something went wrong. This is all due to the magic of symmetric-key cryptography: the ciphertext (packaged within the RAR/SFX archive) goes through the AES decryption using the password you entered and the result (plaintext) is exported to whatever location you chose.
In conclusion, you'd have the same luck trying to break an SFX file as you would with RAR archive.
With the included zip utility in CentOS5 (zip command): i.e. /usr/bin/zip -P $ZIP_PASS ...
I haven't been able to find any documentation on this. I am trying to find out how secure the password is. Is this encrypted? How is it protected if not with encryption?
Thanks
Ok I found the answer I was looking for.... From http://en.wikipedia.org/wiki/ZIP_%28file_format%29 and http://en.wikipedia.org/wiki/Known-plaintext_attack
Encrypted file archives such as ZIP are prone to this attack.[citation
needed] For example, an attacker with an encrypted ZIP file needs only
(part of) one unencrypted file from the archive which forms the
"known-plaintext".[4][5] Then using some publicly available software
they can quickly calculate the key required to decrypt the entire
archive. To obtain this unencrypted file the attacker could search the
website for a suitable file, find it from another archive they can
open, or manually try to reconstruct a plaintext file armed with the
knowledge of the filename from the encrypted archive.
So... the zip is not completely secure - but with random file names (when implemented well) for the file(s) inside the zip, and immediate deletion of the unencrypted file (which is also non-web-accessible) - this appears to be a POSSIBLE solution...
More resources:
http://linux.101hacks.com/archive-compression/password-protection-for-zip-files/
However, the more I read, AES 256bit encrypted zips by 7zip (once installed on the server) is much, much more secure. It is NOT susceptible to the known plaintext attack, either.
Yes, it is encrypted. Per the manual:
-P password
use password to encrypt zipfile entries (if any). THIS IS INSECURE! Many multi-user operating
systems provide ways for any user to see the current command line of any other user; even on
stand-alone systems there is always the threat of over-the-shoulder peeking. Storing the
plaintext password as part of a command line in an automated script is even worse. Whenever
possible, use the non-echoing, interactive prompt to enter passwords. (And where security is
truly important, use strong encryption such as Pretty Good Privacy instead of the relatively
weak encryption provided by standard zipfile utilities.)
This is just found from running "man zip" on a centOS machine.
As the manual entry notes, for high security it is not good to use the password in the command to zip the file, as others could check the process list and see the password as zipping.
I don't know what kind of encryption this uses, but I looked around some and it doesn't appear to be great. There are some similiar questions on stackoverflow to this. Look into using a different zip library if encryption is truly important, use something that allows AES, such as GPG.
I have a csv file that required to be encrypted. I want to ask that is there any difference between encrypt the content and encrypt the file? Or they are the same? Because our client doesn't clearly specify what they want?
Thanks,
Encryption will always produce binary result, which can be "armored" (base64-encoded and wrapped) then in order to get the text. All implementations conformant to OpenPGP standard handle armored data by decoding it to binary automatically, so it doesn't really matter what mode you specify. One special case is when you plan to paste the result to some other text data (such as text document), then armoring is mandatory.
Usually when they say PGP encryption, they are talking about commercial programs that encrypt a file or files into one gpg file with their public, which they can decrypt with their private key.
The other way is encrypt it yourself line-by-line in code (there are libraries that do that using file streams; very easy).
Your client one way or another has to tell you how that expect to decrypt the data later on, which will tell you how you encrypt in the first place.