-
May 22nd, 2008, 05:03 PM
#1
Hashing Functions
A debate has come up recently and I was wondering what others thought about it. The debate is about whether or not it increases security to add content to user input. Here's the two scenarios:
1.
- A user registers a password.
- The password is hashed.
- The hash is stored in the database, along with the username.
- When comparing passwords to user input later, the user inputs a password.
- The password is hashed.
- The new hash is then compared against the hash stored in the database to determine if the user authenticates.
OR
2.
- A user registers a password.
- The date and time is stored in the database.
- That date and time that is stored is then added to the input.
- A hash is created from the combination of the input and the stored date and time.
- The hash is stored in the database, along with the username.
- Later, a user enters input.
- The input is then paired with the date and time that is found by searching for the username.
- The input and date / time combination is then hashed.
- The new hash is then compared to the hash stored in the database.
My argument is that adding content to the user's input before hashing it will prevent dictionary attacks, (especially if the date/time fields are stored in a separate table in a separate database.)
What are your thoughts?
Last edited by itPro; May 22nd, 2008 at 05:06 PM.
-
May 22nd, 2008, 05:46 PM
#2
You are basically talking about salting. Yes it is a good idea but it doesnt have to be that complicated.
Md5($userspass . "8fjSDJF99aFkkSDffffL9@fkFD9");
If something like that was used even if the users password was "a" then it would be a plus all that garbage making it almost impossible to crack if someone obtained the md5 hash of the users password.
-
May 22nd, 2008, 06:14 PM
#3
Strictly speaking I don't think that you are "adding content", you are just using a different methodology?
It is generally fairly trivial to find a user name and in the first scenario it is even stored in the same file. It should be reasonably possible to reverse engineer?
I am not sure how realistic it is to assume that someone can access the password/user file and not any other file such as the date/time/user one?
The thing about user names is that organisations tend to use a standard format which should be pretty easy to deduce if you know it. So, if you use the user name it wouldn't really matter if you stored them in a separate file.
Assuming that the date/time/user file is secure then this would be more secure. OK you have a fixed number of 12 characters but there is the added complication of the cracker having to know what format it is stored in, even if they know how it is being done? Also deducing the date and time of creation would be difficult?
I don't think that either method is particularly susceptible to a "dictionary" attack. I would have thought that brute force would be the way to go, particularly if you enforce a sensible password policy.
Last edited by nihil; May 22nd, 2008 at 07:27 PM.
-
May 22nd, 2008, 07:35 PM
#4
Strictly speaking I don't think that you are "adding content", you are just using a different methodology?
This is just semantics. lol
It is generally fairly trivial to find a user name and in the first scenario it is even stored in the same file. It should be reasonably easy to reverse engineer?
I think you're missing the entire point. There are two fields stored in the same record, and they are date and time. There is nothing anywhere in the database stating that the date and time are used in creating the hash, (other than the C# code-behind, Windows Application C# files, or your method of choice). For all the casual database table-reader knows, this is just a stamp on when the login was created. If the attacker was a little brighter than the average Joe, who says that the date and time are paired with the input in exactly the order that I stated? Who says that they can't be hashed first before being added, added in reverse order, or any other possibility that could have astronomical odds of guessing, all while remaining a unique final hash?
The odds of reversing such a hash are even more astronomical than the odds of guessing the proper method of putting together the string that is used to create the hash, (since you have to know what is being used to create the hash in order to know whether or not you have successfully reversed the hash.) If you really want to get over-the-top complex, throw in the OS SID, the MAC address, and any other unique identifier that you would want to add before the hashing takes place.
I am not sure how realistic it is to assume that someone can access the password/user file and not any other file such as the date/time/user one?
It is not really a question of access to the local machine, as they would have to get that far in order to be a real threat anyway. Moving the data simply makes things a little more complicated for the attacker. (That's really the point to security anyway. If you add enough obstacles, the work involved with reaching the prize costs more than the prize itself.)
The thing about user names is that organisations tend to use a standard format which should be pretty easy to deduce if you know it. So, if you use the user name it wouldn't really matter if you stored them in a separate file.
The username would only be an indicator of which fields would be added to the input, (or used to find the other additions to the input perhaps).
Assuming that the date/time/user file is secure then this would be more secure. OK you have a fixed number of 12 characters but there is the added complication of the cracker having to know what format it is stored in, even if they know how it is being done?
I'm not sure what you're referring to here. What is 12 characters?
I don't think that either method is particularly susceptible to a "dictionary" attack. I would have thought that brute force would be the way to go, particularly if you enforce a sensible password policy.
That's just the thing. If you use either of these methods, you don't have to enforce a password policy. This eliminates the need to rely on users to be IT-saavy enough to use complex passwords, as well as the necessity for forcing them to use a randomly-generated complex password. They can use the word "cat" for a password, and it can be converted into a password that is no longer weak. This will not fix the "weakness" in the sense that an attacker could not auto-generate attempts into the interface directly and find it quickly through brute-force, but this would make it much tougher on the database side, if access was achieved directly. The trick then is to prevent an attacker from using the interface itself in a brute force attack.
Last edited by itPro; May 22nd, 2008 at 07:42 PM.
-
May 22nd, 2008, 07:58 PM
#5
If an attacker can only attack this scheme through the login prompt, the setup you propose doesn't add anything security-wise, as the software automatically appends the date/time to the input before hashing it. In that case, there is absolutely no difference between the two alternatives you propose.
-
May 22nd, 2008, 08:18 PM
#6
That's true. Didn't I just say that?
If an attacker uses other methods, such as accessing the database directly and discovering all of the hashed passwords, then this added security makes a huge difference, for the reasons that I described above.
-
May 22nd, 2008, 08:46 PM
#7
Hi,
I think that you misread me. I was saying that the first method is not particularly secure and is also quite common, so an attacker might be expected to try it.
I think you're missing the entire point. There are two fields stored in the same record, and they are date and time. There is nothing anywhere in the database stating that the date and time are used in creating the hash, (other than the C# code-behind, Windows Application C# files, or your method of choice). For all the casual database table-reader knows, this is just a stamp on when the login was created. If the attacker was a little brighter than the average Joe, who says that the date and time are paired with the input in exactly the order that I stated? Who says that they can't be hashed first before being added, added in reverse order, or any other possibility that could have astronomical odds of guessing, all while remaining a unique final hash?
The odds of reversing such a hash are even more astronomical than the odds of guessing the proper method of putting together the string that is used to create the hash, (since you have to know what is being used to create the hash in order to know whether or not you have successfully reversed the hash.) If you really want to get over-the-top complex, throw in the OS SID, the MAC address, and any other unique identifier that you would want to add before the hashing takes place.
That is what I meant by saying that the second method was more secure because the attacker would have to know the format, even if they knew that you were using a date/timestamp.
I'm not sure what you're referring to here. What is 12 characters?
Ah! that is why you didn't see my point, it is the date/time such as:
DD/MM/YY and HH/MM/SS which would give you 12 characters excluding the separators. Like I said:
but there is the added complication of the cracker having to know what format it is stored in
Given the variety of possible formats, including the month in words, this vastly increases the number of combinations that would have to be tried.
That brings me to oofki's suggestion. Use salting. This adds a random string to the data before it is hashed, thus ensuring that they are all unique and virtually uncrackable within a reasonable time and resource framework. Because it is random and unique it is far more secure. User passwords and date/timestamps are not neccessarily unique. You can enforce unique user IDs however so to ensure that your system was unique you would need to use their ID as well.
That's just the thing. If you use either of these methods, you don't have to enforce a password policy.
I wouldn't recommend that. I doubt if you would get it past a security audit.
This eliminates the need to rely on users to be IT-saavy enough to use complex passwords
There are plenty of software solutions that will force them to do it.
I normally suggest that they use their own "packing" and don't tell anyone what it is. For example:
€1234<"My Password">ABCD$
That's a 25 character complex password that you won't forget. When you want to change it just change the "My Password" bit.
-
May 22nd, 2008, 09:10 PM
#8
€1234<"My Password">ABCD$
Thank you. I particularly like this method. I will most likely initiate my own "version" of this. =)
-
May 23rd, 2008, 08:21 PM
#9
That brings me to oofki's suggestion. Use salting. This adds a random string to the data before it is hashed, thus ensuring that they are all unique and virtually uncrackable within a reasonable time and resource framework. Because it is random and unique it is far more secure. User passwords and date/timestamps are not neccessarily unique. You can enforce unique user IDs however so to ensure that your system was unique you would need to use their ID as well.
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, with the fault of using duplicates. That is actually why using a date/time stamp is better, since it will ALWAYS be unique, which, in-turn, protects data integrity. Having a set structure is more professional and accurate, whereas random will at some point break the system. 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.
Last edited by itPro; May 23rd, 2008 at 08:47 PM.
-
May 23rd, 2008, 09:27 PM
#10
My issue with the scheme has always been that the only case where it adds security is when your hashes are vulnerable (i.e. when the attacker has access to the hash - the salting, then, indeed adds an extra layer of security). In that case, though, you have other problems to worry about
If the attacker does not have access to the hash, the scheme does not add security.
Similar Threads
-
By encipher in forum Cryptography, Steganography, etc.
Replies: 0
Last Post: April 11th, 2007, 02:25 AM
-
By Black Cluster in forum Other Tutorials Forum
Replies: 4
Last Post: April 24th, 2005, 07:28 PM
-
By Kamikaze Badger in forum Code Review
Replies: 4
Last Post: March 30th, 2005, 01:55 PM
-
By Kamikaze Badger in forum General Programming Questions
Replies: 2
Last Post: October 28th, 2004, 12:50 AM
-
By jethro in forum Other Tutorials Forum
Replies: 0
Last Post: July 11th, 2002, 06:49 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|