I am trying to find some samples of how to take a string and hash it using MD5, and then be able to reverse hash (correct term?) back to the original string.
Does anyone know of any documentation that shows how this can be done, or ideally has any sample code they could share?
I've read about the java.security.MessageDisgest class, but that appears to be only one-way. I need to be able to convert the hash back into its original data. Is MD5 the best algorithm to use, or should i be looking at something else entirely?
MD5 is destructive. You lose data when you hash.
Perhaps you are looking for a symmetric cipher like DES or (better) AES?
The bouncycastle security provider has a DES implementation example at http://www.bouncycastle.org/specifications.html
EDIT: Sorry, I've jumped the gun. What is your objective: Compression, Indexing, Checksumming, Encryption, or something else?
Hash functions are designed to be irreversible.
What you need is to use a secure transport layer, like SSL or TLS (eg: HTTPS is HTTP with SSL or TLS).
Please refrain from rolling your own on this one.
Note that simply using a symmetric cypher like AES on the client (eg: Javascript) is useless, because you'd need to supply the key to said client and thus an attacker would be able to trivially decrypt any intercepted messages.
Related
Is there a way to decrypt PBKDF2 password in java. Java has implementation of PBKDF2 algorithm as PBKDF2WithHmacSHA1. I got the code to create hashes for password. I referred to below link for hashing technique:
http://howtodoinjava.com/security/how-to-generate-secure-password-hash-md5-sha-pbkdf2-bcrypt-examples/
My requirement is to store the third Party FTP server password in the encrypted format and get back the password in plain text form from DB when there is a need to login into the server. Can anyone suggest best password encryption method?
Note that PBKDF2 is a hashing-method rather than an encryption-method (to be precise: it is a method to derive an encryption-key from a password but it is frequently used as a password-hashing method as well). The whole point of PBKDF2 is to make it impossible to get the original password other than by brute-force guessing and make that as hard as possible too.
If you are talking about your users' passwords: you should not be able to get them in clear at all - if you did and let me know (e.g. by showing me my password) I'd instantly mark your whole site as insecure.
If you need to keep an encrypted password for your application to access another service then PBKDF2 is the wrong tool for the job, use a real encryption-algorithm like AES instead.
No it's impossible by design! Wonder why?
Following 2 articles will answer all your questions:
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
https://crackstation.net/hashing-security.htm
Is there a way to decrypt PBKDF2 password in java. Java has implementation of PBKDF2 algorithm as PBKDF2WithHmacSHA1. I got the code to create hashes for password. I referred to below link for hashing technique:
http://howtodoinjava.com/security/how-to-generate-secure-password-hash-md5-sha-pbkdf2-bcrypt-examples/
My requirement is to store the third Party FTP server password in the encrypted format and get back the password in plain text form from DB when there is a need to login into the server. Can anyone suggest best password encryption method?
Note that PBKDF2 is a hashing-method rather than an encryption-method (to be precise: it is a method to derive an encryption-key from a password but it is frequently used as a password-hashing method as well). The whole point of PBKDF2 is to make it impossible to get the original password other than by brute-force guessing and make that as hard as possible too.
If you are talking about your users' passwords: you should not be able to get them in clear at all - if you did and let me know (e.g. by showing me my password) I'd instantly mark your whole site as insecure.
If you need to keep an encrypted password for your application to access another service then PBKDF2 is the wrong tool for the job, use a real encryption-algorithm like AES instead.
No it's impossible by design! Wonder why?
Following 2 articles will answer all your questions:
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
https://crackstation.net/hashing-security.htm
DSA & RSA
It's not about which one is stronger.
I've been researching the subject on the internet and below is the summary of information I've got.
Can you please advise if it is correct or not, and if there are any additional important issues which I don't mention here.
Here I am talking only about DSA vs RSA in application to Java.
My main goal - to use Public key algorithm to send Session key (AES) from client to server and then to check authencity of client.
DSA.
1. In Java you're are supposed to encrypt the file with private key.
2. It means that IT IS a signature - anyone with a public key can read it, but only the owner can sign it.
3. If you try using public key as private and vice versa, you'll run into trouble, because it is not that difficult to guess public key by private.
4. You effectively can't use DSA to send Session key, because everyone will be able to decrypt it.
RSA.
1. In Java you're are supposed to encrypt file with public key.
2. It means that this is best way to deliver secret messages to one specific recepient. Nobody can read it after being signed, except for the owner.
3. If you try switching keys with each other it will bring troubles (the same as above)
4. You can effectively use RSA for a client to send Session key encrypted with Server's open key and then receive confirmation from servers signed with Client's open key.
Based on this I decided to use RSA for my purposes.
AES256 vs AES128
Another unrelated question - do you think that for session encryption without any extremely sensitive data it makes sense to use AES256?
I'd like to, but it creates problems for end user. I know it is very easy to install update to Java which allows 256 bit keys, but the sad truth is that even such simple thing can cut potential userbase by half.
On the other hand - if I don't send sensitive information (like credit card numbers) and each key is used for not more than a few days, maybe AES128 is enough?
Obviously I am going to include the option to use AES256 for those users who are not bothered by the need to install update.
Thanks for any comments!
As you found out, DSA is only a signature algorithm, not a encryption one, and as such not suitable for key exchange.
If you have a online connection (and not just transport from one point to another), you can use Diffie-Hellman (which is based on similar ideas like DSA), and use DSA or RSA in signature mode to authenticate the other side to avoid a man-in-the-middle attack.
Other than that, RSA key exchange is also quite usual (i.e. sending the key AES key encrypted with the RSA key of the server).
For the AES variants, AES-128 should be secure for about any time (i.e. bruteforcing should take longer than you'll live). There is only a larger key variant as the US military wanted to use different levels of security for different stuff. (And also, AES-256 is lately showing some (theoretical) weaknesses which are not in AES-128, which could mean that AES-128 is actually more secure.)
But as Kerrek commented, don't try to invent your own protocol, use existing ones. You will make all mistakes the other ones did before, and add new ones. (You can do your own implementation of these protocols if you want, but it is also often easier and safer to reuse existing implementations, too - there are lots of things to do wrong even with secure protocols, like using bad random numbers.)
For online (two-sided) communication, SSL (or now better its successor TLS) is the way to go. In Java, it is available as the SSLEngine class (if you want to use asynchronous I/O), or with a SSL(Server)SocketFactory (for normal socket read/write). I used this for applet/server communication (for my project fencing-game).
For offline (one-directed) communication (like e-mail) or storage, use the PGP data format (which also can use RSA and AES). (I don't know of an existing Java implementation, though.)
DSA means "Digital Signature Algorithm". It's meant for signatures. You cannot use it to encrypt anything.
AES128 is plenty secure enough for sensitive information. Even the US government allows its use for anything except information classified as TOP SECRET, and that only because of a "better safe than sorry" mentality and considering that such information may still be harmful if decoded 50 years from now. I wouldn't hesitate a second to use it for transmitting credit card numbers (which, after all, expire in less than 10 years).
Does anyone know good tutorials to change PBEWithMD5AndDES encryption algorithm to AES for a Java application? Specially , I want to know what precautions I should take while changing this algorithm to more secure one. Any important test cases to check before and after algorithm changes. Another question is since I have used PBEWithMD5AndDES , most of the user passwords are encrypted using that algorithm. So if I change my algorithm to AES , how do I make sure that decryption of passwords happen with old algorithm while I can still use new algorithm for any new encryption.
Normally you wouldn't encrypt a users password, you'd just hash it with a salt instead.
Migrating from one encryption system to another is going to be a bit of a pain, as I see it you have two options:
During the upgrade process decrypt then re-encrypt all the passwords
Add a flag indicating the encryption method used. All existing passwords will obviously be set to the current standard. New users will be set to whatever method you choose and you can migrate other users when they change their password.
If you've already got data encrypted in format a, and you want to start using another encryption scheme, b, I can think of two ways to accomplish this:
Decrypt all of your data and re-encrypt it using `b`. This approach would be good when you can take your data store offline and "fix everything at once."
For each item you attempt to decrypt, try to decrypt it using `b` first. If that fails, decrypt it using `a`. The next time you try to encrypt something, make sure you use `b`. This approach could be used when you can't take your data store offline, but you want to encrypt all of your data using another algorithm. All of your data will eventually be encrypted using the other algorithm.
There's really no problem changing algorithms. What you need to do is decrypt the cipher text and then encrypt the resulting plain text with the new algorithm. That's straightforward. If you are going to perform this transition over time, I would suggest creating a new database table that keeps track of whether a particular entity (based on unique id) has been transfered to the new algorithm. If it has, then you simply use the new algorithm to decrypt it and you can forget about it, if not, then you use the old algorithm to decrypt it. Regardless though, all new encryption should be performed with the new algorithm.
Now, there's a second issue here. Why are you bothering to decrypt passwords? Just save the hash of the password and forget about it. If you are able to decrypt passwords, you introduce a potential vulnerability. If a malicious user can get a hold of your key you use to encrypt those passwords, then they could access the plain text of the password. Not only could the user then use that information to compromise your system, if your users use the same username/password combination for other sites, those accounts would be compromised as well. You should only store a hash of the password (SHA is a good one, don't use MD5) and then when the user attempts to log in, you hash the input and compare the two results. You have no need to know what the plain text password is.
you may look into ESAPI - java http://code.google.com/p/owasp-esapi-java/
ESAPI 1.4 was using PBEWithMD5AndDES, but in 2.0 they introduced AES
check their mail chain here
you may check the difference between the two implementations
PBEWithMD5AndDES is a method of taking a user's password and from it deriving an encryption scheme that can be used to protect further data. It is not a method of verifying a password, nor of encrypting one.
If you are only interested in password validation, then decrypt the passwords and replace them with a secure hash and in future match the hashes. You will also need your password reminder service to a password reset service.
The question is where is the password you are passing into the PBE algorithm coming from? If it is a fixed password for your application, then you just need to replace it and perform some kind of rolling upgrade. As an observation, if you are storing encrypted data as text, either hex or base-64 encoded, there are characters that cannot appear in the text output and which you can hence prepend to indicate a newer encryption scheme. For example the : character does not appear in base-64. That will allow you to identify what has been upgraded and what has not.
If the passwords are coming from the user, then each user has their own password derived cipher. In this case you can only re-encrypt whatever data has been encrypted with the user's cipher when the user provides their password.
The most direct replacement is going to be along the lines of PBEWithSHA256And256BitAES. Unfortunately, this is not supported by Java 6, so you will need a 3rd party JCE library such as Bouncy Castle. Bouncy Castle offers PBEWithSHA256And256BitAES-CBC-BC, which would be a suitable replacement.
The process of upgrading the cipher is a challenge. Whatever data has been encrypted with DES can only be decrypted with the user's password. I assume you do not have access to the passwords. This means you can only re-encrypt the data when the person who knows the password provides it. You are going to have a long period of time when your system contains a mixture of ciphers, so you need a way of identifying what is converted.
If we are talking about files, you could change the file suffix, or the folder they are stored in. If we are talking about BLOBs in a database, you could add an extra column to the database table to say what the encryption method is. If neither of those are possible you could add some form of header to the data to indicate that it has been encrypted in a new way. That's slightly risky as your existing data has no header and there is an outside chance it will match the new header by accident.
It may also be advisable to keep a list of which users have not yet had their data converted so you can prompt them to convert.
Hi I am developing my application in flex and JSP, so when I am passing values through HTTP Service Post method with request object but these values are tracing and modifying by testing team so I am planning to encrypt values in flex and decrypt it in jsp.so is there any algorithms like SHA or MD5 more secure algorithms, so please send any code or related links it is very useful to me. I am using like
httpService = new HTTPService;
httpService.request = new Object;
httpService.request.task = "doInvite";
httpService.request.email = emailInput.text;
httpService.request.firstName = firstNameInput.text;
httpService.request.lastName = lastNameInput.text;
httpService.send();
So is there any other way to give more secure ,please help me in this,Thanks in Advance.
you can't "decrypt" MD5 or SHA1 hashes they are ONE-WAY hashes which means they are non-recoverable.
Kinda hard to read, but (as far as I could understand) you're confusing Encryption with Hashing. Neither MD5 nor SHA are encryption algorithms, they're hash algorithms:
Hash Function
Encryption
You should consider posting to a secure area of the site, i.e. over https.
I have found a mature Flex library that implements both the MD5 and SHA-1 hash algorythms. So now you can use either one on the Flex side.
http://github.com/mikechambers/as3corelib
Of course, you can't go backwards with a hash algorythm, so you'll have to compare the persisted hash with the one sent over the wire.