RSA.gen_key function always asks for password when it's used to generate keys. Is there a way to feed it the password from the python code instead of typing it manually?
The only time it asks for a password is if you try to save a key and you choose to use a cipher. Just pass "cipher=None" as an argument.
For example:
key=RSA.gen_key(2048, 65537)
key.save_pem('./privkey',cipher=None)
But as Heikki said, key generation requires no password. Only saving if you choose to use encryption.
It does not ask for passwords as far as I know:
In [1]: from M2Crypto import RSA
In [2]: r=RSA.gen_key(1024, 65537)
..++++++
.......................................++++++
In [3]:
If you don't like that output, you can provide a custom callback function. See documentation and tests.
If you mean that it asks for passphrase when calling save_pem() method, you are right: the default will ask for password. But again, you can provide your own callback that provides the password programmatically.
Related
I'm testing Yubico Yubikeys 5 NFC, in general, we use KeePassXC to save sensible information. KeePassXC accepts yubikeys but just one... Anyone know if it possible to add more than one to a kdbx file?
After talking to the KeePassXC dev team, it is clear that having two different seeds in two separate Yubikeys is not possible. You need to add the same seed to the other Yubikey to keep a copy of the seed.
In the Docs section, can we read this:
What happens if I break my YubiKey? Can I create backup keys?
You should always make a copy of the HMAC secret that is stored on the YubiKey and keep it in a secure location. This can be an analog paper copy, but since the YubiKey personalization tool allows you to program a custom secret into the key, you may as well program a second key with the same secret
Can I register multiple YubiKeys with my KeePassXC database?
You can only use a single secret for encrypting the database. So you can use multiple YubiKeys, but they all have to be programmed with the same secret (see question above).
and The explanation to how to setup the same id in slot 2 in two yubikeys is here:
https://support.yubico.com/hc/en-us/articles/360013779759-Using-Your-YubiKey-with-KeePass
Just remember in the second key you must copy & paste the same seed
The complete discussion is here: https://github.com/keepassxreboot/keepassxc/discussions/6344
Recommend to use a strong master password on top of the YubiKeys & save the DB regularly to generate new challenge/response pairs. Far from perfect but better than just a password. The following method (Challenge-response with HMAC-SHA1) works on Ubuntu with KeePassXC v2.6.2 and 2x YubiKey 5 NFC with firmware v5.4.3:
Install ykman (part of yubikey-manager)
$ sudo apt-get install yubikey-manager
Check that slot#2 is empty in both key#1 and key#2. You will be overwriting slot#2 on both keys.
$ ykman otp info
Slot 1: programmed
Slot 2: empty
Generate a base32-encoded secret seed (ex: "SECRETSEED") that will be programmed into both keys. RFC2104 recommends that your seed is as long as the underlying hash function (20 bytes for SHA1)
$ base32
SECRETSEED<Enter>
CTRL+D
BASE32SECRETSEED
$
Note that the above method adds a CR to the seed. Store SECRETSEED somewhere safe (ideally not digitally) in case you lose both keys
Program the resulting "BASE32SECRETSEED" to key#1 and key#2
$ ykman otp chalresp -t 2
Enter a secret key: BASE32SECRETSEED
Program a challenge-response credential in slot 2? [y/N]: y
Verify the same challenge gives you the same response using both keys
$ ykman otp calculate 2
Enter a challenge (hex): deadbeef
Touch your YubiKey...
aabbccdd11223344556677889900aabbccdd1122
Add one of your keys to your KeePassXC database
Database > Database Security > Add additional protection > Add YubiKey Challenge-Response
Both keys should now work to unlock/save your DB
Refs:
https://developers.yubico.com/Developer_Program/Guides/Touch_triggered_OTP.html
https://github.com/Yubico/python-yubico/blob/master/examples/rolling_challenge_response
https://wiki.archlinux.org/title/YubiKey
https://www.rfc-editor.org/rfc/rfc2104
I'm building a web application. Among other fields in the table User, there are: enc_passw and salt. What's the idiomatic way to create a hashed/encrypted password in Clojure? What are the most trustworthy and decent libraries?
Also, should I just concatenate the real password and salt to calculate hashed/encrypted password? For example:
(secure_hash (str "my_real_pass" "my_salt"))
Take a look at friend's credential implementation here.
It's using [org.mindrot/jbcrypt "0.3m"].
(defn hash-bcrypt
"Hashes a given plaintext password using bcrypt and an optional
:work-factor (defaults to 10 as of this writing). Should be used to hash
passwords included in stored user credentials that are to be later verified
using `bcrypt-credential-fn`."
[password & {:keys [work-factor]}]
(BCrypt/hashpw password (if work-factor
(BCrypt/gensalt work-factor)
(BCrypt/gensalt))))
If you want an argumentation on bcrypt, read coda's here
Using Mask Password plugin I added variable in Manage Jenkins -> Mask Passwords - Global name/password pairs.
How to get it by Groovy script in parameterized section of job in Dynamic Choice Parameter?
(in my groovy script I need to specify password to get info, I want to hide it something)
Here's how to decrypt a password using its hash:
hashed_pw='your-sercret-hash-S0SKVKUuFfUfrY3UhhUC3J'
passwd = hudson.util.Secret.decrypt(hashed_pw)
println(passwd)
I'm sure there are other ways to find a password's hash, but one way it to look it up in credentials.xml
How can I safely store sensitive data online?
I want to store some extremely sensitive information online in a public folder, and I'm not sure how to go about it.
Specifically, I want to store bitcoin private keys in a .json file named "walletData.json" in a public folder. The file contains the wallet address and public key in plain text, along with an encrypted version of the private key.
Assuming anyone can access the file and attempt to crack the encryption password with their "super computers", what's the best way to safely encrypt that private key?
I know a longer password would be a good start, but ideally I don't want to need a password longer than 10 characters.
I was thinking of maybe hashing the password 1000 times, then using that hash+password as an AES encryption key. But, as everyone can see the key generation method, i'm not sure that will help? I was also thinking of padding out the encrypted private key with some other random data, but again, I don't know if it'll really help??
Is there a safe way to do this?
EDIT - after Reid's answer:
I'm trying to do this 100% in Javascript/jQuery.
When I export a CoinPrism.com wallet, I get this:
{"keys":[{"addr":"1PNLiLgW2fBokCB2wmfhZTtbmioitkqtMm","priv":"172655af193edeb54467a52fc6eb94c67eeeff8cd03555767e5cf12df694bb88f9c8b25c4019147d9e4993405274c96a","encryptionMode":"PKBDF2-SHA256","iterations":2000}],"salt":"2222b67fc7255aaf0b4027bfcabffb5e62f39e9e0aa13e8ad70f2dc75a484f26"}
The "priv" value is an encrypted private key. I don't know exactly how it's encrypted, but i'm sure that there's a way to decrypt it using just my 10 character password.
Does anyone know how they're doing this?
Is it safe to store this information online?
Well, I will just say outright that you don't need to be the one who writes the code to do this — it is far too easy to mess up, and your post makes suggestions that are concerning. (For instance, you describe something of an ad-hoc key derivation scheme, but one that is insufficient in protection.)
So, you need a library of some kind to handle this business for you.
My suggestion: Use GPG with the ASCII armor option. For example:
gpg --symmetric --armor --cipher-algo AES file.txt
This will symmetrically encrypt (--symmetric) a file (file.txt here) using the AES cipher (--cipher-algo AES) and store the resulting encrypted file in an ASCII armored format (--armor). Note: the resulting encrypted file will be stored in the filename plus the extension .asc; e.g., here, it puts the result in file.txt.asc. You can change this with the --output option.
Now, the above command will prompt you for a passphrase — this passphrase needs to be very strong, far more than 10 characters I'm afraid. This is the burden of passphrase-based encryption: you need passphrases that are strong. Ideally, you want a passphrase that is long and complicated, hard-to-guess and hard-to-bruteforce.
Since we are on StackOverflow, you may be looking to automate the passphrase entry (using scripting). To do that, there are several --passphrase related options for GPG. For example,
gpg --batch --passphrase "test" --symmetric --armor --cipher-algo AES file.txt
will use the passphrase test instead of prompting the user. Command line arguments are not safe, however, on a system, so it would be better to use the --passphrase-from-file option, which takes a single file as an argument. The first line of that file is the passphrase to be used.
when generating a password file using htpasswd -m -c file admin with the password admin the result looks like this:
cat file
admin:$apr1$V.aqW878$JCj8ivmSnFp3BnTCtLAuN.
When I try to authenticate against that using node.js the results are rather different:
Digest Hex: 21232f297a57a5a743894a0e4a801fc3
I've tried following this existing StackOverflow solution:
new Buffer('21232f297a57a5a743894a0e4a801fc3').toString('base64');
MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM=
So the result was still wrong.
When I change the digest to base64 the result would be:
ISMvKXpXpadDiUoOSoAfww==
Bottom line of my problem is that I don't get the same hashes and need help. Any advice would be greatly appreciated.
Thank you
Roman
Alright, I found the answer. htpasswd uses a "salt" which is stored in the middle bit of the password string:
$apr1$V.aqW878$JCj8ivmSnFp3BnTCtLAuN.
Salt: V.aqW878
The node-pass module gave me the right clues. See validate_md5. It uses the native openssl command to generate a salted MD5 hash.
In retrospect this makes sense since MD5 isn't safe anymore. That's the reason I didn't use it for years now and got a bit off track here. In essence, anything marked with $apr1$ is to be treated like this.