I have a login database, from my Android client I have to pass the password in a secure manner. I want to implement a login screen which is capable of doing encryption.
How to implement the security encryption in my application?
It's still a bit vague what it is you want to accomplish since I don't really get what you mean by "login screen which is capable of doing encryption".
If I understand you correctly though I'm guessing you want to have a login screen in your application that your users need to pass in order to use your application. Kind of like a door into a building, or a fence? Well, I can't tell you exactly how to accomplish it, but perhaps enlighten some issues.
The user enters his or her username and a password, check if the user exists in the database and compare the password against the one in the database.
Simple, but not that secure. In this case you will need to store the passwords in plaintext, meaning someone else (let's call her evil Eve) could create another application, read from the database and get the passwords.
To mitigate this you could hash your password (preferably with a salt). To hash a string, take a look at the MessageDigest class, there's an example available via the link. Now, using a hash means that you (to quote Wikipedia)
convert a large, possibly variable-sized amount of data into a small datum
i.e. you get some data other than what you give the hash function. A hash is a fast, one-way-function so you won't get the actual password back once you hashed it. But no problem, store the password's hash in the database, and compare the hash of the password when logging in.
This is somewhat better than plaintext, evil Eve might read from the database but it would not be the password she needs to enter in your application to log in. Not to worry for evil Eve, "I'll just get a Rainbow table" she says, "and compare my rainbow table with the password from your database".
So close... Well, in order to mitigate a rainbow attack you can use a salt, in other words another value added to the password that will create a different hash. The beauty of hashes are that you only need to add a small amount of additional data to make the hash seem almost randomly different from the hash without the extra bits of data. A simple salt can be the username, store hash(username + password)
instead of hash(password)
. Now, since hashes are fast to compute, the salt should be hidden somehow. How you do it is completely up to you, but you should emphazise having it secret.
Evil Eve is pretty mad by now, but she might just be able to find your salt, and in that case she just leaves her computer running when she's asleep and when she wakes up she will most likely have a cracked password.
Since hash functions are fast, why not just hash the hash of the password, and since they are fast, why not hash the hash of the hash of the password? Hey, while we are at it, why not do it this way. How long should the user have to wait before being able to login? If it's okay to wait a second, how many iterations can you complete in that second? Reading some answers in this stackoverflow thread might give some reasons to, the more the merrier. Combine this with the salt mitigation and it should be pretty solid.
Well, evil Eve will have a tough time penetrating your login screen by now, hashed passwords with salts and iterations and all.
But remember, your defense is only as strong as your weakest link! Ask yourself this as well, what am I trying to protect? Will my login screen protect that to? If the villains can't break the door, they might just go through the hedge!
You can read more about security in Java and the Cryptography Architecture if you want to learn more about security in Java.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With