0

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.

XaolingBao
  • 897
  • 2
  • 9
  • 21
  • 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 01:40
  • Your approach doesn't use salt and splitting the hash into two fields is unnecessary. See http://security.stackexchange.com/questions/51959/why-are-salted-hashes-more-secure-for-password-storage – user2320464 May 29 '16 at 01:43
  • @user2320464 I am wanting to use a salt, and my approach has a mention of salt or similar. – XaolingBao May 31 '16 at 02:29

2 Answers2

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.

Ben
  • 3,896
  • 1
  • 10
  • 22
  • 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.

Community
  • 1
Lie Ryan
  • 31,279
  • 6
  • 69
  • 93
  • 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 09: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 03 '16 at 13:57
  • @Lasagna: Salt adds entropy to the input of the hash function. Adding Salt significantly increase size of the rainbow table, the goal being that you add enough entropy such that your attacker wouldn't be able to generate/store the entire Rainbow Table. – Lie Ryan Jun 03 '16 at 14:59
  • Thanks for that, but I was speaking of it in terms of @Matthew's comments about the DB being compromised. Which brings me back to my original question. If you hashed a password and possibly salt, then split the hash in half, and then add another Salt/PEpper/w.e... to the end of each half, wouldn't that be more secure since not only is there a password + salt, but the hash was split and then added in extra data to confuse further. The claim that if the server is compromised would mean all of the data is available regardless, and if the salt is available you should be able to compute a table. – XaolingBao Jun 03 '16 at 15:03
  • 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 03 '16 at 15:20
  • Thanks @Matthew, that makes sense, So in reality, as long as we have a Strong password, and a Random salt.. we should be fine? but why then would using the same SALT be an issue? If the password is something easy, but the salt is `234lkjslkjf@#$SKkljl@W#J$@3` even if 2 passwords are the same, how would you figure out the salt, or even if you had the SALT, you would STILL have to compute a rainbow table for that salt... right? It seems like these tables are created per individual salts, or is there one massive table for all possible combos that make take into account a salt? thanks – XaolingBao Jun 03 '16 at 15:31
  • @Lasagna: if you reuse the salt, an attacker can steal the salt and then generate one rainbow table to help crack that hash+salt combination to crack most or all passwords in your database. If each password have its own salt, the attacker would have to create one rainbow table for each password. This is a much larger task, with much less return, than the previous css. – Lie Ryan Jun 03 '16 at 15:36
  • You've answered that yourself: if you have a single salt (sometimes called a pepper), two identical hashes would show you that they had the same password. If you guess either, you get the other for free. With a per-row salt, every single user might have the same password, but you could only tell by trying each one individually. – Matthew Jun 03 '16 at 15:36
  • Thanks for the help both. LieRyan but wouldn't protecting the SALT also be a good idea then? IF the DB is compromised, then it's just a matter of time before the passwords are found. @Matthew's comment is said "very few accounts are broken by rainbow tables" so is that just also adding additional layers that aren't needed? I would assume that there are other security problems than how your salt and password are hashed, i.e., SQL injection, and other bad problems? I see that I might want to look at other protection, instead of crazy DB splitting hashing stuff? :) Thanks. – XaolingBao Jun 03 '16 at 15:45
  • @Lasagna: the application need to be able to read the Salt to verify passwords. This means that the application must have a way to retrieve the Salt from wherever you store it. If you have code injection that allows the attacker to retrieve the database, chances are you'd be able to retrieve the Salt as well. The key property of properly implemented Salt is that they significantly reduce the impact of database leaks, even if they are leaked together with the database. – Lie Ryan Jun 03 '16 at 16:04
  • 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 03 '16 at 16:06
  • Thanks Lie, much appreciated. I am actually looking into "Apache Shiro" and seems to be doing everything itself, so I'm curious your thoughts on Shiro? I assume that encrypting the data in transit would protect it, but what forms of "Code injection" besides SQL injection, would I have to worry about? Thanks for all the help, much appreciated. – XaolingBao Jun 03 '16 at 16:21
  • @lieRyan I was looking at Wiki's entry on Salt https://en.wikipedia.org/wiki/Salt_(cryptography) and it mentions that Salted passwords do not make is harder for "Dictionary Attacks" to attack "Single " passwords... So isn't that still an issue if they are targeting a single account? – XaolingBao Jun 07 '16 at 10:48