I need to use a password to login to MySQL DB. But the password is stored in AES encryption algorithm.
The login will be:
AES_PASSWORD=2hhbdhbdhbdbh (the encrypted password in AES)
mysql -uroot -p$(AES_PASSWORD)
How do I decrypt this in shell and use it? I searched in other similar queries, and couldn't find anything related to AES.
You need to know more than just the password's AES string. You need to know which AES it was encrypted with, for example, and the key or password used to encrypt it.
But lets say you you're using aes256 and know the password is "secret". You can do this:
DECODED=`echo $AES_PASSWORD | openssl enc -d -a -aes256 -pass pass:secret`
And then call mysql with $DECODED as the password argument instead.
This may or may not be the best way to invoke mysql, however, as the password appears on the command line in plain text when someone looks at the process list with 'ps'.
Related
I am making a Password Manager application for android to store and retrieve passwords whenever needed. I want to first encrypt my password and then store it in my database. I saw a tutorial where he first hash the 'key' and then apply it on the AES algorithm to encrypt the password. I am unable to understand why he does so.
I would guess that the "key" is a passphrase of some kind, which is known only to the password manager, and which encrypts all passwords -- the passwords are encrypted so they can later be decrypted and returned.
If that is the case, do not hash the key. It's better to "derive" an encryption key from it. For example, the "key" may be "snowfallsinthesummertime". HKDF is an example of a key derivation algorithm which can take this "key" and produce a strong encryption key which is then used with AES encryption to encrypt the password. That's the only way I can explain the "hashing the key" of your question.
Furthermore, along with encrypting the password, it's a good idea to prevent tampering of the encrypted data. A good way to do that is to chose the GCM mode of AES encryption which includes an "authentication tag" which would detect tampering.
Is there a linux command to see the hashed password? Not the actual password but just the hash over it. I have tried showing hash table and such but that has yet to work. Feel like I'm just missing a simple command.
On Unix/Linux systems the hashed passwords of all users are stored into the file /etc/shadow and - for security reasons - this is readable only to root.
Therefore there is no way for an unprivileged user to read its contents.
However, if the NIS service is enabled in your system/network, you can see the hashed passwords in the second column of the output of the command ypcat passwd.
My script is going to use WMI to connect to remote systems and I was looking at this post on how to go about doing so. It looks like I may need to pass in the username and password.
I am executing my script on remote systems with a Java program that runs it and parses the STDIN output.
Is it safe to pass in a password as a variable?
From the Java side the password will be in a property file (or a different method -- I'm not yet sure the best way to go about that, but its a different story) and I'll pass it in when I call the script.
never ever send passwords in plain. Use always a one way hash algorithm like MD5 to encrypt the password entered by a user.
Further never save a password as plain text anywhere. Always store the hash and compare this with the hashed input of the user.
Some articles to start with VBScript:
Is there a method to encrypt passwords stored in a VBS
Encrypting/Hashing plain text passwords in database
http://www.edugeek.net/forums/coding/6951-masking-password-inputbox-vbscript.html
http://social.technet.microsoft.com/Forums/scriptcenter/en-US/1d132da1-2014-4f34-87f5-d787e764995f/save-encrypted-password-in-vbscript
If you are worried about sending the password in plaintext via network for a WMI request:
This link says that if you have Kerberos authentication in use, password/username
cannot be intercepted on the network.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa393720(v=vs.85).aspx
Check if this helps you out.
If you are worried about saving the password on the machine (which you want use for a WMI request):
Encrypt it and store in some db/file, decrypt it whenever you want to send it across
And yes, you should use existing standard encryption mechanisms.
Hi I am accessing a repository through a URL of type svn+ssh://
Reading the following quote from SVN and SSH from Adobe I am a little confused
"Before you configure Subversion or Dreamweaver for SVN+SSH, create an RSA key pair and configure the public key on the server. This public/private key pair is used to authenticate with the server, instead of storing and passing your password in plain text."
So if I just acces a repository by svn+ssh:// pe. from command line, my password is send in clear text ? I thought part of ssh was to encrypt the password, no ?
Maybe I was unclear, I have not generated any keypairs so use my password every time, does that change anything or is the quote written in confusing way ? Thank you.
Part of ssh is to encrypt everything, not just your password. So, your password would not be going over the wire in plain text.
SSH never sends passwords in plain text. However, non-SSH protocols such as svn:// may send the password in plain text. Adobe is recommending that users use SSH. Adobe also recommends that if SSH is used, then RSA key pairs are also used. Key pairs are easier because you don't have to keep typing your password for every operation (when used with an SSH agent).
There is no password at all in this case. All authentication happens based on key pair. One key is on your client machine, another one lies on the server. All traffic is also encrypted.
I have 2 devices and I want to set up a secure communication channel between them. The only shared secret is a (7- to 20- character ASCII) passphrase. If I use PBKDF2 (from RFC 2898) with a common salt, iterations, and passphrase to generate an AES256-CBC key and IV on both sides, I think I can authenticate the user and provide an encrypted channel all in one step. Is that true, or is there some reason why I've only seen people use PBKDF2 to verify passwords?
My reasoning is that both sides need to know the passphrase to generate the same key and IV. So if device B can decrypt data from device A, they both have demonstrated that they have the same passphrase.
PBKDF2 is a fine way to generate a common key from a shared secret (you should not be generating the IV in such a way though - the IV should be random, and sent alongside the ciphertext).
However, CBC is not an authenticating cipher mode. This is because an attacker can take an encrypted message and make predictable modifications to it, without needing to be able to read the message or know the key. Such attacks have broken real world systems in the past.
You can use an authenticating cipher mode, like Galois Counter Mode (GCM) instead of CBC.
An alternative is Encrypt-Then-MAC. Use PBKDF2 with two different salts to generate two different keys - first the data is encrypted using CBC with the first key, and then a HMAC is calculated over the ciphertext using the second key.
You will also need to use single-use-nonces to prevent replay attacks.
In general, you wouldn't be able to authenticate a message using a cipher, because the message could be anything. However, if the message conforms to some specified format, I suppose it's reasonable to assume the ciphertext must have been produced with the shared key—with longer messages in more complex formats giving better assurance. For example, the padding in a block cipher can serve as a weak authentication.
For better security, compute a MAC using the shared secret and send that with the ciphertext.
While PBKDF2 can be used to produce an IV, it can only do so for a single message. In most cases it's better to select a random IV and send it with the ciphertext.
PBKDF2 does not "verify passwords". It generates keys from passwords.
To verify a password, normally you have a thing that gets encrypted with a key. The key is generated from the original password, via PBKDF2. Then the cryptotext is saved.
When you want to check whether the user-entered text matches the password, generate the key from the password candidate using PBKDF2, then try to decrypt the saved cryptotext. If the decryption works, then you have a match.
Normally, though, you would not use the password-based key as a session key.
So, NO, you normally would not protect the secure channel with the password-based key.
caf's answer is good. I'd just like to add that you're trying to implement crypto, and even for trained experts that's generally a bad idea. Using the highest-level library you can is much safe.