0

This question already has an answer here:

I've been reading up on Password hashing, and it seems like there is a lot of opinions on "What's right."

I'm curious about the possibility of storing a split of a Hashed password in multiple user fields. Meaning hash the password first, then split, as it seems splitting a plain-text password, making it's length smaller, then hashing, will weaken security.

Lets say I have a password field, an then another field somewhere else in the table that's also hashed. When trying to see if the entered password is the same, could I take the 2 hashed values that were split, combine them, and see if that equals the entered one? Granted, I would like to hash a lot of values in my DB, so having a random "hashed value" wouldn't seem suspicious in this case.

Example

Field Password: SA234j23kljfs

Other field : 23lkj4as89dfADk

User password: SA234j23kljfs23lkj4as89dfADk

I also am curious if I could append data to the fields in order to confuse an attacker even more. I believe this would be a form of SALT?

Example

Field Password: SA234j23kljfs|dSl92slC3lD29

Other field : 23lkj4as89dfADk|298fskASDlk2sl

then split the extra data behind |

(Note that | is there just as a placeholder for this example and it would be split would some sort of logic to split correctly).

User password: SA234j23kljfs23lkj4as89dfADk

Is there anything wrong with either of these approaches? I surely feel that this would be a problem for any attacker.

EDIT: I decided to edit some details and explain better/give better examples of what I'm trying to do.

It seems that a lot of the answers had to do with splitting the plain-text, and then hashing each piece, instead of hashing everything, then splitting...

I understand why splitting then hashing is a risk, but why would splitting an already hashed password, be the same?

From what I've read, hashes aren't supposed to have any relevance to each other so "hello" and "world" hashes put together, should not be "helloworld" hashed, or is this wrong?

Thanks.

marked as duplicate by Neil Smithline, Rory Alsop May 29 '16 at 8:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I am not sure I understand your question. What problem is it that you are trying to solve? Also, you can not decrypt a hash. – Anders May 28 '16 at 23:10
  • I understand I didn't make any sense with my question. I want to split the hash, then store in multiple places, or split the plain-text, then hash each piece. If no decrypting, what is the reverse operation of the hash? Are you encrypting and decrypting the "password" then? – XaolingBao May 28 '16 at 23:29
  • Maybe I'm a little confused. I was thinking you convert the password back, to plain-text, but maybe you hash the incoming password and test that with the already stored password? Sorry for the confusion and thank you. I'll edit my question to reflect this. Sad that someone neg voted me though... – XaolingBao May 28 '16 at 23:55
  • 2
    There isn't actually that many ways to do passwords right. There's just a lot of people throwing opinions that's just totally wrong. – Lie Ryan May 29 '16 at 1:40
  • Your approach doesn't use salt and splitting the hash into two fields is unnecessary. See security.stackexchange.com/questions/51959/… – user2320464 May 29 '16 at 1:43
4

This would make the password LESS secure.

Consider a 16-character password made up of a sequence of randomly chosen letters, numbers, and symbols. By itself, this password is basically "uncrackable" for all intents and purposes, even if your password database is leaked, assuming you hash the password. You could probably even use something stupid like MD5 and be OK against most attackers. Assuming a trillion password guesses per second, it would still take millions of years to crack this one password.

But now, we apply your storage method. Assume you take the first 8 characters and hashed them in one field, then take the next 8 characters and hash them for the next field.

Now you have two 8-character passwords. Each password can be cracked individually in a few minutes to a few hours, depending on the hash you use, if your password database is ever leaked, just by trying every possible sequence of 8 characters.

Assume no help at all from the fact that the password is "hiding" in two different fields. At best, you have security through obscurity; you're relying on the fact that the attacker may not know which fields to combine together. At worst, the attacker who manages to steal your password database, will also manage to steal the website code, and will know immediately which fields to grab. A basic tenet of information security is to always assume the attacker knows how your system works, and make sure the system will remain secure despite that knowledge.

  • 1
    I want to hash the password first, then split. But also, how would they know the other hashed field has anything to do with the password?. I also mentioned adding extra data, to both fields, so that the 2 halves of the passwords aren't fully exposed. Granted I understand your point if they have access to my DB, tyhen they have access to other things that could help them get to the password if it's not protected. – XaolingBao May 29 '16 at 23:18
2

Field Password and "X" contain a part of the hashed function most likely a split of the first Y characters in the password field, and the rest in the "X" Field. Combine and check if correct.

Is there anything wrong with this approach? I surely feel that this would be a problem for any attacker.

Yes, this severely weakens the hash security. Instead of having to solve one difficult problem, now the attacker just have to solve two exponentially simpler problem.

Supposing that you only use lower case character and the attacker tries to attack this by brute force, instead of having to try every 26**16 = 4.36087429 × 10**22 possibilities , the attacker now only have to try 26**8+26**8 = 417654129152 possibilities, which is 104413532288 times weaker than just hashing the entire 16 characters in one go.

This is similar to the NTLM Hash vulnerability.

  • I want to hash the password first, then split. But also, how would they know the other hashed field has anything to do with the password?. I also mentioned adding extra data, to both fields, so that the 2 halves of the passwords aren't fully exposed. – XaolingBao May 29 '16 at 23:19
  • 2
    Think about it this way: your code needs to be able to read and verify the whole password. Therefore, it must be able to access the full thing. If your code can access the full password hash, an attacker with database access can access it too - it doesn't matter how the hash is stored internally. – Matthew May 31 '16 at 9:18
  • Why does DB access mean they know my Application Logic? They might have SQL injected it, or hacked into my site, but that doesn't mean the Application code is open to the users. I understand your comments, but if that's the case what's the point of a Salt, since they would have DB access, and see the salt, or even know the hashing algorithm, so they can compute a Rainbow Table and just crack everything? Also, as I mentioned, splitting after hashing would be different than what the others are talking about, splitting before... right? Thanks for the help, I appreciate it. – XaolingBao Jun 3 '16 at 13:57
  • 1
    @Lasagna Modern hashing algorithms are designed to be slow - they make it impractical to pre-calculate values, and incorporate salt automatically. Your scheme just drastically increases the storage space required, without a corresponding improvement in security. Very few accounts are broken by rainbow tables. They aren't needed - users just tend to use weak passwords, and it's easy to try them through your application with a rented botnet. In that case, you do all the checks for an attacker, through your application logic. In that case, you increase load on your system, for no actual gain – Matthew Jun 3 '16 at 15:20
  • 1
    @Lasagna: the reason why few attacks actually depend on Rainbow Table is exactly due to the use of proper Salt. Adding proper Salt makes creating Rainbow Table not worthwhile. There are lots of web framework, authentication libraries that uses Salt properly preventing these attacks. I suggest you look into implementing your authentication based on those rather than trying to implement yourself. – Lie Ryan Jun 3 '16 at 16:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.