I have stored passwords as hash and salt, encrypted with base64. Now I want to recover original password from that hash and salt. How? I am using vb.net in MS Visual Studio, but I am comfortable with C#, too.
You're mixing up several things. First of all you shouldn't encrypt passwords. Instead you should hash them. Base64-encoding is neither of both.
A base64-encoded string may not be directly human-readable, but it can be very easily be converted back to cleartext. So it's not safe at all.
Have a look at this comprehensive article to learn more about password hashing:
https://crackstation.net/hashing-security.htm
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.
I have a password hashing mechanism based upon Rfc2898DeriveBytes (based on code detailed here: http://crackstation.net/hashing-security.htm). Internally, this class utilizes SHA1 which - the CrackStation link does indicate the SHA1 is "old", but also states that, although Rfc2898DeriveBytes uses it internally, Rfc2898DeriveBytes is still a good mechanism.
The security department of a customer of mine has heard that that "SHA1 has been compromised" (specifically, that, for purposes of signing a document for transmission across the internet, SHA1 has been defeated, under certain circumstances - the fact that this "vulnerability" does not apply to a password hash is immaterial to the security department). As a result, they have demanded that we alter our password hashing mechanism to employ SHA2.
Currently, the .Net framework has no equivalent of Rfc2898DeriveBytes that employs SHA2 (or SHA256, etc.) internally. I know that I can use reflection to get at the source code for this class and change it, but I've always been told that the first rule of encryption is "don't grow your own".
This is principally a political demand by my customer, not a technical one, which could be easily satisfied by running the password through a SHA2 hash prior to running it through Rfc2898DeriveBytes. However, I am not sufficiently knowledgeable about cryptography to know if this might be bad - might in fact result in an objectively less secure password hash.
Does anyone know of an Rfc2898DeriveBytes equivalent class that employs SHA2? Or, does anyone know if running the password through a SHA2 hash prior to Rfc2898DeriveBytes would be perfectly safe?
Download the free code samples from "SecurityDriven.NET" book. Find the PBKDF2 class which takes an HMAC factory. Available factories include SHA2 (256, 384, 512).
Running the password through SHA2 hash prior to Rfc2898DeriveBytes is not the right thing to do, even if this is unlikely to be the weakest part of whatever you're doing (you'd be losing password entropy).
I am using AES (Rijndael) symmetric-key algorithm to encrypt-decrypt data.
I am using the System.Security.Cryptography. PasswordDeriveBytes function;
PasswordDeriveBytes password = new PasswordDeriveBytes(
passPhrase,
saltValueBytes,
hashAlgorithm,
passwordIterations);
Looking this function up on MSDN etc, it does not tell you explicitly what parameters ‘hashAlgoritm’ can take.
There are examples on the internet of it taking SHA1 as well as SHA256. I experimented with this and found that it can take SHA512.
But without documentation, I have no idea if SHA512 is really better than SHA256 or SHA1 or even MD5.
Can anybody shed light on this issue?
The security of the hash method is slightly less important for a key derivation function. It's probably best to choose one that matches the required key size, although use of MD5 in general should be discouraged. Other applications may only use SHA-1 .
Note that PasswordDeriveBytes has been deprecated and should certainly not be used for output larger than the hash size. Use PBKDF2 istead, see Rfc2898DeriveBytes.
Is there standard way to generate Password Hash with Microsoft development tools?
Or maybe there is most common way. (I have read that there is MD5, STA1)
Unfortunately I don't have server's source code, but have to consume SOAP web-services.
The must be some algorithm to generate hash code. I need to implement it using Java or using some library.
Here is part of SOAP request that I need send to server. Look at oldPasswordHash.
- <ChangePassword xmlns="urn:____________">
<sessionGUID>{864da5f3-21b6-486a-8bd3-c507ae3d224e}</sessionGUID>
<oldPasswordHash>089ad55bd0a8f6d3c2e2bbf0e4e1475c7e984ef1</oldPasswordHash>
<newPasswordHash>f4a69973e7b0bf9d160f9f60e3c3acd2494beb0d</newPasswordHash>
</ChangePassword>
These are SHA1 hashes of the unsalted passwords.
f4a69973e7b0bf9d160f9f60e3c3acd2494beb0d is the SHA1 hash of Passw0rd!.
The fact that I was able to reverse one of the hashes with a rainbow table service demonstrates that hashing of passwords without salting is very insecure.
In C# you can reproduce the implementation like this:
public static string Hash(string value)
{
var sha = new System.Security.Cryptography.SHA1CryptoServiceProvider();
byte[] hash = sha.ComputeHash(Encoding.ASCII.GetBytes(value));
return BytesToHex(hash).ToLower();
}
private static string BytesToHex(byte[] bytes)
{
return String.Concat(Array.ConvertAll(bytes, x => x.ToString("X2")));
}
For a java version, take a look at the first google hit for "sha1 java".
As for hash algorithm, you need a cryptographic hash function, that is a hash function that is (for all intents and purposes) impossible to reverse. Be also aware that there exist files (and indeed websites) that strive to calculate every hashcodes for every string and publish these so called Rainbow Tables. (SHA256 seems like a good choice to me.)
As for programmatic generation, look at System.Security.Cryptography in .NET.
As for tooling to create hashes, I know of nothing that comes with Windows. Obviously you can use the GNU tooling via Cygwin (or the like) or search for a command-line tool for the algorithm you have chosen.
Cygwin for windows provides command line hashing tools such as sha1sum in its coreutils package that can easily compute a hash for you. The Bouncy Castle libraries would provide implementations of most common hash algorithms in both Java and .NET.
The sample XML doesn't say much. The strings are hex, 40 chars in length which is 20 bytes or 160 bits. That may mean it's SHA-1 (which is 160 bits) but not necessarily. In addition, how did it generate a hash from the password. Was the password plaintext, plaintext with some salt, plaintext mixed with some other hash etc. I guess if you install sha1sum first from the command line, you can see what happens if you feed the password into it. You might get lucky and discover what it's doing. Then you can proceed to code up the equivalent with Bouncy Castle.