I want to make secure deaddrop. I want everyone to be able to store files that only a person with the password can access. I need to lock individual files & folders, no the entire drive.
You just need to use file-level encryption on the files/folders you want to secure, rather than just encrypting the whole USB drive. You can use any available file encryption utilities to do this. The receipient will then need to know how to unencrypt the files.
I'm not an expert here, but there are free tools available to do this type of encryption. One example: https://www.aescrypt.com/
Related
I would like to secure or at least hide my server credentials from the .ini file generated when creating an executable file from INFOMAKER. I do not think that I can do anything about the coding of the executables generated from the Infomaker.
I am not just comfortable with the credentials lying around in plain text.
Already tried different connection methods including SQL directly, and ODBC connections.
If there is a way that I can hide or get rid of the ini file entirely, that would be great.
So, a common practice these days is to put connection strings & passwords as environment variables to avoid their being placed into a file. This is all fine and dandy, but I'm not sure how to make this work when trying to set up a continuous deployment workflow with some configuration management tool such as Salt/Ansible or Chef/Puppet.
Specifically, I have the following questions in environments using the above mentioned configuration management tools:
Where do you store connection strings/passwords/keys separate from codebases?
Do you keep those items in a code-repo of some type (git, etc.)?
Do you use some structure built-in to your tool?
How do you keep those same items secure?
Do you track changes/back-up these items, and if so, how?
In Chef you can
store passwords or API tokens in either encrypted data bags or using chef-vault. They are then decrypted while chef does the provisioning (with encrypted data bags using a shared secret, with chef-vault using the existing PKI of Chef client).
set environment variables when calling external software using the environment parameter of e.g. the execute resource.
not sure, what to write here -- I'd say you don't really manage them. This way you set the variables only for the command that needs it, not e.g. for the whole chef run.
With puppet, the preferred way is probably to store the secrets in Hiera files, which are just plain YAML files. That means that all secrets are stored on the master, separate from the manifest files.
truecrypt virtual encrypted disks are cross-platform and independent of tooling. Mount it read-write to change the secrets in the files it contains, unmount it and then commit/push the encrypted disk image into version control. Mount read-only for automation.
ansible-vault can be used to encrypt sensitive data files. A CI server like Jenkins however is not the safest place to store access credentials. If you add Hashicorp Vault and Ansible Tower/AWX, then you can provide a secure solution for several teams.
In helping out a friend with a few questions for CS, I came across one that I had no prior experience with and was hoping someone would be able to clarify the difference between NTFS and File Share for me.
To help, the question we faced was:
A folder storing a faculty member’s personal documents are set as a share to which everyone has full access. The only person with NTFS permissions on the folder is said faculty member. Can everyone else access the documents?
I appreciate any clarification you can provide. I'd love your help in learning about this!
Short answer: No.
In Windows each file and directory has an ACL controlling access to it.
Each file share also has an ACL controlling access to the share.
When you access a remote file through a share you are doing so using the credentials used to login to the local computer. (You can connect using different credentials by entering a username/password when connecting).
The remote computer tests the supplied credentials against the ACL on the share.
Once you are past that, then every file you attempt to access on the remote machine through this connection will be checked using your credentials against the ACL on the file and the share. This allows a file share to offer more restricted access to some files than if the same user were attempt to access them locally. (So you could share files as read-only, even if the ACLs on the files themselves would allow that user write access).
If the file share is of a FAT file system then the only ACL checking that is done is against the file share itself because FAT doesn't support ACLs.
When computer are not in a domain and all user accounts are local user accounts then permissions are maybe not what you expect. Unlike Unix/linux, it is generally not possible to create the same user account (uid) on two computers because Windows basically uses a GUID for the UID (a big random number). So when you attempt to look at file owner or ACL information on remote files, since those files are all owned by local accounts on the remote computer, to your local computer those UID will not be recognized (See dir/q from the command line).
Windows can be setup to make non-domain file sharing a little easier. It can be set so that when you attempt to access the remote file share, as long as the remote computer has an account with the same username and password as the local computer, then the connection is allowed -- and you are logged into the remote computer using the remote computer users account.
For reference, see information on NTLM, SMB and NETBIOS.
I have a shared hosting account, is it possible to install LAME onto my account? I also don't have SSH access. I want to convert wav to mp3
You will need to request that the server administrator installs it. Most shared hosting providers are used to these types of requests, and are generally accommodating. However, they may have concerns with you processing large amounts of audio content, and using more than your fair share of system resources.
It's worth asking, at least!
If you don't have direct access to the server, I don't really see a way to do that.
That's more of a question for https://serverfault.com/. The best bet is to simply ask your provider.
But unless there is a policy against that, you could just replicate a lame binary on your webspace (outside of cgi-bin and htdocs root!) and make it executable (chmod +x via ftp). It's self-contained, so you just need to take care of the architecture (usually x86-64 nowadays, but see phpinfo).
Without having access to the server you will not be able to install LAME on the system. Some providers will take into consideration your request and will install LAME it really depends who your hosting provider is.
If this is a service you want to provide, you can always allow anyone to upload a wav file and when you have time you could convert it and send the user a link with the location of their mp3.
I am using dozens of different web services, and I keep a password file in a remote Linux machine. The file contains my usernames, passwords and answers for security question.
This server happens to be offline to often, and I'm looking for a way to keep the password file on my own computer, or on a service like DropBox. Obviously, I want to keep the file encrypted, but handy - I want to be able to print its contents using one shell (or cygwin) command, perhaps using a passphrase.
Any good ideas how to do it?
You can use GPG's symmetric option to encrypt files with pass-phrases.
gpg --symmetric filename
That will result in an encrypted file named filename.gpg. To redirect the output to STDOUT instead of a .gpg file:
gpg --symmetric -o - filename
You can later decrypt the file with:
gpg --decrypt filename.gpg
I use PasswordSafe encrypted files in exactly this configuration. GUIs are available for Windows/Mac/Unix/Java. cliPSafe gives it a command line interface.
THe original code was written by Bruce Schneier, well known in the security world, but I've never used cliPSafe.
As already noted GPG solves the problem. Using the gpg command directly for encrypting text files may be a bit cumbersome though, especially as you would often decrypt the file to a seperate file, add some text (passwords in this case) and the reencrypt it (which will possibly expose your unencrypted data).
Vim has a very good plugin called gnupg for trasparently handling encrypted files using GPG. Using this plugin the unencrypted data will never be written to disc and you can just treat it as any other file (except for the passphrase question popping up of course).