Develop Reference

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.

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.

Java using SHA1

I try to implement a SHA1 decoder but i can't find something usefull on internet. Can anyone help me find information on how I can implement an SHA1 decryption. I want to transform the encrypted data to Strings.

I try to implement a SHA1 decoder but i can't find something useful on internet.
SHA-1 is a hash function. It's one-way: you hash the data, and get a hash. If you hash the same data, you'll get the hash; if you hash different data, you'll "almost certainly" get a different hash.
If you could "decrypt" it, it wouldn't be doing its job.

If you figure out how to crack sha1 props to you. I think the government may be able to do it but you would be hard pressed to find a public library that has a smart algorithm that doesnt take a great deal of resources to crack.
they claim they can crack it and decrypt it, I doubt it works
another source that claims they can decrypt it, i doubt their code is publicly available though
Is there a specific reason you are trying to decrypt it, maybe there is a flaw in your design or another way to solve your problem?
heres a neat diaolog about the progression of sha1

Hash functions are designed to be one-way. So you can't simply calculate the input from the output. Doing this is called a pre-image attack. If the message itself can't be guessed, such an attack requires around 2^159 attempts, which is infeasible.
The best way to reverse SHA-1 is to guess the input. For typical user passwords this attack succeeds quite often, since the password isn't complex enough. For example a typical GPU will be able to try >100mio passwords per second.
This is why we don't use plain SHA-1 for password hashing. We use deliberately slow schemes, such as PBKDF2, bcrypt or scrypt with sufficient work-factor.

If you need to find the password behind a SHA1 hash, put the Hash on google.
If the password is common, and the hash is not 'SALTED', you have a chance to get the password.
Else read this:
https://en.wikipedia.org/wiki/Rainbow_table

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.

Creating a Strong Password Scheme When All Data is Stored on Device

Background:
I have been working on an Android application that stores data in a local database as my pet project. Lately, I have decided that I want to password protect the application and encrypt the database. Now, I am aware of the complexities of encrypting the database on the fly and have (given the expected usage pattern of my application) decided to just encrypt the whole database file rather than try to store encrypted column value or the like. Thus far I have implemented a system that will prompt for a password on every application launch or whenever the user navigates away from my activity (to account for the user pressing the home key and the application not being killed in a timely manner).
Currently, I am trying to decide how exactly to go about hashing the password and where to store it. Given that everything must be stored on the device, I am basically treating the password hashes and salt as already compromised as anyone who has spent 10 minutes reading can root a given device and access my database / preferences.
I have developed what I think should still provide very strong security given the above assumptions. I wanted to get some feedback from the community to see if my solution is viable or if there is a better way.
My idea is to generate 10 different random salt values on the first run of the application. These values will be stored with the actual final password hash in the application preferences (rather than in the database). Note that there will only be one password and it is used for both user authentication and database decryption. Whenever a challenge is presented, the password will be hashed as follows:
Cleartext password is hashed.
Hashed password is run through the same checksum algorithm that is used for standard UPC barcodes. This will result in a value between 0 and 9 (inclusive).
This checksum digit will be used as an index to the array of salt values. This single salt value will be appended to the current hash.
The new hash + salt value will then be hashed and steps 2 - 3 will be repeated.
I figure doing this process for 5 iterations would give 5^10 different salt combinations alone and should make any type of rainbow attack practically impossible. Once the final hash has been verified correct, it can be used to decrypt the database.
Now, I realize that this sounds like overkill for a simple cellphone app. It is. But, this being my pet project, why not?
Question:
So, after that wall of text, is this approach reasonable or is there a better way? I think, with this in place, the weakest link would be an in-memory attack or am I mistaken? Any feedback is greatly appreciated.
Thank you in advance.
-cheers

I don't get it. If you are encrypting the database, why do you need to store a hash of the password anywhere?
Derive an encryption key from the password, which is stored in the user's brain, using something like PBKDF2. Use it to encrypt the database.
When the user wants to decrypt the database, prompt them for the password. Derive the key from it again, and decrypt the database.
You store a password hash for authentication purposes. But this is encryption, not authentication.
Suppose you have a hash function that takes salt, a number of iterations, and a password as input, and returns a hash as output: byte[] hash(byte[] salt, int count, char[] password). Randomly generate one salt on the first run of the app, and hash the newly chosen password. Store this salt and the resulting hash in the application preferences. Then randomly generate another salt, and hash the password with it. Use the resulting hash as the database encryption key, but store only the new salt in the application preferences.
Later, when a user wishes to use the app, prompt for the password, and use the first salt to hash it. If it matches the stored hash, the user has proven that they know the decryption password. Hash it again with the second salt, and use the resulting key to decrypt the database.
This subsequent derivation of an encryption key might be what you meant; I am trying to make that step explicit, in case you intended to use the password directly as an encryption key. Having two different salts, one for authentication, and another for encryption, will allow you to use the same password for both purposes, safely.

What I do is use the record ID of the database row as the salt. You could hash the id of the row and use that for a zestier salt.
If you only have a dozen or so passwords, it seems approximately similar in security to what you are already doing. But if you have hundreds or tens of thousands, it becomes infeasible to calculate one dictionary table for every ID.

Ok... Assuming your hashing method is not weak, it doesn't matter if the salt is known - Salt is simply so that 2 users with the same password have different hashes - and a casual inspection of hashes wouldn't result in identical passwords being obvious. Salt should be unique per user.
Assuming the (malicious) user has root, there's absolutely NOTHING you can do to prevent them compromising your app except encryption - specifically the user could theoretically get your binary, decompile it to work out how it authenticates users, bypass it and then just follow the decryption mechanism - And since the encryption key is not related to user PW in your scenario, it has to be stored SOMEWHERE - and if the app can read it, so can root
The only truly secure approach would be to have a single-user (or at least single-password) which related to the DB encryption key.
Aside from that, the best you can hope for is to make it sufficiently difficult for a malicious user that it' not worth their time.

Even with 10 salt values you are still technically vulnerable to rainbow table attacks. All they have to do create 10 rainbow tables each using your salt. It will take them sometime to generate all new rainbow tables, we are talking days or weeks. Once they have the tables though the can use it against all the users who downloaded the application. If you store a unique salt per password that would require them to go through the whole process for every password, which is a lot of work for just one password. The question is would someone want to go through all that trouble to get one password. Here is a good post about storing passwords "You're Probably Storing Passwords Incorrectly"

I cannot spot any major weakness in this scheme. However, it does not add any security over best practice salting; i.e. generating an storing a new per-user salt each time the user sets or changes their password.
This scheme does add an extra point of attack. If there is a weakness in the way that the salts are generated (e.g. predictability), then it is likely to be easier to exploit if you restrict yourself to 10 salts all generated at the same time. That might give an attacker more leverage to guess what the likely salts are, and hence create rainbow tables.
But the main problem with your approach (IMO) is just the complexity.