We have a perl program that generates gpg encrypted files for multiple folks.
Today, we added dan#example.com.
When I run the encryption script, it happily encrypts the file for dan#example.com using jordan#example.com. This is presumably because jordan#example.com was in my keyring first.
I've tested from the command line, and if I use gpg -r dan#example.com --encrypt foo.txt, the friendly client chooses to use the public key for jordan#example.com, instead of the more explicit dan#example.com.
Of course, if I use key ids it works, but that's not really what we've got here. Is there a way to tell gnupg to use the more explicit email address without resorting to key ids?
This is documented in the manual page that comes with gpg. Section "HOW TO SPECIFY A USER ID" you find the option "By exact match on an email address.". So the answer to your question is to use angle braces such as <dan#example.com>.
Related
I was reading this article Encrypting Environment Files to encrypt and decrypt the .env content.
as per the documentation, after running php artisan env:encrypt command, it generates a new .env.encrypted file, and also the output of the command is returning a Key.
To decrypt the content, the command is looking for LARAVEL_ENV_ENCRYPTION_KEY which always changes as soon as I encrypt the content. So I don't understand the best use of this feature.
Real Use case.
Let's suppose, I have added a new variable in the .env file and encrypted the file.
Now I shared this file with other team members, now I have to share the key as well to decrypt it.
after decrypting, another team member adds a new variable and he has to follow the same routine. encrypt, and share the key.
for decryption, you have to remove the .env file, and obviously LARAVEL_ENV_ENCRYPTION_KEY will never be found(or which might be changed because of the latest encryption), so you have to pass the --key option while decrypting the content.
'To decrypt the content, the command is looking for LARAVEL_ENV_ENCRYPTION_KEY which always changes as soon as I encrypt
the content. So I don't understand the best use of this feature.'
You can always provide your own encryption key while decrypting using:
php artisan env:decrypt --force --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
In addition, you can encrypt by provide the same encryption key using:
php artisan env:encrypt --force --key=3UVsEgGVK36XN82KKeyLFMhvosbZN1aF
The team members don't need to share a new encryption key every time they add a new environment variable to the .env file since they will always be using the same key to encrypt the edited .env file before adding/committing the regenerated .env.encrypted file to source control.
I am trying to encrypt a file using GPG and then decrypt it whenever required.
I saw an example to encrypt it
https://gist.github.com/ayubmalik/a83ee23c7c700cdce2f8c5bf5f2e9f20
But, there is nothing described about how to decrypt it
There is one more example that allows String or text encryption and decryption
https://gist.github.com/stuart-warren/93750a142d3de4e8fdd2.
But, I have to work on files. Can anyone help me to find the solution to it?
I have been trying to create certificates with the subjectAltName of the type /subjectAltName=DNS.1=www.domain.net,DNS.2=*.www.domain.net but when I view the key only the CN I set is displayed, ie www.domain.net.
Is the syntax I am using for the subjectAltName wrong, or is adding the subjectAltNames from ta configuration file the only way to accomplish that?
You can put the alt names into the config lie you stated. Why do you need it otherwise anyways?
If you are too tired of always changing the config's contents, just write a shell or bash script to ask you for the input and to edit the file and roll the certificates afterwards I guess
I am using command line with bash in Mac OS X. I will ask in my script:
Enter your password?
>
Do you want to save it and do not ask this more?
The password is to unzip a file. To do this, it always has to be entered, but I want it to only be entered once.
I can easily save it in a text file, but that is too obvious.
So I want to save it in the system. Windows has the "Windows Registry". Is there a similar system in Mac OS X (or Unix) that I can save it in and it will not be lost?
Or is there another way to save the password and it will be more secure? I know if someone runs the script with debug mode (showing how the command line is created) he will easy find the password, but he will have to get the computer, so is a kind of physical security.
You could do it the way system passwords are stored: use a plain text file but store a checksum instead of plain text password. It would be best of the file wasn't accessible to the user, but even if it is, it's not that easy to reverse a checksum. Suppose you read the password into variable password. Then, you could do something like echo "$password" | sha1sum - > password_file. Then at next login, run the password provided by user through the same command and compare results. This way you can check if they entered the correct password without storing the password in cleartext.
Either use your OS's keyring (OSX has something like this), or store it in plain text. Don't pretend that you are secure when you are not. If you cannot store things securely, then store them in plain sight, so the user is not given a false sense of security.
I'm looking for a way to dump (export) the contents of an OS X keychain into a file that I can easily process elsewhere, such as tab-delimited plaintext or something of the sort.
The Keychain Access app does not offer any such functionality, and getting a key's data involves opening each in turn, and having to type in the keychain's password to see the password stored with the key, every time.
After a bit of digging, I found somebody's solution by using AppleScript and the Keychain Scripting app to access keychains (can't link to individual post; scroll down about two thirds to the end of the page):
http://discussions.apple.com/thread.jspa?threadID=1398759
Using Keychain scripting, you can access all data fields of all the keys – including the plaintext password! – and it's fairly easy to dump this data into a text file etc. I've tested it and it works well.
However, this solution still involves having to confirm access to each key by clicking OK on a dialog. This is much better than having to type in the keychain's password every time, but it's still irritating. Furthermore, you have to confirm access twice for each key; once for Script Editor (or the script itself if it's running as an app) and once for Keychain Scripting. So, if you're processing a keychain with 100 keys, you have to manually click OK on 200 dialogs.
I'm now looking for a solution to get around this. I realize that as it's the purpose of keychains to safeguard the sensitive data and prevent precisely the kind of thing I'm trying to do, any such solution would probably involve some kind of hack.
I'd be very interested in your ideas!
Allright, I'm stupid. There's a command-line tool called security that does just this (and lots of other actions on keychains).
An example usage:
security dump-keychain -d login.keychain
This will dump all the data in the login.keychain (the default keychain for a user) as plaintext, including the passwords. You still have to confirm access , but only once for each key, and it's much faster than (and doesn't throw weird errors when trying to access certain fields) using AppleScript. And it's no hack.
Without the -d option, it will dump all the fields except for the password.
The dumped data for a key looks like this (for an internet key; program keys and certificates have other fields, but the format is the same):
keychain: "/Users/<username>/Library/Keychains/login.keychain"
class: "inet"
attributes:
0x00000007 <blob>="tech.slashdot.org (<username for this web login>)"
0x00000008 <blob>=<NULL>
"acct"<blob>="<username for this web login>"
"atyp"<blob>="form"
"cdat"<timedate>=0x32303038303432333038323730355A00 "20080423082705Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>="Kennwort des Web-Formulars"
"icmt"<blob>="default"
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303038303432333038323730355A00 "20080423082705Z\000"
"nega"<sint32>=<NULL>
"path"<blob>=<NULL>
"port"<uint32>=0x00000000
"prot"<blob>=<NULL>
"ptcl"<uint32>="http"
"scrp"<sint32>=<NULL>
"sdmn"<blob>=<NULL>
"srvr"<blob>="tech.slashdot.org"
"type"<uint32>=<NULL>
data:
"<the plaintext password for this key>"
Please read this: https://gist.github.com/rmondello/b933231b1fcc83a7db0b
Ignore:-----
I found a sollution to the "Always Allow" dialog in each key!
Just run the previous command with sudo.
sudo security dump-keychain -d login.keychain
This way you'll only need to enter your password two times. One on the Terminal to sudo and another to unlock the keychain! ;)
Have a nice day!
Update, there is now a tool that does this nicely:
Keychaindump is a proof-of-concept tool for reading OS X keychain passwords as root. It hunts for unlocked keychain master keys located in the memory space of the securityd process, and uses them to decrypt keychain files.
Source: https://github.com/juuso/keychaindump
Actually I was just looking for the same:
Modified applescript from github somebody posted. To be run in ScriptEditor and must be allowed in Preferences & Security.
set keychainPassword to "yourpasswordgoeshere"
tell application "System Events"
repeat while exists (processes where name is "SecurityAgent")
tell process "SecurityAgent"
delay 0.1
try
set value of text field 1 of window 1 to keychainPassword
click button "Allow" of window 1
end try
end tell
end repeat
end tell
You must click each window separetly in order to activate them. For that I used tool "murgaa auto clicker" I had known from runescape many years ago (http://www.murgaa.com/auto-clicker-mac/ seems still active). You just set shortcut for autoclicking (eg. Command+R) and set timer to 10ms and it works like charm.
Keysafe
Keysafe reads and decrypts Apple Keychain files. Use Keysafe to securely access your passwords and credentials without a Mac.
I wrote a tool called Keysafe to extract the contents of Keychain files. The tool is available on Mac, Windows, and Linux.
Keysafe is not free; a licence is required to fully decrypt a Keychain. Without a licence the contents are still extracted but the decrypted values are partially redacted and secure notes are not post-processed into RTFD files.
If you have a Keychain that does not "just work" with Keysafe, please get in touch. The Keychain format is expansive and finding edge cases is always interesting.
I found solution for not clicking "Allow" multiple times
sudo su
security dump-keychain -d /Users/YourUsername/Library/Keychains/login.keychain