i use this code for encrypt my data to blwofish but i dont know really to convert to blowfish or other encryption.
echo crypt('ab','$2a$09$anexamplestringforsalt$')."\n";
and i'm try bottom code but it's false
echo CRYPT_BLOWFISH('ab','$2a$09$anexamplestringforsalt$')."\n";
It is the crypt parameter string, that defines which algorithm is used:
$2a : This describes the algorithm (BCrypt) but should be 2y nowadays
$09 : This is the number of rounds and is usually 10 or higher
$anexamplestringforsalt : This should be a really random salt of a given alphabet
To generate a BCrypt hash, it is much safer to use the new password_hash() function though, there exists also a compatibility pack for earlier PHP versions.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
Related
I've generated a random 256 bit symmetric key, in a file, to use for encrypting some data using the OpenSSL command line which I need to decrypt later programmatically using the OpenSSL library. I'm not having success, and I think the problem might be in the initialization vector I'm using (or not using).
I encrypt the data using this command:
/usr/bin/openssl enc -aes-256-cbc -salt -in input_filename -out output_filename -pass file:keyfile
I'm using the following call to initialize the decrypting of the data:
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, keyfile.data(), nullptr))
keyfile is a vector<unsigned char> that holds the 32 bytes of the key. My question is regarding that last parameter. It's supposed to be an initialization vector to the cipher algorithm. I didn't specify an IV when encrypting, so some default must have been used.
Does passing nullptr for that parameter mean "use the default"? Is the default null, and nothing is added to the first cipher block?
I should mention that I'm able to decrypt from the command line without supplying an IV.
What is the default IV when encrypting with EVP_aes_256_cbc() [sic] cipher...
Does passing nullptr for that parameter mean "use the default"? Is the default null, and nothing is added to the first cipher block?
There is none. You have to supply it. For completeness, the IV should be non-predictable.
Non-Predictable is slightly different than both Unique and Random. For example, SSLv3 used to use the last block of ciphertext for the next block's IV. It was Unique, but it was neither Random nor Non-Predictable, and it made SSLv3 vulnerable to chosen plaintext attacks.
Other libraries do clever things like provide a null vector (a string of 0's). Their attackers thank them for it. Also see Why is using a Non-Random IV with CBC Mode a vulnerability? on Stack Overflow and Is AES in CBC mode secure if a known and/or fixed IV is used? on Crypto.SE.
/usr/bin/openssl enc -aes-256-cbc...
I should mention that I'm able to decrypt from the command line without supplying an IV.
OpenSSL uses an internal mashup/key derivation function which takes the password, and derives a key and iv. Its called EVP_BytesToKey, and you can read about it in the man pages. The man pages also say:
If the total key and IV length is less than the digest length and MD5 is used then the derivation algorithm is compatible with PKCS#5 v1.5 otherwise a non standard extension is used to derive the extra data.
There are plenty of examples of EVP_BytesToKey once you know what to look for. Openssl password to key is one in C. How to decrypt file in Java encrypted with openssl command using AES in one in Java.
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), nullptr, keyfile.data(), nullptr))
I didn't specify an IV when encrypting, so some default must have been used.
Check your return values. A call should have failed somewhere along the path. Maybe not at EVP_DecryptInit_ex, but surely before EVP_DecryptFinal.
If its not failing, then please file a bug report.
EVP_DecryptInit_ex is an interface to the AES decryption primitive. That is just one piece of what you need to decrypt the OpenSSL encryption format. The OpenSSL encryption format is not well documented, but you can work it backwards from the code and some of the docs. The key and IV computation is explained in the EVP_BytesToKey documentation:
The key and IV is derived by concatenating D_1, D_2, etc until enough
data is available for the key and IV. D_i is defined as:
D_i = HASH^count(D_(i-1) || data || salt)
where || denotes concatentaion, D_0 is empty, HASH is the digest
algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data) is
HASH(HASH(data)) and so on.
The initial bytes are used for the key and the subsequent bytes for the
IV.
"HASH" here is MD5. In practice, this means you compute hashes like this:
Hash0 = ''
Hash1 = MD5(Hash0 + Password + Salt)
Hash2 = MD5(Hash1 + Password + Salt)
Hash3 = MD5(Hash2 + Password + Salt)
...
Then you pull of the bytes you need for the key, and then pull the bytes you need for the IV. For AES-128 that means Hash1 is the key and Hash2 is the IV. For AES-256, the key is Hash1+Hash2 (concatenated, not added) and Hash3 is the IV.
You need to strip off the leading Salted___ header, then use the salt to compute the key and IV. Then you'll have the pieces to feed into EVP_DecryptInit_ex.
Since you're doing this in C++, though, you can probably just dig through the enc code and reuse it (after verifying its license is compatible with your use).
Note that the OpenSSL IV is randomly generated, since it's the output of a hashing process involving a random salt. The security of the first block doesn't depend on the IV being random per se; it just requires that a particular IV+Key pair never be repeated. The OpenSSL process ensures that as long as the random salt is never repeated.
It is possible that using MD5 this way entangles the key and IV in a way that leaks information, but I've never seen an analysis that claims that. If you have to use the OpenSSL format, I wouldn't have any hesitations over its IV generation. The big problems with the OpenSSL format is that it's fast to brute force (4 rounds of MD5 is not enough stretching) and it lacks any authentication.
I want to test (unit testing) HashPassword($password) method from WordPress.
How I can check that HashPassword("123123") will return the correct hash for it?
For example, I want to do something like:
$hashFor123123 = "$P$P)230230832482349823";
$result = HashPassword("123123");
$this->assertSame($hashFor123123, $result);
But, HashPassword method each time returns a new string with hash. That is why I cant do assert.
How to test it?
Password hashing uses a random salt, so each time you hash the same password you'll get a different value back. The theory is explained here, even though WordPress doesn't use the php password hashing functions, but rather their own. You cannot compare hashes; you can only check whether a given unhashed password matches a hash.
The random salt defeats cybercreeps' use of rainbow lookup tables to recover passwords given their hashes. This helps keep your users' passwords secret even if a cybercreep manages to steal your wp_users table. Defense in depth, it's called.
In WordPress, you can hash a password and then check it using wp_hash_password() and wp_check_password(), something like this.
$hash = wp_hash_password( '123123' );
if ( wp_check_password( '123123', $hash )) {
/* it worked */
} else {
/* it did not work */
}
It's not clear why it is worth your time to unit-test this subsystem. It is used in production many billions of times every day around the world.
The reason that the result is different every time you call HashPassword is because your password is prefixed by a random salt before it's hashed.
To compare a plaintext password against a known hash, you have to call CheckPassword.
I am using passlib pbkdf2_sha512 on my python api to verify a users password. The input string that the algorithm needs has to follow this format as far as I am aware: $pbkdf2-digest$rounds$salt$checksum
Is there a library in Node that can generate me a sha512 password and return it in such format or would I need to write my own algorithm to format it in such way and pick random salts, rounds etc.
More information about the python library.
I tried to reproduce the String generated by the python library in Node:
function sha512(password) {
const salt = crypto.randomBytes(16);
const rounds = 29000;
// I used sha256 for testing purpose, it shouldn't matter for the sake of the result
const passwordHashed = crypto.pbkdf2Sync(password, salt, rounds, 256,
'sha256').toString('Base64');
console.log(passwordHashed);
}
I generated a hash for "password" and my code returns
Encoded in Base64:
7uLTDHjAhQX0yIqXptXuhHIygNogaZRcDqa7ckc0XCj4FAAW29V6KzIzRuJKJoTqN9xjfGOyGZ21X0J1vemQLThcnIXgwt2E84VrW/ai+BdVaUPHiT8J0mutOM9j52l1fFLT7rl5Rmr8qiyGzBaWj6i0sRkrdba9IVDHr1HxGAoM8qEuCSHgKsBVVX65+1pf2DDEUsgGShzE31xiuwF8UpHwq5Cxhiq8ER5xQnKj/j3mG/AAoylPVu30Jd4aFNoRi2Lfhk+6nFwLS0R222R38Jio93qzVD0Nb8kjXqjoXIYxTY6ZOumlsXWR/NmhTQi31x6JggoO1Z1jSFnCVUUd2Q==
And when generated with the python library in adept base 64
98jZicV16ODfEsEZeYPGHU3kbrUrvUEXOPimVSQDD44
Which is obviously a much smaller String. The library mentions that their encode is very basic except for some characters being swapped but this result doesn't seem to make quite sense to me. (I used the same salt size and the same rounds as in the exmample on the library website)
i was reading this tutorial, and i encountered the following discussion about encryption. At the end there's written
In the last line, we’ve hashed the salt with the password, yielding an
encrypted password that is virtually
impossible to crack
But in my opinion an hacker who has both the encrypted_password and the salt could do the "rainbow" trick exactly as if we were using the salt.
So, where i'm wrong?
Thanks!
$ rails console
>> require 'digest'
>> def secure_hash(string)
>> Digest::SHA2.hexdigest(string)
>> end
=> nil
>> password = "secret"
=> "secret"
>> encrypted_password = secure_hash(password)
=> "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> submitted_password = "secret"
=> "secret"
>> encrypted_password == secure_hash(submitted_password)
=> true
Here we’ve defined a function called
secure_hash that uses a cryptographic
hash function called SHA2, part of the
SHA family of hash functions, which we
include into Ruby through the digest
library.7 It’s not important to know
exactly how these hash functions work;
for our purposes what’s important is
that they are one-way: there is no
computationally tractable way to
discover that
2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
is the SHA2 hash of the string
"secret".
If you think about it, though, we
still have a problem: if an attacker
ever got hold of the hashed passwords,
he would still have a chance at
discovering the originals. For
example, he could guess that we used
SHA2, and so write a program to
compare a given hash to the hashed
values of potential passwords:
>> hash = "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> secure_hash("secede") == hash
=> false
>> secure_hash("second") == hash
=> false
>> secure_hash("secret") == hash
=> true
So our attacker has a match—bad news
for any users with password "secret".
This technique is known as a rainbow
attack.
To foil a potential rainbow attack, we
can use a salt, which is a different
unique string for each user.8 One
common way to (nearly) ensure
uniqueness is to hash the current time
(in UTC to be time zone–independent)
along with the password, so that two
users will have the same salt only if
they are created at exactly the same
time and have the same password. Let’s
see how this works using the
secure_hash function defined in the
console above:
>> Time.now.utc
=> Fri Jan 29 18:11:27 UTC 2010
>> password = "secret"
=> "secret"
>> salt = secure_hash("#{Time.now.utc}--#{password}")
=> "d1a3eb8c9aab32ec19cfda810d2ab351873b5dca4e16e7f57b3c1932113314c8"
>> encrypted_password = secure_hash("#{salt}--#{password}")
=> "69a98a49b7fd103058639be84fb88c19c998c8ad3639cfc5deb458018561c847"
In the last line, we’ve hashed the salt with the password, yielding an
encrypted password that is virtually
impossible to crack. (For clarity,
arguments to hashing functions are
often separated with --.)
Rainbow tables are expensive to compute. Without the salt, you can build a rainbow table once that can be used repeatedly, since the password "password" will always yield the same hash (md5=5f4dcc3b5aa765d61d8327deb882cf99, sha1=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8) and is thus easy to identify in a password database.
With a salt, you have to compute a rainbow table for each salt you encounter. A good-sized salt, say 32 bits (ideally, 128 or even more), means you have to compute a rainbow table for every password you want to crack, thus largely defeating its purpose.
Salt is to stop someone from pre-computing a "reverse" lookup table that allows an attacker to quickly find a password that results in the target hash. Creating one of these tables is as much work, computationally, as brute-forcing the target password space, so it's only worthwhile if you can use the table on many targets.
Salt prevents this; the attacker would need to account for the salt when they generated the table, so the table would be good for only a single target, and the attacker is back to brute force.
Yes, you are right, if somebody had knowledge of your algorithm and the salt, he could generate a rainbow table. However, generating a rainbow table takes a long time the more characters are allowed.
So for example, if you have an password consisting of 10 characters, which all are numbers, you have 10^10 possibilites. If you allow lower and upper case alphabetical chars, this goes up to 62^10 possibilites, a mere 8.39 * 10^17 permutations; and that's only for 10 character passwords, you also have to take into account any length below that and above, depending on the length of password you allow.
It takes a long time generate such a table, while rainbow tables for the algorithm itself might be readily available, the salt modifies the algorithm to make it your own, and the possibility for a table existing for that is very low.
If you use salt (even if it is public but uniqueto a site) you will get a protection from hash-dictionaries, where often used passwords are already hashed.
If your salt is secure then they can not brute-force it using supercomputers. They have to check every possible password with your server (which let's hope has some form of bruteforce-protection).
I've taken a look at the StackOverflow question, "Password Encryption / Database Layer AES or App Layer AES," and I'd like to effectively and efficiently hash my passwords on registration (web app) and then be able to check they are correct on login. I'm using VB, but comfortable using C#.
I would love to use Jeff Atwood's Encryption class described in ".NET Encryption Simplified" as it's really easy to understand. It has a hashing class—but I have no idea how to "login" and compare hashes after they have been hashed. This is Jeff's demonstration of his hash methods using his Encryption class:
Sub DemoHash()
Dim d As New Encryption.Data( _
"{ts '2004-10-09 08:10:04'}The world is beautiful and needs caring by its children")
Dim hash As New Encryption.Hash(Encryption.Hash.Provider.SHA1)
Dim hash2 As New Encryption.Hash(Encryption.Hash.Provider.SHA256)
Dim hash3 As New Encryption.Hash(Encryption.Hash.Provider.SHA384)
Dim hash4 As New Encryption.Hash(Encryption.Hash.Provider.SHA512)
Dim hash5 As New Encryption.Hash(Encryption.Hash.Provider.MD5)
Dim hash6 As New Encryption.Hash(Encryption.Hash.Provider.CRC32)
hash.Calculate(d)
hash2.Calculate(d)
hash3.Calculate(d)
hash4.Calculate(d)
hash5.Calculate(d)
Console.WriteLine("SHA1: " & hash.Value.Hex)
Console.WriteLine("SHA256: " & hash2.Value.Hex)
Console.WriteLine("SHA384: " & hash3.Value.Hex)
Console.WriteLine("SHA512: " & hash4.Value.Hex)
Console.WriteLine("MD5: " & hash5.Value.Hex)
Console.WriteLine("CRC32: " & hash6.Calculate(d).Hex)
Console.WriteLine()
Dim salt As New Encryption.Data("salty!")
Console.WriteLine("Salted CRC32: " & hash6.Calculate(d, salt).Hex)
Console.WriteLine("Press ENTER to continue...")
Console.ReadLine()
End Sub
So my questions are:
I can encrypt the password (though I have no intention of storing it) and hash a string. If I were to have a user called 'barry' with a password of 'fishlegs', what is the best way to store his password and retrieve it?
In SQL Server; is binary or nvarchar the best option for the storage of the hash?
Based on 'barry' and his password what effectively is the hash storing? Is it an encryption of 'fishlegs' appended to a salt?
Cryptography is hard!
Thanks to anyone who can assist...
Hmm, I think you're just missing some basic concepts related to how hashing works. Let me try to explain briefly. I'm going to start out simple and elaborate on my answer afterwards, so please read through the whole thing, the information at the beginning will not be secure.
What you want to use to store a password is a function known as a "one-way hash". What this means is that, for any input that you feed the function, the same input will always give the same result. However, there is no mathematical process that lets you take that result string and figure out what the original input was.
Let's take MD5 as an example of a hashing function. If I run MD5 on the string "password", I will always get the result "5f4dcc3b5aa765d61d8327deb882cf99". However, if you were to simply give someone that result string ("5f4d..."), it is impossible for them to apply some mathematical process to "reverse" the function and figure out that it came from "password".
What this means is that when a user first sets up their password, you apply a hashing function to it, and store the result. So instead of storing "password", you store "5f4dcc3b5aa765d61d8327deb882cf99". Then, when that user tries to log in, you take whatever they typed into the password box on the login form, and apply the same hashing function. If you get the same result as what's stored in the database, they must have entered the same password as they originally chose, even though you have no idea what that original password actually was.
Now, even though it's impossible to "reverse" a hash function, the fact that the same input always gives the same output means that someone can simply build up a big database of input/output pairs, and use that to effectively reverse hashes. This is called a "rainbow table". There are many of these available on the internet, so it's not safe to use simple hashing, just in case your database ever gets compromised. That is, even though it is mathematically impossible to take "5f4dcc3b5aa765d61d8327deb882cf99" and figure out that it came from running MD5 on "password", it's very easy to determine that in practice. All you have to do is run every word in a dictionary through MD5 and store the results, and you can easily reverse simple passwords.
This is where "salting" comes in. If you generate a random "salt" string for every user and attach that to their password, it effectively ruins rainbow tables. For example, let's say that the same user above registers with their password as "password". We generate a random 8-character salt to attach to their password before hashing it. Let's say that it's "A4BR82QX". Now, instead of hashing "password", we hash "A4BR82QXpassword". This gives the result "87a4ba071c8bcb5efe457e6c4e6c4490", so we store that in the database, along with the salt string. Then when this user tries to log in, instead of directly hashing and comparing the password they entered in the login form, we take what they entered, put "A4BR82QX" in front of it again, and hash that. Just as before, if it matches the stored hash, we know that they entered the right password.
Effectively what you've done here is make it so that pre-generated rainbow tables are useless for trying to crack the passwords in your database. Since the salt is random, and each user has a different one (generally), the attacker will have to re-generate their rainbow tables for every individual user. This is much more difficult.
However, there's one more problem, and that's that generating MD5 hashes is fast. Even though salting like this requires them to re-generate rainbow tables, because of how fast MD5 is, some decently-complete rainbow tables can be created very quickly. So if they just want to crack a high-value account on your site, it's not really a big deal for them to spend some time generating rainbow tables to try and reverse that password. If the high-value account's original password wasn't secure enough by itself, it'll still be found very quickly, even with salting.
So the next step is to find a slow hash function, and use this instead of a fast one like MD5. Having your site take an extra couple of seconds to check a login isn't a big deal at all. But when someone is trying to generate rainbow tables to crack a password, having each entry take several seconds is an absolute killer. I've written enough here, so I'll just finish by linking to this article, which goes into plenty of detail about picking a good, slow hashing function: Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes.
That was a pretty huge answer, if any of that's unclear, please let me know in a comment and I'll edit to elaborate.
OK so a couple of things about Jeff's class first of all. SHA1 and MD5 are deprecated now. CRC32 is not suitable at all for passwords. Secondly you should be salting every hash, preferably with a different salt value. Generally you choose a cryptographically random block of data for this, but at a push you could use the user name. To salt you prefix, or suffix the salt value somewhere in the process. I tend to hash the password, hash the salt, combine the two, then hash again. But you can swap things around it doesn't really matter that much, as long as you are consistent.
So rather than confuse things further with Jeff's class lets do this the classic way.
First off random salt generation.
public static byte[] GetRandomSalt()
{
int minSaltSize = 16;
int maxSaltSize = 32;
Random random = new Random();
int saltSize = random.Next(minSaltSize, maxSaltSize);
saltBytes = new byte[saltSize];
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
rng.GetNonZeroBytes(saltBytes);
return saltBytes;
}
Then hashing
public static byte[] ComputeHash(string plainText)
{
byte[] plainTextBytes = Encoding.UTF8.GetBytes(plainText);
HashAlgorithm hash = new SHA256Managed();
return hash.ComputeHash(plainTextWithSaltBytes);
}
So this will compute a SHA256 hash and return it as a byte array.
If you were salting you'd do something like the following
byte[] passwordHash = ComputeHash(password);
byte[] salt = GetRandomSalt();
byte[] saltHash = ComputeHash(salt);
byte[] hashWithSaltBytes = new byte[hashBytes.Length + saltBytes.Length];
for (int i=0; i < hashBytes.Length; i++)
hashWithSaltBytes[i] = hashBytes[i];
for (int i=0; i < saltBytes.Length; i++)
hashWithSaltBytes[hashBytes.Length + i] = saltBytes[i];
And then, if you're bored hash it down again, or leave as is.
To turn a byte array into a string, if you don't fancy storing bytes you can use
string hashValue = Convert.ToBase64String(hashWithSaltBytes);
String comparisons are easier than byte comparisons where you have to iterate over each array, up to you. Just remember if you are using random salts you need to store them beside the password.
Take the user password "Secret!".
Generate a random salt of a few bytes "s4L75a1T".
Concat them to "s4L75a1TSecret!".
Calculate the hash "b9797a5b683804eb195b6ba2a5e368ae74394cd3" (this is SHA-1 in hex)
Store the hash and the salt (both as hex string, Base64 string, or whatever you like) in the database together with the user name and the other user information (in the example the salt is just a plain string and the hash is Base64 encoded).
FirstName LastName Salt Hash
-----------------------------------------------------------------
John Doe s4L75a1T uXl6W2g4BOsZW2uipeNornQ5TNM=
If you want to verify the user password, just take the user name, look up the salt, do the above again and see if the calculated hash and the one in the database match. There is no (known) way to (easily) recover the password.
Don't confuse encrypting passwords with hashing them; with a good cryptographic hash function, you should not be able to reverse the hashing process to retrieve the original string.
Chad's answer above is an excellent point-by-point explanation of the concepts involved.
This subject's been done to death all over the Internet; not just on Stack Overflow; seriously - a simple web search ought to find you a pretty comprehensive guide.
Thanks, Jeff, for spreading yet another bunch of misinformation. I suppose we'll see a whole slew of misguided questions about hashing, encryption, etc. over the next week, not to mention the crap that'll come up about floating-point arithmetic.
I believe the process is like this: Generate a random salt, so 'fishlegs' + 'r4nd0mS4lt' to get 'fishlegsr4nd0mS4lt'. Then you hash that, say with MD5 (though you might want to use SHA256 to be more secure) to get: 593d5518d759b4860188158ef4c71f28. Store that and the randomly generated salt. When the user logs in, append the random salt and then check if his entered password with the salt matches the hash in the database.
What you are essentially wanting to do is:
A) On account creation, you get a username and password from the user, you hash those together with your own salt and store the resultant string in your database like:
Dim sUserName = "barry"
Dim sPassWord = "fishlegs"
Dim mySalt = "A deliciously salty string! fillED WIth all KindS of Junkk(&^&*(£"
Dim d As New Encryption.Data(mySalt + sUserName + sPassWord)
Dim hash As New Encryption.Hash(Encryption.Hash.Provider.SHA256)
hash.Calculate(d)
Dim sTheSaltedHashedUnPassCombination = hash.Value.Hex;
SavenewPasswordHashToDatabase(sTheSaltedHashedUnPassCombination)
You never store sPassWord.
B) When the user logs in you perform exactly the same operation on the provided username and password then compare the resultant hash to the previously stored value in the database so you use:
Dim sThePreviouslyCreatedHashFromTheDatabase = GetHashForUserFromDatabase(usernameProvided)
Dim mySalt = "A deliciously salty string! fillED WIth all KindS of Junkk(&^&*(£"
Dim d As New Encryption.Data(mySalt + usernameProvided+ passwordProvided)
Dim hash As New Encryption.Hash(Encryption.Hash.Provider.SHA256)
hash.Calculate(d)
Dim sTheSaltedHashedUnPassCombination = hash.Value.Hex;
if (sThePreviouslyCreatedHashFromTheDatabase.Equals(sTheSaltedHashedUnPassCombination))
'UN & Password Valid!
else
'UN & PW Invalid!
end
(Pardon any errors, VB aint my language)
To answer your given questions:
1) See above. Never store the password directly, store the hashed value
2) use a char(X), the number of characters returned from the hash is constant so you can give it a known storage size.
3) What you are effectively storing is the password for the user salted with their username and also salted with the constant on your server. This will be a fixed length string and you cannot change this string back into the separate username and password.
The whole point of hashing is that you store the hashes rather than the plaintext passwords and they can't be recovered (at least only with great difficulty). Hash functions are designed to be one-way, so that retrieval is impossible - this is their very essence.
nchar[n] is probably the best option, since common hash algorithms produce results of constant length (SHA1 outputs a 160-bit hash). Common practice is to convert the hash to Base64 so that it can be stored as ASCII text.
A salt is just a method that adds random bits onto a hash in order to complicate the process of cracking. Each extra bit of salt means that a brute-force cracker must take twice as long (and use twice as much memory).
ASP.NET includes a SQL based membership provider that allows you to create, store and verify encryped or hashed passwords, without you having to do anything - as Eric Lippert says:
let me give you all my standard caution about rolling your own cryptographic algorithms and security systems: don't.
You Want Salt With That? Part One: Security vs Obscurity
You Want Salt With That? Part Two: Security vs Obscurity
You Want Salt With That? Part Three: We Need A Hash
You Want Salt With That? Part Four: Challenge-Response