Why use password salt?

[xyph]

What are your (both xyph and Dan) thoughts about using a timestamp as a salt?  It has the following benefits:

 

Always unique per user.

Fairly randomized on its own.

Fairly long.

Difficult to guess as it can look like benign user profile data (it doesn't need to be labeled as a dedicated salt column, although obfuscation is admittedly a weak benefit).

 

Keep in mind, I'm not a security expert. The topic interests me greatly, but I don't have the experience nor a math background specific to cryptography.

 

Always unique per user - Not always. Even using microtime(), it's possible to get duplicates. Even then, unless the users are using the same password, and in the case of key stretching, are given the same iteration count, a unique hash will be made. A random salt with lots of entropy is more important than a truly unique salt.

Fairly randomized on its own - It's not random at all

Fairly long - Disagree here - Even if it's 50 characters long, it's still limited to 10 possible values per character.

Difficult to guess - Compared to pseudo-random bits, it's trivial. You can store any salt beside a hash in a single column, assuming you know the length of either the hash or the salt.

 

To summarize, I'd much prefer to use a pseudo-random string of bits. This is much more difficult to predict than a purely time based solution, and adds much more entropy per bit used. Please let me know if anything seems off here.

[xyph]

If a hacker gets both the database and the logic then all bets are off. They can, with sufficient time and resources brute force any of the hashes. Which is why string-lengthening is important.

 

This is where I disagree. Obscuring the logic won't make your passwords any more secure. Most widely-accepted security implementations are successful because they are well tested and open. They more eyes looking at something, the more mistakes are found.

 

A good security measure should be known to everyone, and rely on a form of unpredictability and a secret key known only to the person accessing it.

 

Even if the attacker knows how the salt is applied, they are limited to attacking a single hash at a time. If you slow down this procedure and there is enough entropy in the source password (this is where a good password policy is important), even attacking a single hash will take extreme amounts of time. If the information is important enough, your user will have been forced to change their password long before it's been brute forced.

[Matt Ridge]

 

We use one-way algorithms because they are just that. One way. They don't get 'reversed,' they get brute forced. SHA and MD5 are bad not because they can be 'cracked' (incorrect terminology aside), but because they were built for speed. When the only way to attack your hash is through brute force, speed is your enemy. We use salts to prevent simple passwords from being brute forced nearly instantly. We use random salts to prevent an attacker from being able to apply a single brute force attack to every hash.

 

I'm done with this thread though. You seem have already come to conclusions on subjects you know very little about. That's not the type of person I enjoy helping. Best of luck

 

Ok, I understand a little better, but I have a question, even if you are done with this topic I'm not because I'm trying to learn...

 

When you say random salts, do you or the program dictate where those fields are salted?

 

Also, I am going through past experience when it comes to attacks on servers, not individual web pages/domains, so I do have experience with brute force attacks, and other forms, just on server side, not individual programmed web pages, which although they seem similar they aren't. 

 

When dealing with servers you are only as strong as the software you work with, unless you design it yourself. Even then there are foundations to work off of, firewalls,  ROSKO lists, and other aspects that I am sure you know about.

 

Web pages are an entirely different beast. One line of code can dictate safety, or destruction, and they seem a lot more prone to vulnerabilities than servers as a whole. 

 

I am going on the premise that hackers attacking server use the same forms of attacks when going by web pages.  I was taught when making passwords for servers to not use words that are common dictionary words, or can be researched such as pet names, family members, birth or death dates, etc. 

 

When I saw people saying salting dictionary passwords it set up an alarm in my head, and I asked about utilizing things such as what people here consider leet languages to break up common words and/or dates so that itself would be harder to figure out. 

 

Then I was told I didn't know what I was talking about because I didn't read a document.

 

You know what I read the document, as you pointed out it is more advanced than what I am ready for, but I am asking questions because when I am ready to learn and understand it I will have a general foundation upon what I am looking at instead of going in blindly. I'll be able to say, "That is what they mean"... Because honestly I don't know what I am going to be using when the time comes.

 

I would rather ask questions here and have tech babble to me now explained in plain English because if I can't understand the document, I am sure other people here can't... perhaps it is time to create a post explaining in plain English what salt is, how it works, and why it is so hard to hack instead of saying "read this document"...

 

I don't know, but I have more questions but I'll ask them later.

 

[xyph]

You seem to be lost as to what PHP does. PHP runs on a server, ideally. An attack on a PHP script IS an attack on a server. Any other attack is simply an attack through another application running on that server. Again, you really need to have a deep understanding of how the internet works, and the protocols it uses before you can even touch the surface of security relating to it.

 

You really don't know what you're talking about. While a strong password policy is important, it's only part of implementing a secure system. A well salted password out of a dictionary could be harder to brute force than an unsalted, complex password.

 

If you aren't ready to learn and understand it, you aren't ready to build a foundation on it. You're better off going in blind, with good knowledge of the underlying protocols. In security, the last thing you want in your head is limitations, expectations or predispositions. For all I know, the best practices might change completely when you are ready to learn it, making anything you've been told up till then a waste of time.

 

Google will show you plenty of documents pertaining to what a salt exactly is. It doesn't need to be spoon-fed to people, though it pretty much already is. If you have issues understanding exactly what a salt is after reading the article, you shouldn't worry about it. You need to implement the class in the article, and be comfortable that a community and several extremely large projects have backed it.

 

That article is about as plain-English as it can get. It's impossible to explain how an attack on a certain protocol will work if that person doesn't understand the protocol in the first place. This isn't a topic that someone can pick up in a couple months, or a newbie can grasp without a deep knowledge of the underlying technology first.