It is absolutely easy to create a key inside the "trusted" keyring and then export/import it (keyctl pipe/keyctl load).
However, is there a way where I can seal a known key once? I.e., I know the key: "aabbccddeeff00112233445566778899" and I want to inject it into the trusted keyring, so that it will only ever be exported back in sealed form?
I am absolutely aware about the security implications of having an explicit key copy outside of the trusted keyring and, in my scneario, that is acceptable.
Related
I'd like to generate a public/private keypair from the command line which I can use for local testing with a NEAR Protocol account. How is this done?
There are multiple ways to generate keys for custody purposes. See custody docs for examples. From the docs:
Generally, any software that can produce valid ed25519 key pair can be used to generate the keys.
To generate a straightforward keypair (see format requirements), where both public and private key will be available in plaintext to you, you can use the near command line tools to output a keypair for an account (once you've installed them):
NEAR_ENV=mainnet near generate-key your-account-name
This creates a json keypair at ~/.near-credentials/mainnet/your-account-name.json
mainnet is the network this will be used with by default and also the folder within which the JSON file will live.
If you don't specify an account, one will be automatically generated, for example:
NEAR_ENV=mainnet near generate-key
Key pair with ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh public key for an account "5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680"
If you peek into the generated JSON file, which lives at ``~/.near-credentials/mainnet/5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680.json`, it looks like this:
{"account_id":"5644304e7a48c7d425ffdaef027f1dfbd32eab129954b798eae501b610f3b680","public_key":"ed25519:6okNNRWxvWAyWMYxmgBQ2EWPyRm1FfppgXXWJELrFLXh","private_key":"ed25519:5NDP1t4JijZHZzGnEkz3dancSWsLG3Gjss4WPXNPiHWNtdtvVJttW9uPqvxKMCwwPgtYvTxzQqDE7mSN72wXsMcK"}
The keypair generated each time is different, but the JSON files persist. And, yes, the keypair displayed above is purely for demonstration purposes and isn't linked to anything interesting :) (don't go sharing real keypairs on the internet, folks).
Troubeshooting -- you may need to double check your permissions to create or write to the ~/.near-credentials directory to make this work properly.
I have a Cocoa application on OSX, which manages FileVault Disk Encryption on behalf of the user and reports back the recovery key to a server once the recovery key is generated. However, if the user changes the recovery key using 'changerecovery' command, is there anyway to listen to this event and obtain the recovery key so as to update the server?
As an alternative solution, have you considered using an institutional FileVault recovery key? With this method, you create a single key, install it on every machine that you manage, and then you can use that key to unlock the machine. This key is independent of the user's own recovery key.
There are directions here to create and deploy an institutional key: https://support.apple.com/en-us/HT202385. In addition to the manual deployment steps described in that support document, you can automatically deploy and enforce your institutional key using macOS/OS X Server Profile Manager so that it cannot be removed by the user. Instructions to do that are available here: http://impdossier.blogspot.com/2015/12/enable-file-vault-by-profile-manager.html
I feel like I'm completely missing the point of the new JCEKS keystore format in Wildfly. Maybe you can set me straight.
The way that we have Wildfly configured (and much of the internet instructs us to, for example):
We put the standard keystore entries in a standard Java Key Store ("keystore.jks") file with a password ("jks_pw")
We then create a JCEKS keystore ("keystore.jceks") with a password, salt, and round-count ("jceks_s_n").
We then put "pks_pw" into "keystore.jceks"
We then add the JCEKS password/etc ("jceks_s_n") into our jboss config (standalone.xml) as plain text, defining a entry
We then add a reference to the vault-stored JKS password to our jboss https connector (standalone.xml), as "password="${VAULT::jks::jks::1}".
What the heck did all of that accomplish???
If we just used a JKS file and a password embedded in standalone.xml, the system is susceptible to:
An attacker getting a copy of standalone.xml and the JKS file, in which case all secrets are known.
An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.
If we use a JCEKS container in the way described, the system is susceptible to:
(SAME) An attacker getting a copy of standalone.xml, the JKS/JCEKS files, in which case all secrets are known.
(SAME) An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.
This would sort of make sense if we put the actual certs inside of the JCEKS file, in which case brute-force and lookup table attacks would be harder in the second case of attack, but so far I haven't found a way to use a JCEKS-formatted keystore directly with an https connector.
Really, the only reason I care too much about this is that we apparently have a security requirement to use the "vault", but it seems pointless.
UPDATE: It is worth noting that by using the vault you're using a "masked" password to the vault in your jboss config file, but I can't figure out what this means. Apparently your masked-password + salt + rounds can unlock the JCEKS keystore (source), so I'm not sure what exactly masking accomplishes. It just seems like a third level of redirection. I've got to be missing something...
JBoss states that the security mechanism behind "vault" is security by obscurity (https://developer.jboss.org/wiki/JBossAS7SecuringPasswords)
How secure is this?
The default implementation of the vault utlizes a Java KeyStore. Its configuration uses Password Based Encryption, which is security by obscurity. This is not 100% security. It only gets away from the problem of clear text passwords in configuration files. There is always a weak link. (As mentallurg suggests in the comments, the keystore password is the weakest link).
Ideally, 3rd party ISV robust implementations of Vaults should provide the necessary security.
Vault uses an unknown password and algorithm perform a symmetric encryption of the keystore password. Without a HSM, you will always face the problem of "where store the, e.g., datasource password". So normally you'd define a property file with an Access-Control-List and store the encoded password there.
The vault just increases the effort of getting the secured password, leaving the attacker to either read the pw in-memory or reverse-engineer the vault encryption algorithm + key.
It is important to to know that the security mechanism behind "vault" is security by obscurity, which means you are just masking your sensetive data. It means if an attacker have access to your standalone.xml and the keystore, he can easily read all your data.
vault "increases the effort" -> the attacker cannot see them directly but with some (little bit) effort.
I have interest in using GPG to sign and encrypt messages, but the GPG keys are not in my private or public keyrings, they are in separate files. Is there any way to sign and encrypt messages with keys in files, rather than using keys in my keyring?
I've looked at https://superuser.com/questions/450759/simple-pgp-encryption-in-one-step/450760#450760, but it involves creating a temporary keyring in a temporary directory, and that's not quite what I want to do.
I've also looked at In-memory GPG signing (or possibly using a temporary keyring), but wants an in-memory key...
I wrote a helper script in Ruby to handle my file synchronization through some servers. It was used only in my intranet and authentication was made by SSH keys. But now I want to use it where I can't use SSH keys and I want to store the passwords in a config file.
I know, there are some encryption libraries like bcrypt or OpenSSL, but I have a problem with that:
I start my script and enter my passphrase and it is stored in a variable to decrypt my passwords.
My code is open source.
So everybody, who has access with my user to my computer (which would be the first barrier, which I'd like to extend) and looks into the memory (where my passphrase is stored) can decrypt my password file. How is that handled in applications which are relevant to security?
Edith says as a reply to DevDude (but here, because I want to keep my specifications in my question):
But then this configuration file would be plain text and not encrypted. And when I encrypt this file there are two more issues in my opinion:
The super_secret_pwd would be stored in a variable, so when I would search in the memory of the computer, I would find it, wouldnt I?
The master password for encryption would be in the memory as plain text, too.
So the big question is: Is it possible to read plain text variables from the memory? As I know it is possible in C and a big security issue.
What you are looking for is to use a YAML file with the password/API keys. and never check this file into your repo.
Then you can reference this file on your initializers, and maybe make the password a global variable or x, use configatron, etc.
This is basically how production applications work, they read their important settings from a YAML file stored on the server itself.
This is what I use:
#c = configatron
# Per environment settings
app_settings = YAML.load_file('config/secret_stuff.yml')
#c.password = app_settings['super_secret_pwd']
Do not use ENVIRONMENT variables because they have all sort of security issues. They are an antipattern.