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.
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)
I edited this question to clarify why I asked this question again (I had weak Google-Fu and found these rather old 1 2 3 pretty-much-duplicates only after posting).
Approaches to accessing a password-protected resources that I've seen in the wild.
Plaintext storage in script (might often end up being shared, or in a Dropbox)
Plaintext storage in a config script
You can do password = readline("Password: ") but of course the password ends up in plaintext in the console (and thus in console logs etc.), so might as well store it in a plaintext config file.
I found this little trick to avoid displaying the password in the Terminal, but running system("stty -echo") on OS X Mavericks leads to the error stty: stdin isn't a terminal, so I guess it wouldn't be particularly portable.
Using tcltk. Has the unfortunate effect of making Rstudio crash and being difficult to install.
keychain. It's not on CRAN, so I don't think I can use this as a first-line approach, I'd also like a bit more detail about where and how passwords are stored on various systems (i.e. will it end up in plaintext on Windows?).
Access tokens, OAuth etc. seem to have similar problems.
I don't know any R packages which use PGP for connections? Probably also a bit difficult for newbie users.
I'm not asking for myself mainly, but I want to provide somewhat sensible defaults for nontechnical users who might store plaintext passwords enabling access to sensitive data in their Dropbox.
Unlike others who asked similar questions, I could also change the server-side of things if I had a better approach.
Are there best-practice approaches that I'm currently missing? My focus on interactive sessions is because I assume that's how most nontechnical types use R, but of course it would be nice if it worked during e.g. knitr report generation too.
Some suggestions to solve your problem securely. These solutions match all programming languages.
Establish a secure connection to your resource without R, like a SSL tunnel.
If you need a secure password in R to establish a secure connection, then you can read this from a secure config file and remove this password variable if you don't use the password anymore. A secure config file is a config file that is not part of your code repository (Git, SVN, ...). You have to manage your secret independent of your code. This mean separate your code and your secrets. One simple way is to put your private and secure secret in your private and secure user home directory. Then you have delegated your security problem to your operating system. Your secret is now save as your OS and your home directory. Pleas check the rights of your home directory and enable the file system encryption if they are off. Notice, this is the way like Maven handle passwords.
You get more security if you encrypt your password/secret config file. Then you have second line of defense.
For most applications is point 2 enough.
Notice, be sure that your secret is not deployed with your code. You need a second way to manage and deploy your secret to production systems.
Notice, be sure that if your programs jams, that your secret is not in memory anymore.
Notice, use always strong algorithms for encryption. Don't implement your own security algorithm, is a high complexity task. Better use standard implementations of strong encryption algorithms.
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.
I have a VBS script I use at work for automating tasks when connected to Cisco routers and switches, including automating the login process. Not unreasonably people are a little edgy about storing their password in a plain text VBS file, so I provide them with the option to prompt every time for the password or have it stored in the script.
Is there a method by which I could call out to a Windows API which might be able to handle encryption for me? I would need a way to both a) encrypt the original password so it could be safely stored in the script, and b) provide a way of calling the decrypt function for use within my main script so that I can use the plain password. There is no built in function for encryption/decryption in VBS that I can find.
I realise that anyone with access to the script to read the password could also easily add a "WScript.Echo Decrypt(strEncryptedPassword)" type line to the script, but this doesn't seem to worry anyone!
Any help would be appreciated. I'm not great with API programming (in truth I'm a poor VB6 programmer turned network engineer) so please bear this in mind with responses.
Check this article
Also consider the following links:
Encrypt function
Decrypt function
If your are interested in stronger encryption, then check this article
Say you have a bunch of files.
Say you can store meta data to these files.
Say, one of these meta attributes were called "encryption"
Say everyone was allowed to look at these files, but since they are encrypted, only people who know how to decrypt them can actually read the contents.
Say, for every given value of "encryption", a group of people share the knowledge on how to decrypt files marked with that value.
Say you want to be able to do this programmatically, in an OS agnostic way (if possible)
What are the values you would use for "encryption"?
How would you store the keys?
How would you organize access to the keys?
I am currently leaning towards following implementation:
the value of the field "encryption" contains the name of a key, possibly also denoting the algorithm used
each user has access to a bunch of keys. This could be defined by roles the user has in an LDAP/ActiveDirectory like structure, or they could just be files in a secure directory in the users profile/home directory.
on viewing a file, the viewer (I'm trying to build a document management system) checks the users keys and decrypts the file if a matching key was found.
What encryption would you use? Symmetric (AES)? Or Asymmetric (what are the good ones)?
Using asymmetric keys would have the additional benefit of making a difference between reading a file and writing a file: Access to the private key is necessary for writing the file, access to the public key (only semi public, as only certain roles have access to it) would allow reading the file. Am I totally mistaken here?
What are common systems to solve these problems used in small to medium sized businesses?
EDIT: It seems there are no universal sollutions. So, I will state the problem I am trying to solve a little more clearly:
Imagine a Document Management System that operates in a distributed fashion: Each document is copied to various nodes in a (company controlled, private) P2P network. An algorithm for assuring redundancy of documents is used to ensure backups of all documents (including revisions). This system works as a service / daemon in the background and shovels documents to and fro.
This means, that users will end up with documents probably not meant for them to see on their local workstation (a company controlled PC or a laptop or something - the setting is such that a SME IT guy sets this all up and controls who is part of the P2P network).
This rules out directory access based schemes, as the user will probably be able to get to the data. Am I mistaken here? Could a local folder be encrypted such that it can only be accessed by a Domain user? How secure is that?
I am aware of users sharing decrypted versions of files - and that that is hard to suppress technically. This is not a problem I am trying to solve.
The encryption isn't the hard part, here. Understanding the business needs, and especially, what threats you're trying to protect against, is the hard part. Key management isn't a trivial thing.
I highly recommend the book "Applied Cryptography" to help you understand the protocol-level issues better.
This is a hard problem. If this is something really serious, you should not use the advice of amateur cryptographers on the internet.
That said, here's my musings:
I'd encrypt each file with a random symmetric key using AES. This encryption would be on a job that runs overnight, so the key changes overnight.
I'd encrypt the key of each file with the public key of everyone who has access to the file.
If someone loses access to files, they'd be unable to read the new copies the next day (they could still have copies locally of old versions).
I'd use gpg (runs on nearly all OS-es happily).
You misunderstand asymmetric crypto. Public key is given to everyone, Private key you keep yourself. If Alice encrypts something with Bob's Public key, only Bob can decrypt it. If Bob encrypts something with his Private key - everyone can decrypt it, and everyone knows it came from Bob cause only he has his Private Key.
EDIT: However, if you ignored everything I said and went a different route, and gave every FILE it's own pub/priv keypair... then you would rely on the public key be available ONLY to those you want to read the file, and the private key available to those you want to r/w. But that's a bit trickier, and relies heavily on people not being able to distribute keys. Overnight jobs to change keys could mitigate that problem, but then you have the problem of distributing new keys to users.
If I understand you correctly, you could use GNU Privacy Guard. It's cross-platform and open source. Basically, every user has a copy of GPG and a local "keychain" with their "private keys" and "public keys". When you want to encrypt something, you use the person's public key, and the results can only be decrypted with their associated private key. A user can have more than one keypair, so you could give all administrators access to the "administrator role" private key, and each hold of they private key could decrypt documents encrypted with the "administrator role" public key.
The cool part is that you can encrypt a file with multiple public keys, and any one of the corresponding private keys could then be used to decrypt it.
The difficulty of this problem is why many businesses default to using OS-specific solutions, such as Active Directory.
For OS-agnostic, you have to re-create a lot of user-management stuff that the specific OS and/or Network vendors have already built.
But it can be done. For the encryption itself - go with AviewAnew's answer.
I have to agree with Mark here:
Understanding the business needs, and especially, what threats you're trying to protect against, is the hard part
For example; are you worried that unauthorized users may gain access to sensitive files? You can use file-level access control on virtually any operating system to restrict users or groups from accessing files/directories.
Are you worried that authorized users may copy the files locally and then lose their laptop? There are a number of os-level encryption facilities that provide varying degrees of protection. I personally recommend TrueCrypt for thumb drives and other portable media, and Windows Vista now include BitLocker which provides a different level of protection.
Another variation of the lost-laptop theme is the lost-backup theme, and many backup vendors now include encryption schemes for your tape backups for just this reason.
Finally, if you're worried that authorized users may share the files with unauthorized users then you may be trying to solve the wrong problem. Authorized users who can decrypt these files can just as easily share a new unencrypted version of the same document.
What you need is public-key encryption using either OpenPGP or X.509 certificates. In both cases you can encrypt the single block of data for multiple "recipients" using their OpenPGP keys or X.509 certificates respectively. In X.509 the standards for encrypting the data this way are PKCS#7 and CMS (defined in some RFC, I forgot the number). You would need to employ some key revocation checking in order to prevent access for those people, who were given access before but don't have it now.