Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Hashing Functions

  1. #1
    Member
    Join Date
    May 2008
    Posts
    34

    Cool 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.

  2. #2
    Senior Member
    Join Date
    Oct 2003
    Location
    MA
    Posts
    1,052
    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.

  3. #3
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    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.

  4. #4
    Member
    Join Date
    May 2008
    Posts
    34
    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.

  5. #5
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    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.

  6. #6
    Member
    Join Date
    May 2008
    Posts
    34
    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.

  7. #7
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    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.

  8. #8
    Member
    Join Date
    May 2008
    Posts
    34
    €1234<"My Password">ABCD$
    Thank you. I particularly like this method. I will most likely initiate my own "version" of this. =)

  9. #9
    Member
    Join Date
    May 2008
    Posts
    34
    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.

  10. #10
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    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

  1. ZWinCrypt - Simple C++ Library for Hashing, Encryption and Compression
    By encipher in forum Cryptography, Steganography, etc.
    Replies: 0
    Last Post: April 11th, 2007, 02:25 AM
  2. OS Types and Functions!
    By Black Cluster in forum Other Tutorials Forum
    Replies: 4
    Last Post: April 24th, 2005, 07:28 PM
  3. General math functions header
    By Kamikaze Badger in forum Code Review
    Replies: 4
    Last Post: March 30th, 2005, 01:55 PM
  4. Question about functions in C++
    By Kamikaze Badger in forum General Programming Questions
    Replies: 2
    Last Post: October 28th, 2004, 12:50 AM
  5. Useful JavaScript functions
    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
  •