Hashing Functions

Would you really assume that no one would ever be able access the database and just put the data in the database as clear text? Why use a hash at all, if this is your logic? You just said that, "If the attacker does not have access to the hash, the scheme does not add security.", so why implement a hashing system at all? An attacker does not have access to the data, until the attack occurs. The security factor is meant to be preventative, so why wouldn't you implement these security features before an attacker does gain access? Why would you say that it is useless to add it? I'm a bit confused on why you are saying that it doesn't make things more secure. That's like saying that using a retinal scan for authentication does not add security, if no one ever comes into the building. Isn't the entire point of using a hashing function to prevent a user that gains access to the data from being able to decipher what it really is? Even if the entire machine is compromised, it would be a good idea if the attackers couldn't figure out what the classified data was, correct?

itPro, please forgive me as it is almost 40 years since I studied this stuff at university.

Quote:

---

I was reading back over the thread just in case I missed anything, and I noticed something. If something is truly random, then it is not guaranteed to be unique. As well as any programmer knows "random", it is following a pattern

---

Your first comment would depend on whether the selection was "with replacement" or not wouldn't it. You know, a bit like a lottery?

Yes "random" follows a pattern, and I suppose that there is the possibility of "collisions", depending on the quality of the algorithm used.

Quote:

---

That is actually why using a date/time stamp is better, since it will ALWAYS be unique

---

I don't think so, because the date and time are the same for everyone in the same time zone at any given point in time? That is why I suggested combining you two methods to ensure uniqueness.

Quote:

---

The security factor is meant to be preventative, so why wouldn't you implement these security features before an attacker does gain access?

---

Quite! why make it easy for them? Also you musn't forget the potential for "the enemy within", employees have some sort of access and they can get in through the door (past the primary physical security)?

Quote:

---

As you said, it will not, if you enforce unique usernames, but that might prove harder to do in a larger company, and certainly more of a pain for the users themselves.

---

Hey, I have worked in the finance and defence sectors most of my life and for outfits with maybe 250,000 employees or more.

1. It is ridiculously easy........... hell, I could do it on a PI with Win 3.11 and Office 4.3 I know, because I have ;)

2. Why is it a pain?.............. like you chose your own name when you were born? Hell, when you join a big outfit you are given an employee number........... you need it to claim your expenses............never met any bastard who forgot it yet :D

I started work in late '72 and to this very day I have never heard of anyone forgetting their user ID............ passwords....... yeah loads of times, but user ID? never!

I also agree with Negative when he says:

Quote:

---

If the attacker does not have access to the hash, the scheme does not add security.

---

That is very true, and I commented earlier in this thread that if an attacker had access to the hash they would probably have access to much more. It sort of depends on whether you are looking at a local or remote attack?

To support Neg~, all my home PCs that need a password have it taped to the top.................. If someone accesses that, they have broken into my home? (I trust my wife and cats :D)

Most of them are x86, PI, PII, PIII, P4, Athlon XP boxes that I was given or purchased for minimal amounts, so I don't think that they are really worth stealing............... actually, three of them were even delivered to my house by the refuse disposal guys (trash throwers). I am old and poor so the guys deliver as well as collect :lildevil:

The point is, that I never keep any confidential information on them. It may be private, but not confidential. Anyway, most are just experimental boxes that I re-image, so only the CD is something to secure?

itPro, I think that we need to look at what I will loosely describe as the "security cycle"?

1. Risk Analysis
2. Security Model
3. User Authorisation Policy
4. Identification of Processes and Procedures Required
5. Implementation and Enforcement of Determined Model & Policy using defined processes and supporting procedures

For that, I think that we need to bring in the "environment" variable?

Quote:

---

Your first comment would depend on whether the selection was "with replacement" or not wouldn't it. You know, a bit like a lottery?

---

Truly random strings are only random if there is the possibility of them being chosen again. In order to secure a random placement, you would have to keep track of it and prevent it from being chosen a second time.

Quote:

---

I don't think so, because the date and time are the same for everyone in the same time zone at any given point in time? That is why I suggested combining you two methods to ensure uniqueness.

---

I'm fairly certain that the exact ticks are included with a date/time stamp, if you choose to format it that way. You're not going to get duplicates if you're using ticks and you prevent duplicates from occurring programmatically. The odds of two users trying to register at a website on the exact same tick is a definitely long shot. Besides, when you are writing data to a database table, you should make sure that the process writing the data should place a write lock on it so that no other process can read or write to that table, until the lock is released. You could easily set this writing process up to last at least one tick. http://msdn.microsoft.com/en-us/libr...ime.ticks.aspx

As for the unique usernames, I was actually thinking back to you stating that it would be a good idea to force them to use complex passwords. While that is optimum security, I personally know some CEOs that have flat refused to use anything besides their personal weak password that they used for everything... Using their names is a good idea, as that will often be unique, but you will definitely run into instances where the usernames are exactly the same. There really is not much of a point to having a unique username anyway. The security is provided through the hashing process of the password, or at least it is in the context we've been discussing so far.

As for thinking you are safe in the privacy of your own home, you either have other safeguards in place, or ... Well I'm just going to assume that you do. You joke about trusting your wife and cats, but the real threat are those that are close enough to your wireless to jump on, and any ports that are open on your local network.

I would have to completely disagree with the environment having anything to do with information security. Whether your server is in your own home or if it is in a bank guarded by the police, you still have to protect your information. (The level of protection is actually decided by the value of the information, rather than the environment that the information is in.) You might trust your wife and cats, but do you think that's going to prevent Joe Hacker from accessing your database and reading the clear text, if you don't have safeguards up to prevent him from doing so? You should never be so naive as to think you are safe just because you are at home, unless you have implemented some security practices.

Besides this isn't really a question of whether or not a hashing function should be used in some instances. The debate, as stated at the beginning, is whether or not the more complex method of creating the hash adds any security at all. It appears as though a couple people already agree with me that it does, although there is possibly a debate going on now of how exactly to best implement that functionality. Nevertheless, it appears as if I was correct in saying that such a method does indeed make the data more secure by implementing such a system.

My main objections are these:
- I think we all agree that the scheme does not add any security whatsoever when the attacker does not have access to the hash.
- The security of your scheme relies on keeping the salting process secret. If the attacker has access to your hashes, though, it's not that far-fetched to assume that he'd have access to your salting as well (i.e. that he can find out what you're doing).

In short, you're wrong. It does add more security, no matter what aspect of the system you are looking at. This scheme is geared toward preventing a user from knowing what the password list is, should an attacker gain access to the database. (Surely you've heard of SQL Injection and other database attacks?) To say that preventing this does not add any security is completely inaccurate. Actually, any additional step to make it harder for an attacker to gain access to your data IS security. You can't deny that. Security comes in layers, and not all of the layers are geared toward the same idea. (Thinking out of the box is what puts security professionals ahead of the crackers.)

As for keeping the salting process secret, you're right. Even if they knew how it worked, however, it would still be a ridiculous process to break the hash. They would still be missing the user's password, and the string would be a good deal larger. It would be at least a 104-bit key, and that's if a client used a one-character password. Encryption is what, 128-bits at a minimum? I think you can see that I'm now putting you in a position that you would have to say encryption doesn't add security in order for you to say that my scheme does not add any security. (In fact, if you replace my scheme with implementing encryption instead, you could still say that encryption doesn't add any security, unless you keep one of the keys private. Are you sure you want to say that? lol) I can see, however, that they would only need the user's part of the key in order to have a complete key, but the process would still require the added part of the key in order to break it.

Now tell me what security professional would make it easy for an attacker to discover how the process works. In fact, tell me how a custom hash function is not more secure than a normal hashing function that everyone already understands and has documentation. Are you really sure that you want to ground your logic on the idea that known procedures are better than known procedures with an secret twist? I'm making things more complicated, and that's what it takes when you want to be ahead of the attacker.

You could say the same things in your above post about using a hash at all. The equivalent is to say that you might as well not put in usernames and passwords into a bank network system, since the robbers could just force the employees to put them in. That's basically giving up since there is the possibility that it will not prevent them from accessing their objective.

Hey itPro,

I guess it is time to introduce CYA into the discussion?

Like you Cover Your A$$..... :D