Using Netbeans 8 on Windows 8;
I have ftp and ssh connections stored in my Netbeans that I lost from my password manager, so I am now trying to extract them from Netbeans but it's harder than I expected.
I exported the stored connections using options > export > Keyring & Passwords, I then obtained a text file called win32.properties that stores the connections, but they are encrypted.
As these exports are meant to import on another computer, I didn't expect the connections to be encrypted. How can the other Netbeans installation decrypt them? Is there a global Netbeans decryption key?
I would like to know if there is a way how I can run the decryption by myself.
Related
I am using a z/OS java jar which requires a keystore and truststore file.
I have FTP'd all of the files to the z/OS Unix directory(Mainframe).
When executing the jar, I receive an "invalid keystore file format" error. When I use the keytool on my local machine on the keystore file, the command is successful. When using the keytool command on the remote (zOS Unix), I am getting the format error. The files are being transmitted in binary format.
Is there a particular way that I should be transmitting the file to MF Unix?
There are three primary way I use to transfer files to z/OS USS depending on whether I want conversion or not (from utf-8 to ibm-1047 for instance).
With conversion:
scp works and will translate the files characters while transferring. Note: this is an IBM behaviour that you do not normally see when transferring from distributed system to distributed system. It's really annoying.
ftp with ascii mode
Without Conversion:
ftp with transfer mode set to binary
sftp
Choose the option that makes the most sense based on the client in your environment.
I currently have File Vault enabled for encryption on my Mac. Is there any need to encrypt a virtual machine that is installed on my Mac? Or does the File Vault cover that?
I am running Mac OS Sierra 10.12 (Host), and using Virtual Box for my VM's. The guest OS is Ubuntu 14.04. If someone got access to my Mac that is protected by File Vault, would they have any way of accessing my Ubuntu VM?
As #manannan mentioned, it is not easy to give you a proper answer to your question given the little context you provided. But I'll give it a try - feel free to edit your question and I'll update the answer.
With File Vault activated on your Mac, every file that is written to the encrypted disk will be encrypted. A virtual machine consists of one or more virtual disks which are stored on the Mac's file system. Hence they are encrypted on your Mac and can't be read by someone who disassembles your Mac and tries to read your hard disk.
If you export the virtual disk file (for a example on a non-encrypted USB flash storage), the virtual machine is no longer encrypted - so for a safe transfer to another user, you have to come up with your own encryption.
Having the virtual machine encrypt the disk "again" would enable you to safely export and transfer your disk image to another user but would also add overhead to using the machine, as the virtualized OS would have to take care of encryption on top of File Vault.
For a customer project which handled very sensitive data we once created a virtual machine inside a TrueCrypt encrypted folder on the Mac. Like that you basically get the same effect as having the virtualized OS encrypted its hard disks - but I think that TrueCrypt is no longer actively maintained and I don't know any alternative product.
Hope this helps.
I have a requirement to perform checksum (for data integrity) for SFTP. I was hoping this could be done during the SFTP file transfer - I realize this could be product dependent (FYI: using CLEO VLTrader), but was wondering if this is customary?
I am also looking for alternative data integrity checking options that are as good (or better) than using a checksum algorithm. Thanks!
With the SFTP, running over an encrypted SSH session, there's negligible chance the file contents could get corrupted while transferring. The SSH itself does data integrity verification.
So unless the contents gets corrupted, when reading the local file or writing the remote file, you can be pretty sure that the file was uploaded correctly, if no error is reported. That implies that a risk of data corruption as about the same as if you were copying the files between two local drives.
If you would not consider it necessary to verify data integrity after copying the files from one local drive to another, then I do not think, you need to verify integrity after an SFTP transfer, and vice versa.
If you want to test explicitly anyway:
While there's the check-file extension to the SFTP protocol to calculate a remote file checksum, it's not widely supported. Particularly it's not supported by the most widespread SFTP server implementation, the OpenSSH. See What SFTP server implementations support check-file extension.
Not many clients/client libraries support it either. You didn't specify, what client/library you are using, so I cannot provide more details.
For details about some implementations, see:
Python Paramiko: How to check if Paramiko successfully uploaded a file to an SFTP server?
.NET WinSCP: Verify checksum of a remote file against a local file over SFTP/FTP protocol
What SFTP server implementations support check-file extension
Other than that, your only option is to download the file back (if uploading) and compare locally.
If you have a shell access to the server, you can of course try to run some shell checksum command (e.g. sha256sum) over a separate shell/SSH connection (or the "exec" channel) and parse the results. But that's not an SFTP solution anymore.
Examples:
Calculate hash of file with Renci SSH.NET in VB.NET
Comparing MD5 of downloaded files against files on an SFTP server in Python
I have developed a software that opens encrypted files. the files are Encrypted with the key generated from a Mixture of Device Hard Disc Serial and Mac ID In the server side.
In Order To prevent that File to be Opened on any other Device, In Client Software I Generate the same key from Device Hard Disc Serial and Mac ID too, and Decrypt the file with that Key.
Is it the correct way to limit unauthorized computers to open the file? If yes, what if someone debugs the assembly code of my software and Understand the generated key?
Is it the correct way to limit unauthorized computers to open the file?
There is no one "correct" way. Your way will work great right up until...
what if someone debugs the assembly code of my software and Understand the generated key?
that happens. Unless you can lock down the hardware so well that no one can disassemble and debug into your executable, someone will always be able to reverse-engineer your scheme, get the key, and open the file.
If I have a truecrypt file on a shared drive, if I mount it by using the shared path does my password data get sent in plain text across the network? Basically my question: is it safe to mount a truecrypt file across a network without copying the file to your local machine first.
Your password data is not sent across the network, because the cryptographic operations takes place on your computer, in the TrueCrypt driver. The password is used to derive a key that is used on your computer to decrypt the encrypted sectors sent across the network.
TrueCrypt FAQ has a section on this. I beleive item 2 is what you want to acheive. Their warning is that someone looking at the encrypted trafic could get some side-channel information, like the amount of data read and written, and the offset in the encrypted file.
Unless you want protection from your government or other well funded attacker, I beleive you should be ok, password wise. You might test what happens when a network failur occurs while writing a large file. It might corrupt the file system you mounted.
What I did:
mounted the TrueCrypt Drive and a TrueCrypt-Container with VeraCrypt (is newer)
created a windows (samba) and mac (afp) share of the drive and container with a password in the share settings (whatever software you use)
Mounting the container prevented it from being overwritten from some one else opening the container directly.