Jump to content


Photo
- - - - -

Enhancing password protection


  • Please log in to reply
30 replies to this topic

#1 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 13 July 2012 - 02:59 PM

From this topic: http://community.inv...orums-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.
  • screamingiraffe and BIGGGMIKE like this

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#2 Rimi

Rimi

    Strip Me

  • +Clients
  • 6,084 posts

Posted 13 July 2012 - 03:13 PM

Like this stuff?

http://community.inv...authentication/
http://community.inv...authentication/

#3 eGullet

eGullet

    IPB Full Member

  • +Clients
  • 181 posts

Posted 13 July 2012 - 06:22 PM

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.
eG Forums, a service of the Society for Culinary Arts & Letters.
Running Invision Power Board since 2002

#4 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 13 July 2012 - 07:14 PM

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.

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#5 screamingiraffe

screamingiraffe

    IPB Newbie

  • +Clients
  • 9 posts

Posted 13 July 2012 - 10:55 PM

I've been using IPB for a few years, well I had it installed, but it's been idle, just never had the time to 'use' it, but each install has been hacked within a few months. Just tonight I had to do a complete wipe and re-install, this is the 3rd time.

#6 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,954 posts

Posted 14 July 2012 - 09:26 AM

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.

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#7 eGullet

eGullet

    IPB Full Member

  • +Clients
  • 181 posts

Posted 14 July 2012 - 01:48 PM

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!
eG Forums, a service of the Society for Culinary Arts & Letters.
Running Invision Power Board since 2002

#8 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 14 July 2012 - 02:03 PM

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.

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#9 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,954 posts

Posted 14 July 2012 - 02:19 PM

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.)
  • TaffyCaffy likes this

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#10 eGullet

eGullet

    IPB Full Member

  • +Clients
  • 181 posts

Posted 14 July 2012 - 02:40 PM

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.
  • TaffyCaffy likes this
eG Forums, a service of the Society for Culinary Arts & Letters.
Running Invision Power Board since 2002

#11 bfarber

bfarber

    RBT-KS

  • IPS Management
  • 28,416 posts

Posted 16 July 2012 - 09:03 AM

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.
  • Zizzla_JA likes this

Brandon Farber
Development Manager / Senior Support

If it sounds like fun, it's not allowed on the bus!

php5_zce_logo_new.gif     

Invision Power Services, Inc.


#12 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 16 July 2012 - 04:24 PM

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.

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#13 Misi

Misi

    Spam is good!

  • +Clients
  • 682 posts

Posted 16 July 2012 - 05:05 PM

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.
This signature is not a signature!

#14 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,954 posts

Posted 16 July 2012 - 05:28 PM

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

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#15 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 16 July 2012 - 06:43 PM

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.

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#16 Misi

Misi

    Spam is good!

  • +Clients
  • 682 posts

Posted 16 July 2012 - 07:30 PM

Probably more, actually...

More, at least 10 times,provided the passwords are constructed only from the ten digits.
Using other characters, "10 times" is increasing.
This signature is not a signature!

#17 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,954 posts

Posted 16 July 2012 - 07:34 PM

Wolfie, you are impenetrable. :smile:

You're sort of right, but for the wrong reason. I've run out of care, so we'll just leave it with that.

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#18 PeterUK

PeterUK

    IPB Full Member

  • +Clients
  • 181 posts

Posted 19 July 2012 - 07:20 PM

EDIT: Scratch this.

#19 Wolfie

Wolfie

    Don't get mad, get N*Raged!

  • +Clients
  • 12,484 posts

Posted 19 July 2012 - 08:41 PM

EDIT: Scratch this.

Why? It was a good post. :blink:

٩(͡๏̯͡๏)۶ Click here to browse or purchase IPS software. ٩(͡๏̯͡๏)۶
n-raged.com
- Dacity.Com

♪ Me and you ♪
♪ a two-man crew ♪
♪ side by side we're unified ♪
♪ and we will never be divided ♪

Spoiler

CLICK HERE AND VOTE IP.BOARD AS BEST FORUM SOFTWARE FOR 2013!!!


#20 Misi

Misi

    Spam is good!

  • +Clients
  • 682 posts

Posted 19 July 2012 - 09:15 PM

EDIT: Scratch this.



Posted Image
This signature is not a signature!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users