Encryption method for storing passwords in database [duplicate] - java

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What function to use to hash passwords in MySQL?
Secure password storage
What is the best mechanism for storing passwords into database after encryption of the password? And what is the method of encryption and an implementation in Java?

Never store encrypted passwords. Store a secure one-way hash instead, something like SHA-1 (has some minor security issues), or one of the newer, more secure variants.
Doing so is actually against several regulatory requirements that you may be subject to, such as the PCI DSS if you have any involvement with credit cards (doing any e-commerce?).
Something like http://www.mindrot.org/projects/jBCrypt/ may also prove useful.
+1 for Borealid's comment - even with hashing, the hashing needs to be done properly, and must include "salt" (additional random data to prevent a subset of attacks). jBCrypt will do this for you (as will other similar libraries).

A common way to store passwords is to hash them using a message digest algorithm. I'd recommend SHA1, or if you need more bytes (-> less collision possible), SHA256 or 512. Here's an SHA1 implementation in Java:
http://www.anyexample.com/programming/java/java_simple_class_to_compute_sha_1_hash.xml
It's also advised that you use a salt for making gessing password hashes even harder. Explanation:
http://en.wikipedia.org/wiki/Salt_(cryptography)

Related

Confused with BCryptPasswordEncoder and salting [duplicate]

The current top-voted to this question states:
Another one that's not so much a security issue, although it is security-related, is complete and abject failure to grok the difference between hashing a password and encrypting it. Most commonly found in code where the programmer is trying to provide unsafe "Remind me of my password" functionality.
What exactly is this difference? I was always under the impression that hashing was a form of encryption. What is the unsafe functionality the poster is referring to?
Hashing is a one way function (well, a mapping). It's irreversible, you apply the secure hash algorithm and you cannot get the original string back. The most you can do is to generate what's called "a collision", that is, finding a different string that provides the same hash. Cryptographically secure hash algorithms are designed to prevent the occurrence of collisions. You can attack a secure hash by the use of a rainbow table, which you can counteract by applying a salt to the hash before storing it.
Encrypting is a proper (two way) function. It's reversible, you can decrypt the mangled string to get original string if you have the key.
The unsafe functionality it's referring to is that if you encrypt the passwords, your application has the key stored somewhere and an attacker who gets access to your database (and/or code) can get the original passwords by getting both the key and the encrypted text, whereas with a hash it's impossible.
People usually say that if a cracker owns your database or your code he doesn't need a password, thus the difference is moot. This is naïve, because you still have the duty to protect your users' passwords, mainly because most of them do use the same password over and over again, exposing them to a greater risk by leaking their passwords.
Hashing is a one-way function, meaning that once you hash a password it is very difficult to get the original password back from the hash. Encryption is a two-way function, where it's much easier to get the original text back from the encrypted text.
Plain hashing is easily defeated using a dictionary attack, where an attacker just pre-hashes every word in a dictionary (or every combination of characters up to a certain length), then uses this new dictionary to look up hashed passwords. Using a unique random salt for each hashed password stored makes it much more difficult for an attacker to use this method. They would basically need to create a new unique dictionary for every salt value that you use, slowing down their attack terribly.
It's unsafe to store passwords using an encryption algorithm because if it's easier for the user or the administrator to get the original password back from the encrypted text, it's also easier for an attacker to do the same.
As shown in the above image, if the password is encrypted it is always a hidden secret where someone can extract the plain text password. However when password is hashed, you are relaxed as there is hardly any method of recovering the password from the hash value.
Extracted from Encrypted vs Hashed Passwords - Which is better?
Is encryption good?
Plain text passwords can be encrypted using symmetric encryption algorithms like DES, AES or with any other algorithms and be stored inside the database. At the authentication (confirming the identity with user name and password), application will decrypt the encrypted password stored in database and compare with user provided password for equality. In this type of an password handling approach, even if someone get access to database tables the passwords will not be simply reusable. However there is a bad news in this approach as well. If somehow someone obtain the cryptographic algorithm along with the key used by your application, he/she will be able to view all the user passwords stored in your database by decryption. "This is the best option I got", a software developer may scream, but is there a better way?
Cryptographic hash function (one-way-only)
Yes there is, may be you have missed the point here. Did you notice that there is no requirement to decrypt and compare? If there is one-way-only conversion approach where the password can be converted into some converted-word, but the reverse operation (generation of password from converted-word) is impossible. Now even if someone gets access to the database, there is no way that the passwords be reproduced or extracted using the converted-words. In this approach, there will be hardly anyway that some could know your users' top secret passwords; and this will protect the users using the same password across multiple applications. What algorithms can be used for this approach?
I've always thought that Encryption can be converted both ways, in a way that the end value can bring you to original value and with Hashing you'll not be able to revert from the end result to the original value.
Hashing algorithms are usually cryptographic in nature, but the principal difference is that encryption is reversible through decryption, and hashing is not.
An encryption function typically takes input and produces encrypted output that is the same, or slightly larger size.
A hashing function takes input and produces a typically smaller output, typically of a fixed size as well.
While it isn't possible to take a hashed result and "dehash" it to get back the original input, you can typically brute-force your way to something that produces the same hash.
In other words, if a authentication scheme takes a password, hashes it, and compares it to a hashed version of the requires password, it might not be required that you actually know the original password, only its hash, and you can brute-force your way to something that will match, even if it's a different password.
Hashing functions are typically created to minimize the chance of collisions and make it hard to just calculate something that will produce the same hash as something else.
Hashing:
It is a one-way algorithm and once hashed can not rollback and this is its sweet point against encryption.
Encryption
If we perform encryption, there will a key to do this. If this key will be leaked all of your passwords could be decrypted easily.
On the other hand, even if your database will be hacked or your server admin took data from DB and you used hashed passwords, the hacker will not able to break these hashed passwords. This would actually practically impossible if we use hashing with proper salt and additional security with PBKDF2.
If you want to take a look at how should you write your hash functions, you can visit here.
There are many algorithms to perform hashing.
MD5 - Uses the Message Digest Algorithm 5 (MD5) hash function. The output hash is 128 bits in length. The MD5 algorithm was designed by Ron Rivest in the early 1990s and is not a preferred option today.
SHA1 - Uses Security Hash Algorithm (SHA1) hash published in 1995. The output hash is 160 bits in length. Although most widely used, this is not a preferred option today.
HMACSHA256, HMACSHA384, HMACSHA512 - Use the functions SHA-256, SHA-384, and SHA-512 of the SHA-2 family. SHA-2 was published in 2001. The output hash lengths are 256, 384, and 512 bits, respectively,as the hash functions’ names indicate.
Ideally you should do both.
First Hash the pass password for the one way security. Use a salt for extra security.
Then encrypt the hash to defend against dictionary attacks if your database of password hashes is compromised.
As correct as the other answers may be, in the context that the quote was in, hashing is a tool that may be used in securing information, encryption is a process that takes information and makes it very difficult for unauthorized people to read/use.
Here's one reason you may want to use one over the other - password retrieval.
If you only store a hash of a user's password, you can't offer a 'forgotten password' feature.

Recommended encryption method for recoverable passwords [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have an app which requires keeping multiple user passwords, with the requirement that they be recoverable.
I'm thinking about encrypting the passwords using the master password + another encryption mechanism.
The key for the encryption will be kept in an external system and can be retrieved using an API. The thing is i'm not sure if:
This method is secure enough
which additional mechanism should i choose for the encryption.
Thanks.
EDIT--------------
I know it's closed...but i do want to clarify - i have to have the ability to decrypt, this is a major part in my app...with that been said i think i got my answer with AES algo. I dont need hashing since hashing is irreversible
Stack overflow is a forum for helping you with coding issues.
This question is more suited to The security forum.
That said, there are some standardized guidelines for encryption.
When implementing a symmetric encryption cipher, it's best to use the AES Algorithm. This is the most secure symmetric key block cipher to date, and is the standard for what we currently consider as "protected".
If you're looking to hash passwords, which is the standard for password storage, then there is no need for a key. Use the SHA1 algorithm. In terms of the size of the output, it is the more secure hashing algorithm that is currently in use. Other options are SHA256 and SHA512
Edit: Oh the times they are a changing. And so are the hashing algorithms! People are moving from the SHA family of hashing algorithms to Bcrypt, which has several other features like introducing a cost factor to protect against rainbow tables.
i'm not sure if [...] This method is secure enough
No it isn't. Any method of password storage that allows the recovery of a password rather than a secure method of resetting it is not considered to be 'secure' by most. Additionally, how does is the user sent their 'recovered' password? Because using email to do this is just about the worst possible method.
If you cannot get around having to be able to "recover" the password, then what you want is asymmetric [aka public key] encryption. The password would be encrypted by the public key and stored in the database for comparison. The private key should be kept separate, ideally offline on a memory stick in a safe, and protected by at least one password, if not two or more passwords held by separate people.
As others have mentioned this question is better suited to http://security.stackexchange.com than here, but it has already been asked many times, and you will get more strongly-worded encouragements about not doing it this way at all rather than solutions.
Here is your mandatory read: You're Probably Storing Passwords Incorrectly
Now, on the question of how to store ciphered passwords. Don't. Store hashed passwords.
You are probably asking to solve the wrong problem. I suspect you want to create a feature to recover passwords... in that case I'll send you to one of my previous answers if you don't mind.
As an alternative, you may be wanting to store multiple keys for a single user on a client machine. If this is what you want, then your best bet is to secure it with the security the that the operating system offers you. You should not expect to do better than ciphered files for the user provided by means of the operating system.
Otherwise, you basically designing the way over which all of the stored passwords are going to be stolen. Either because what is considered secure now may no longer be considered secure tomorrow, or because we are humans (right?) and we can commit mistakes.
Anyway, your security will be at best as strong as the authentication process of the secondary API (I mean, the one to retrieve the key to decipher the passwords). You do mention Java, what are the chances of your java code being reverse engineered to discover how to get the passwords?
PHP supports SHA1, manual: http://php.net/manual/en/function.sha1.php
if (sha1($str) === 'd0be2dc421be4fcd0172e5afceea3970e2f3d940') {
echo "Would you like a green or red apple?"; }
And JAVA SHA1 example: http://www.herongyang.com/Cryptography/SHA1-Message-Digest-in-Java.html
You can combine SALT + PSK(SHA1) with AES encryption.
I recommended use to SYSTEM SALT (generated SHA512 key on system + SALT on user + PSK SHA512 for login).
Or better use PBKDF2 if you cant use either, bcrypt or scrypt with SHA2.

Java AES key generation

I'm trying to write a simple password manager in java. I would like to encrypt the file with the stored passwords using AES 256 bit encryption. In addition I would like the user to be able to decrypt the file with a password. When reading other posts online almost all of them stress that it is not secure to simply use a password as a key, they mention using random salts to add security. But I do not understand how I can use random salts when generating the key. If I create the key from the user's password and a random salt then when they try to decrypt their file how will I know what the salt was? This has me completely confused.
Currently I run their password through several different hashes using a constant salt at each step. Is this sufficiently secure or I am I missing something? Any help on how to securely generate a key from a password would be greatly appreciated! Thanks in advance.
Remember that a salt isn't a secret. You can just append it to the encrypted data. The point of the salt is to prevent somebody from using a pre-computed dictionary of common pieces of data encrypted with common passwords as a way into "cracking" the encrypted file.
By making sure that the salt is random and combining it with the password, you remove the possibility of a dictionary attack because there's (effectively) no chance that a hacker will have a database of data pre-encrypted with your "salt+password". (As a starter, see this page, from one of my tutorials, on salts in password-based encryption.)
You also (effectively) eliminate the problem of collisions: where using the same password on two files may give an attacker a clue to the content if the same block of data occurring in both files looks the same in the encrypted version.
You still usually need to take other precautions, though, simply because a typical password doesn't usually contain much entropy. For example, 8 perfectly random lower case letters will generate about 40 bits of entropy; 8 lower case letters obeying typical patterns of English will generate about 20 bits of entropy. In other words, of the 2^256 possible keys, in reality typical users will be choosing among some small fraction in the range 2^20-2^40. In the case of a savvy user, the situation gets a little better, but you will be very unlikely to get close to 256 bits of entropy. (Consider that in a "pass phrase", there'll be about 2.5-3 bits of entropy per character, so a 30-character pass phrase gives you about 75 bits of entropy-- and let's be honest, how many people use anything like a 30 character password?; 8 perfectly random characters using the 'full' range of printable ASCII will give you a little under 64 bits.)
One way of alleviating this situation a little is to transform the password (with salt appended) using a computationally complex one-way function so that it will take a hacker a little longer to try each key that they want to guess. Again, see this page for more details.
To give you a rough idea of the pitfalls of password-based encryption of files, you may also want to have a look at the Arcmexer library I wrote a couple of years ago, which includes a method named isProbablyCorrectPassword(). Combined with a dictionary/algorithm for generating candidate passwords, you can use it to gauge the effectiveness of the above methods (since ZIP file encryption uses a combination of these techniques).
Use this library: http://www.jcraft.com/jsch/
There's a good AES example ere:
http://www.jcraft.com/jsch/examples/AES.java.html
A lot of big names use this package, Maven, Eclipse, etc.

Use SHA-512 and salt to hash an MD5 hashed password?

I am working on a system that has been hashing user passwords with MD5 (no salt). I want to store the passwords more securely using SHA-512 and a salt.
While this is easy enough to implement for future passwords, I'd like to also retrofit the existing MD5 hashed passwords, preferably without forcing all the users to change their passwords. My idea is to just use SHA-512 and and an appropriate salt to hash the existing MD5 hash. I can either then set some flag in the database that indicates which passwords were hashed from plain text, and which ones were hashed from an MD5 hash. Or I could just try both when authenticating users. Or even just hash new passwords with MD5 and then SHA-512/salt, so they can be treated the same as old passwords.
Programmatically, I don't think this will be a problem, but I don't know enough about encryption/hashing to know if I'm compromising the quality of the hash in any way by applying a SHA-512/salt hash to a password that was already MD5 hashed. My first instinct is that if anything, it would be even stronger, a very light key stretching.
My second instinct is that I don't really know what I'm talking about, so I'd better get advice. Any thoughts?
Function composition with cryptographic primitives is dangerous and should not be done if avoidable. The common solution for your type of problem is to keep both hashes for a migration period, using the new hash where possible and transparently upgrading old passwords (when you check a password and it matches, rehash it with the new algorithm and store it)
This won't work if you have a challenge-response based scheme where you don't get to see the plaintext password, but since you seem to have a stored salt that does not change, I assume your application does the hashing.
If you hash with MD5 first, you will only have the spread of MD5 (128 bit). A large fraction of the space of SHA512 will not be covered by your passwords. So you don't take advantage of SHA512, but it won't be worse than MD5.
You have the benefit that if someone obtains the SHA512 hash and doesn't know the salt (this you have to enforce somehow) can't look up the hashes and get the passwords -- something that would be possible with the MD5 database you have now.
So yes, you can just rehash the existing MD5 passwords. But as explained in the first paragraph, it would be a bad idea to apply MD5 to all new passwords as well and then hash them as SH512. A easy implementation would be to have a boolean 'salted' field in the database next to the hashes (but don't put the salt there).
Trust your second instinct. Use an existing library made especially for hashing passwords instead of trying to cook up your own.
Probably hash your new passwords with MD5 and then hash the MD5 with your password hashing library. That way, you can maintain backwards compatibility with your old passwords.
I.e. password_hash(All old, md5'd passwords) and password_hash( md5(New passwords) )
(Warning: I'm not a cryptography expert)
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
If you look at how most Bank and high security people does there password changing. Most of them basically ask people who is using the old encryption method to create a new password. I think you first solution of placing a flag on all existing old MD5 password users, and notify them they need to create new password and slowly migrate them to the new system. That way when you trouble shoot the system if anything goes wrong you won't be asking is this a new user or an old one. Are we double hashing or single? Should never compare two hash as a possible answer because what if MD5('abc') => 123, SHA('NO') => 123, that means someone could have typed in the wrong password but still gets in.

Store different passwords in android

I am developing an android app that requires multiple default passwords to be stored.
Based on the password entered, the user will be shown different forms to be filled.
What is the best solution to store the default passwords if the number of default passwords are more say 10 to 20?
I see two possibilities:
Hash all passwords (together with a salt!) and store the hashes in the normal sqlite database. Each time a user enters a password, you would generate the hash (with the salt) and look in the database if there is a mathing password hash. If no, no password was right. If yes, you can look which of the passwords matched, and forward to the correct form activity. Note that only one hash has to be performed when the user enters a password, so you can use slow hashing algorithms.
Store passwords in an (AES-)encrypted database, or in encrypted form in the normal unencrypted database. You can then always calculate the plain-text form of the stored passwords, for easier comparison. This approach has the downside that you would have to store a secret (key or passphrase) within your app (or get it from your server each time), which is easy to retrieve by decompilation - if these are sensitive passwords or you protect sensitive data, that would be a no-go.
I would prefer the first possibility. Also, I would not use common MD5 as hashing algorithm, but at least SHA-512 or, even better, bcrypt. Here is a good thread explaining why and how to do that on Android: Stackoverflow-Thread. Basically, you must reckon that somebody will retrieve the sqlite database, and it's then very easy to find out weak passwords (with the help of rainbow-tables) if fast hashing algorithms (e.g. MD5) have been employed. Password salts do help, but only against google attacks. Bcrypt hashes (+ salt!) are much slower to generate (which is good), making even weak passwords hard to crack.
There are many storage options available in android. See this
If the data is limited then you can go for preferences.

Categories

Resources