Jump to content

Enhancing password protection


Wolfie

Recommended Posts

From this topic: http://community.invisionpower.com/topic/365912-nvidia-forums-attacked/

I had an idea that I thought I'd toss into the mix so that the idea is "out there" for consideration. Maybe the IPB devs can come up with something better or some great way to implement it or something.

Anyway... With sites getting hacked or exploited and thus account information being downloaded, I was thinking, what would be a great way to, at the very least, protect the original password from being determined if someone were to attempt to use brute force methods of cracking the hashed passwords. Then it came to me, something like a 'secondary password', where a user could optionally enable it. The difference between the primary and the secondary passwords would be that the secondary password wouldn't be saved. Instead, it would be part of the hashing process. If I understand the concept/use of using 'salt' for password hashing, then this would be the same thing, except that (again) it wouldn't be saved at all. So then the user wouldn't only enter a primary password, they would enter a 'key' that would be used for generating the final result to see if the right password was entered.

The idea is that even if someone uses the same 'key' and password on multiple sites, then at least the hacker would have to put in more effort to get a working combination of key + password to come up with the same resulting hash. Even then, there's a chance that it could be something different than the actual key and password, which would at least protect the true information so on other sites, if they're using the same password but not the same key (or not using a key at all), their account would be safe.

I would suggest doing what some sites do (like PayPal and Google, for example) and that is to offer to send a code to a phone that has to be entered to gain access to the account, however that would still allow someone to figure out the password. I do want to repeat, have it be user optional, so that individual members can choose to enable it as opposed to it being forced on them. Obviously there would be a third box to fill out when signing in, but for those who don't know what it's for, there could be a "What's this?" link and if someone fills it in but doesn't have it enabled, it could either be ignored or could still be used which would result in the password not matching. Either way, it would be an unknown 'salt' sort of value that a hacker would need to properly do a brute force crack.

Link to comment
Share on other sites

If you have users who want added password security in the event of a total database compromise, tell them to use longer passwords. Remember that every character added to a password increases the difficulty of brute-forcing the original pass from the hash by a factor of about 100. A sufficiently long password is effectively impossible to crack.

Link to comment
Share on other sites

Remember that every character added to a password increases the difficulty of brute-forcing the original pass from the hash by a factor of about 100. A sufficiently long password is effectively impossible to crack.


Untrue. With the technology available today, a seemingly secure password could be cracked within weeks when everything is known except the password itself. There is also the fact that, while highly unlikely to happen, it's possible that another combination of characters could produce the same end (hash) result. The idea of the extra 'code' would be to complicate the issue so that it becomes even more difficult to crash even when the hash is known. Otherwise, if it were "effectively impossible" to crack, then it wouldn't be considered an issue or a concern when those values are somehow obtained by those who shouldn't have them. There are actually sites that have a dictionary of "reverse MD5" hashes, so if you're using a password like 'password', then a Google for the hash of that (which is '5f4dcc3b5aa765d61d8327deb882cf99') will return sites that tell you the original password was 'password'.


Like this stuff?


Sort of. But more of a user chosen extra 'password' or 'code' that the user could optionally use without making use of an external service. Could be done in a way where the extra level of protection could accept new 'plugins' that the admin could choose to use, so something like the two you showed could be 'dropped in' to provide additional options. What I'm talking about is on a basic level.
Link to comment
Share on other sites

The problem with your suggestion is that it doesn't actually add any new security: You get exactly the same increase in entropy by using a 'second password' as you would if you just made your one password that much longer.

It could increase the complexity of the hashing algorithm, sure, but that's only a problem until the brute force algorithms are adjusted to take that into account.

IP.Board already uses random salts, so reverse lookups of hashes is effectively impossible.

Link to comment
Share on other sites


Untrue. With the technology available today, a seemingly secure password could be cracked within weeks when everything is known except the password itself. There is also the fact that, while highly unlikely to happen, it's possible that another combination of characters could produce the same end (hash) result. The idea of the extra 'code' would be to complicate the issue so that it becomes even more difficult to crash even when the hash is known. Otherwise, if it were "effectively impossible" to crack, then it wouldn't be considered an issue or a concern when those values are somehow obtained by those who shouldn't have them. There are actually sites that have a dictionary of "reverse MD5" hashes, so if you're using a password like 'password', then a Google for the hash of that (which is '5f4dcc3b5aa765d61d8327deb882cf99') will return sites that tell you the original password was 'password'.



What you are referring to are called "rainbow tables"—tables of hashes for common passwords (sometimes hundreds of millions of passwords, the tables can be very extensive). The point of "salting" a password is to attempt to make sure it's not on any of these tables. Most rainbow tables are simply the MD5 sum of a given password. However, if you look at Invision's password algorithm, it's actually:


md5( md5(password) . md5(salt))


This has two effects: first, if basically invalidates the use of any rainbow table because what's stored ISN'T MD5(password) it's the whole combination. Second, it doubles the effort required to brute-force the password by requiring two calculations of the md5 sum: once for the password you are testing, and once for the password plus the md5sum of the hash (which you only have to calculate once, since you know the salt). Once you are brute-forcing the password, then it is indeed true that every character added to the password increases the time required by approximately a factor of 100. Imagine the algorithm used to do this: it's basically just a loop over every possible password: you then either calculate the MD5 sum of that password (expensive) or look it up in the rainbow table (cheap), but then you have to combine it with the hashed salt and recalculate the MD5 sum (expensive, and no way to look up in the rainbow table). Yes, massively parallel architectures have sped this up: instead of taking a hundred times the life of the universe to brute force a long password, it now only takes one time the life of the universe!

Link to comment
Share on other sites

The problem with your suggestion is that it doesn't actually add any new security: You get exactly the same increase in entropy by using a 'second password' as you would if you just made your one password that much longer.



It could increase the complexity of the hashing algorithm, sure, but that's only a problem until the brute force algorithms are adjusted to take that into account.



IP.Board already uses random salts, so reverse lookups of hashes is effectively impossible.


You haven't thought it through. When a database has been compromised so that the hashed password and the salt are both available, it's simply a matter of using the brute force method with the same algorithm to break it. It's effectively the same as there being no salt at all.

With an unknown tossed into the mix, that's when it becomes "effectively impossible", because now you're not only having to do a brute force for every possible combination, but then you're having to add in the extra work of another 'password' with it. The possible combinations increases exponentially. Since there wouldn't be any form/copy of the second 'password' in the database, it would be an unknown. It would be sort of like this. A + B + C = 42. C = 11. Answer for A and B. There are infinite possibilities for what each could be and the only way to answer for one is to know the answer for the other. Let's say that the password used would normally take a brute-force method about a billion cycles before it comes across it, without the extra unknown. Okay that's a billion. Let's say that there is an unknown. For each cycle, it has to do another run of brute force efforts to see if it's found the right password + extra code combination. Even at only a billion tries on the extra code per password tried, that's (1,000,000,000 x 1,000,000,000) possibilities just for that one password.


Yes, massively parallel architectures have sped this up: instead of taking a hundred times the life of the universe to brute force a long password, it now only takes one time the life of the universe!


Not really. If it was that ineffective, then hackers wouldn't bother trying. So obviously they have ways of speeding the process up. Tossing in another unknown though, that would increase the difficulty.
Link to comment
Share on other sites

With an unknown tossed into the mix, that's when it becomes "effectively impossible", because now you're not only having to do a brute force for every possible combination, but then you're having to add in the extra work of another 'password' with it. The possible combinations increases exponentially. Since there wouldn't be any form/copy of the second 'password' in the database, it would be an unknown. It would be sort of like this. A + B + C = 42. C = 11. Answer for A and B. There are infinite possibilities for what each could be and the only way to answer for one is to know the answer for the other.



You didn't hear or didn't understand what I said. Your technique adds no entropy beyond what you would gain by just appending it to the password you already have. Your password is already unknown; adding a second one does not provide any practical benefit.

Your equation analog doesn't work, because there is no algebraic correlation between input and output with hashes. function( A + 11 ) = 42, find A. Well... we have to calculate possible inputs to the function to find the corresponding output. That's exactly what brute-forcing and rainbow tables do. function( A + B + 11 ) is exactly the same as function( A + 11 ) with A = A + B. function( function( A + 11) + B ) might be slightly slower because you run the function twice instead of once, but not enough to make the attack impossible. You still have exactly the same entropy in the system, A + B. You can never find A without simultaneously finding B, and vice versa, because of the hashing function. There's no exponential factor at play.

Cryptography is complicated. (Don't get me wrong--I won't pretend to understand it all either.)
Link to comment
Share on other sites


Not really. If it was that ineffective, then hackers wouldn't bother trying. So obviously they have ways of speeding the process up. Tossing in another unknown though, that would increase the difficulty.



Keep in mind that what I'm talking about is the effectiveness of increasing your password length: the fact is, a short password CAN be brute-forced in a relatively short period of time: and if it's a crappy short password (e.g. all lowercase letters) then it's even easier. So hackers are compromising the passwords of the subset of your members with crappy passwords: that's still valuable! But they are by no means actually cracking every single password: they throw a set of computing resources at it, and take what comes out. Maybe that's 20% of your passwords, maybe it 80%. But someone whose password is 16 characters long is not going to get compromised unless they are a high-value target and the hacker chooses to concentrate all their efforts on that one password. Increase the length to 20 characters and they won't get cracked even then. Increasing the length of your password is the single best way to decrease the possibility of its plaintext being determined in the event of a total database compromise.
Link to comment
Share on other sites

I have read articles that have explained why a password like "I like to walk the dog in the morning" is much harder to "crack" (aka it has a higher entropy) than "a.S$#@s AS".

As eGullet is explaining, it's about the number of possible variations. The more characters, the harder it is - special characters, while preventing dictionary lookups, do not really make the password more or less secure when you're talking about a lookup table of some sort. A period is just another character.

Link to comment
Share on other sites

As eGullet is explaining, it's about the number of possible variations. The more characters, the harder it is - special characters, while preventing dictionary lookups, do not really make the password more or less secure when you're talking about a lookup table of some sort. A period is just another character.


The whole point behind the request is to try to make it harder to do brute force cracking of a password. If someone has a copy of the database (or at least a copy of the members table), then they have everything they need to crack the password even if it takes them several days or longer. With technology today, a hacker could delegate out the work load to multiple computers so even a long password (say 14 characters) could be cracked in less than a month. With an unknown variable tossed in, where without it, the final hash result cannot be correctly obtained, Instead of one unknown (original password), it's two unknowns and suddenly they're having to use those same resources to brute force two 'passwords' to obtain the correct final result/hash.

Maybe the idea or execution of it as I've mentioned it isn't the best way, but if there's any benefit from the overall concept, where somehow another unknown could be introduced to make it more difficult or even pointless to crack (or try to crack), then I think it's something that would be welcome. I did say to make it optional for the user because if someone doesn't want to have to remember something extra as a password, then they wouldn't have to. But someone who wants to make sure their account is 'extra secure' could enable it and know that if the site is compromised, their password will be harder to get than those not using it. Ultimately their password could still get hacked, obviously, but it would make it more complicated, IMO.
Link to comment
Share on other sites

Doesn't IPB have already something to prevent easy cracking?
What I mean is:
Some software needs a username and a password.
I know the username, time to start my brute-forcing machine to figure out the password.
In one day or a thousand days I might succeed.

What about IPBs login system?
I need a password and an email address.
What is the email address of my target?
I have to start my brute forcing machine to give me a possible email address then start figure out the password with that one address.

The email address is wrong, cannot succeed to break in,I need another address.
How many possible email addresses are there?
Thousands,millions...

I give a rest for my excellent brute-forcing machine.

Link to comment
Share on other sites


Maybe the idea or execution of it as I've mentioned it isn't the best way, but if there's any benefit from the overall concept, where somehow another unknown could be introduced to make it more difficult or even pointless to crack (or try to crack), then I think it's something that would be welcome.



Like I said, there's nothing stopping you from just appending your two 'passwords' together, right now, no changes necessary. It would provide exactly the same benefit as two separate passwords. Probably more, actually...
Link to comment
Share on other sites

Like I said, there's nothing stopping you from just appending your two 'passwords' together, right now, no changes necessary. It would provide exactly the same benefit as two separate passwords. Probably more, actually...


Considering that you missed my very valid point about dealing with two unknowns versus one unknown, I believe you aren't seeing the extra security that would be gained by this. We'll just have to agree to disagree on this because it's a very simple concept that would making password cracking much more complex. The downside to it would be remembering the second password, although they could probably use the same one on every site without much worry.

Perhaps if you think about it from a programming point of view. You have one loop to create the first password, then for every password you attempt to use, you have a separate loop for creating a password for the password. The only way someone would know that they have one of them correct is if they have both of them correct. How many different codes (second passwords) should be tried with the main password, before deciding that the main password being tried isn't a match? Also, I never said to do something like md5( $password1 + $password2 ), it could be something like md5( md5( $password1 ) + md5( $password2 ) ) or something else where they're hashed separately. The whole concept boils down to not knowing when you have one correct without having the other correct too. Matching one, you just have one master loop and it's simple. Matching two, you have to have the same loop twice, which automatically doubles the efforts to crack it.
Link to comment
Share on other sites


Why? It was a good post. :blink:




Because I realised afterwards that it wasn't exactly what you were suggesting, but a similar thing I had thought of. :tongue:

For anyone else who was interested, my idea was to store a large, user-configurable string somewhere (by large, say 128 characters) in the config file, and use this appended to the password as part of the hashing process. In order to make passwords realistically crackable, an attacker would have to obtain data both from the database (the SQL data), and the file system (the key from the config file), which is a much more unlikely scenario than them just getting access via an SQL injection or something.

IPB could have a default value for this string, and power users could configure it (there would have to be some sort of column in the DB to dictate whether it had been applied if you were converting an existing system). It puts power users in a significantly better position in terms of password hashes and doesn't change the position of your regular users who don't bother to change it.
Link to comment
Share on other sites

Because I realised afterwards that it wasn't exactly what you were suggesting, but a similar thing I had thought of. :tongue:


Someone else had mentioned the same idea (password in conf_global file) in the other topic. If someone manages to get both, then it's somewhat pointless. However, if someone is only able to somehow obtain the database but not the conf_global file, then it would indeed create a very secure password system. In the other topic, I mentioned the idea of IPS returning a hash or something and for the script to unset the value immediately after using it. The idea being that unless someone alters the files to make a copy of that value, then it wouldn't be stored somewhere that the hacker could download or make it appear on screen, etc.
Link to comment
Share on other sites

Well I couldn't read that topic as it no longer exists or it's been moved somewhere private. :tongue:

The other option is rather than use the string to make the password hash itself stronger, is simply to use the string as the key to encrypt the hash with something like blowfish.

Link to comment
Share on other sites


With technology today, a hacker could delegate out the work load to multiple computers so even a long password (say 14 characters) could be cracked in less than a month.



First off, any password of any length can theoretically be cracked, so you are correct about that. But let's take a look at the actual numbers for a moment. There are 95 printable characters in the ASCII character set. To brute force a 14-character password, even if you KNOW that it is 14 characters, you have to check on average 0.5 * 95^14 passwords: that's 2.4e27 passwords. You can't use a conventional rainbow table because the password is salted. To check each password you have to calculate two MD5 sums. A top-of-the-line modern GPU can calculate something like 200 million hashes per second. So that's 4.8e19 seconds per password per card. That means that is will take that GPU 7.7 billion years PER PASSWORD, if you know how long the password is. The lessons here: a) always salt your passwords (Invision does this) and b) adding a single character to your password makes it 95 times harder to brute force even if the attacker knows how long it is. If they don't then they also have to check all the shorter passwords too. The upshot: if you use a long password and it's salted in the DB, it is NOT going to get brute-forced. Period.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...