I am not familiar with windows password scheme but it would be crazy if windows just relied on the hash. Few *nix machines that I deal with have 128 bit salt + password.
Even wifi-wpa, blackberry and iphones are doing password strengthening to make brute force method more challenging.
As most of us are familiar with, most vulnerable part of the security is us human beings picking the passwords. Underneath algorithms(hashing) are pretty well devised and solid when used properly.
If the salt is short (username, email address, phone number, user id, etc.) then this becomes much more of a serious attack, specifically if the salt+password combination is less than 14 characters.
What difference does it make? With a different salt for each password, that info is going to have to be stored in the database anyway, so does it matter much if its a random string or a piece of user info? They still have to precompute tables for each possible salt, unless you're using email as the salt and all your users happen to have the same email address.
Storing the dynamic salt in the same database together with the user's password hash still doesn't tell you HOW the salt is applied or HOW the product has been digested. This requires insight into the login procedure of the application, and this is where the strength of the salt lies. Adding on this security can be done by storing users' salts somewhere else instead of keeping them in the same table and db as the hashes.
My personal method is to work with two salts; one static half (just for the added entropy) kept with the login code, and one dynamic half (always random - not computed from user input) kept in a separate database, away from the hashes. This forces the attacker to acquire not just the database with the hashes, but also the database with the salts, AND the application's login code, in order to get anywhere.
This is silly. The purpose of a salt (what real cryptographers call a nonce) is simply to make it infeasible to precompute tables. Store it in the open, in the most convenient place possible; don't jump through hoops so you can pretend you're getting more security than you are.
If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.
Hmm... not quite. The word "salt" is always used in the context of KDFs. I'm not entirely certain how I'd define the difference between a salt and a nonce, but they feel like subtly different concepts to me.
If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.
Well, to be fair, scrypt, bcrypt, and PBKDF2 all use salts too. :-)
I am not familiar with windows password scheme but it would be crazy if windows just relied on the hash. Few *nix machines that I deal with have 128 bit salt + password.
Even wifi-wpa, blackberry and iphones are doing password strengthening to make brute force method more challenging.
As most of us are familiar with, most vulnerable part of the security is us human beings picking the passwords. Underneath algorithms(hashing) are pretty well devised and solid when used properly.