Announcement

Collapse
No announcement yet.

Password Encryption

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Password Encryption

    Hello,

    I am the current administrator of the mod_auth_mysql module on Sourceforge. This module allows Apache to authenticate access to web pages through a MySQL database.

    We've had a request to support vBulletin's password encryption. However, the way I understand it, vBulletin uses a non-standard encryption method, consisting of taking the md5 hash of the password, concatenating a salt string and taking a second md5 hash.

    This causes a problem for vBulletin users. We try to support standard encryption methods. However, there are so many non-standard ways of encrypting passwords that we just can't support them all.

    Which brings me to my questions. Why did vBulletin chose such a non-standard method, when there are numerous secure ways of doing things? And would you be willing to go to a standard method?

    Thanks,

    Jerry

  • #2
    There's an old saying for some of us geeks... "you can't out wit the attackers by security, but you can by obscurity". Attackers typically will research for means to reverse the process for the standard methods where as obscure methods are lesser researched upon (ok, so vb encryption isn't exactly obscure, but still). Additionally, personally, I do believe the double encryption with randomized salt is very secure as even by means of brute forcing with just hash alone will not allow attacker to find a 'usable' set of password for them to use on the forums.
    Best Regards,
    Andy Huang

    Comment


    • #3
      Alfarin,

      Yes, I'm familiar with the phrase - I've been programming for over 35 years :-).

      However, md5 hash is pretty secure if the password itself is long enough (i.e. at least 6-8 characters/numbers, mixed case). Or, if you want to use a salt, the Advanced Encryption Standard or even the old crypt() function are both secure and use a salt.

      I guess I just don't see the need for non-standard encryption methods. But it's no loss to me; I don't get anything from supporting this open source project. Rather, it's only the vBulletin users who lose.

      Comment


      • #4
        It isn't totally about MD5 Hashing....It's also about preventing cookie theft as well. Furthermore, using this method, no two MD5 strings are alike, regardless if the password is the same.
        ManagerJosh, Owner of 4 XenForo Licenses, 1 vBulletin Legacy License, 1 Internet Brands Suite License
        Director, WorldSims.org | Gaming Hosting Administrator, SimGames.net, Urban Online Entertainment

        Comment


        • #5
          Originally posted by ManagerJosh
          It isn't totally about MD5 Hashing....It's also about preventing cookie theft as well. Furthermore, using this method, no two MD5 strings are alike, regardless if the password is the same.
          And the problem is...? I don't think your database is open for everyone to read. And again - enforcing minimum lengths should be quite sufficent.

          Or, if you want to insist that passwords not be the same, again - use AES or crypt.

          I also don't see how a non-standard password enryption should limit cookie theft. There are any number of other ways to prevent it. For instance - you could use straight md5 for the password and then generate a cookie using your salt/second md5. Or just use AES or crypt for everything.

          But as I said - it isn't my problem. I just thought you would like to know this scheme will cause problems for your users. mod_auth_mysql is one such problem; I'm sure there will be others.

          But I won't continue this. I understand you feel this level of encryption is very important and aren't willing to change it.

          Jerry

          Comment


          • #6
            Originally posted by jstuckle
            And the problem is...? I don't think your database is open for everyone to read.
            As I understand it, the problem is that many people use the same password on every forum. When they do this, an unscrupulous webmaster can use the hash to login as these members on other forums they post at. The double-hash in vB eliminates that potential issue and adds another layer of protection to forum menbers.
            Steve Machol, former vBulletin Customer Support Manager (and NOT retired!)
            Change CKEditor Colors to Match Style (for 4.1.4 and above)

            Steve Machol Photography


            Mankind is the only creature smart enough to know its own history, and dumb enough to ignore it.


            Comment


            • #7
              It's not possible to change it, unless we added a variable password hashing system. MD5s are one way.

              vB2 had straight MD5s. vB3 added salts (prevents dictionary attacks and of course causes the same password to hash differently for each user). How do you add a salt to a md5? Well, you have to md5 it again, otherwise getting the hash gets the salt too.

              Getting the hash from the database nets you nothing, unless you want to spend the time to bruteforce it back to another md5 hash.

              Also, crypt() doesn't exist on any system that doesn't have it as a system call (eg, Windows).

              Anyway, I don't have much experience with mod_auth_mysql, but I think you could actually have a system that allows you to match against an arbitrary routine. Instead of choosing from a list of supported types (assuming that's what you do), allow the user to enter the string that compares against the database. vB's would be done with MD5(CONCAT(MD5('%s'), salt)) . That would seem to add a bunch of flexibility to me.

              Comment


              • #8
                I know I said I would not post here again, but I feel I need to respond to your posts.

                In reply to Steve:

                Not a chance. Even with MD5 encryption, the unscrupulus webmaster would not be able to log in with the encrypted password - he'd have to use an unencrypted one, unless he just happened to have the same (unencrypted) password as another user, or a dictionary attack. But again - enforcing things like minimum password length would limit such an exposure. Do you have any idea the resource it would take to do a dictionary attack on an 8 character password? Take a guess - it would be 8^62 (26 lower case, 26 upper case and 10 digits) possible values. Not something done overnight, even on a fast mainframe.

                In reply to Mike:

                It is possible to change it. You decide not to. Yes, changing to another encryption algorithm would mean members may have to re-enter their passwords. But that's been true for over 30 years - I remember having to do that on an IBM mainframe in the 70's. It's a one-time shot - not something a person has to do every time they log in.

                But that doesn't even have to occur. You could implement a new encryption method. If the user hasn't entered a password under the new method, validate it against the old method. If it works, encrypt with the new method and destroy the old encrypted password. Simple enough - it wouldn't take much programming at all.

                As for crypt()'s existance. It has been ported to Windows and MAC OS, for instance. I don't know if it exists on OS/390 - but since it's open source, I suspect it does.

                I DO have a lot of experience with mod_auth_mysql. Part of the idea of the modules is to limit the SQL programming necessary for the user. Many of our users don't know SQL, and don't need to. It does allow some extened SQL WHERE clauses.

                But the design does not allow for the construct you suggest. We take the entered password and encrypt it in our module. We then retrieve the encrypted password from the database and compare what we encrypt to that stored in the database. This mechanism is much more secure than searching the datatabase for the encrypted password . And we do not use the MySQL MD5 function to perform the encryption; rather we call a C function to do the encryption (and we call crypt() on Windows, also).

                As I said - we use standard encryption schemes. So do many other modules (i.e. pam_mysql). The fact you chose to use a non-standard mechanism means you are not compatible with the rest of the world. And I don't see the need for the rest of the world to change to suit your desires.

                It's your loss, not mine.

                Comment


                • #9
                  Originally posted by jstuckle
                  In reply to Steve:

                  Not a chance. Even with MD5 encryption, the unscrupulus webmaster would not be able to log in with the encrypted password - he'd have to use an unencrypted one, unless he just happened to have the same (unencrypted) password as another user, or a dictionary attack.
                  You misunderstood what I wrote. Wayne explains it much better here:

                  http://www.vbulletin.com/forum/showthread.php?p=543534
                  Steve Machol, former vBulletin Customer Support Manager (and NOT retired!)
                  Change CKEditor Colors to Match Style (for 4.1.4 and above)

                  Steve Machol Photography


                  Mankind is the only creature smart enough to know its own history, and dumb enough to ignore it.


                  Comment


                  • #10
                    Originally posted by Steve Machol
                    You misunderstood what I wrote. Wayne explains it much better here:

                    http://www.vbulletin.com/forum/showthread.php?p=543534
                    Steve,

                    No, I understood exactly what you said. I also read Wayne's comments, and I understand what he said.

                    I have yet to see you address any of my comments directly.

                    I can understand your position. It's more important for you to have security that is higher than that required by financial institutions, the Federal Government and other security-conscious entities. It is more important for you to have your own method rather than looking for a way to be compatible with the rest of the world.

                    However, that's OK. There are numerous other products on the market people can choose from - both commercial and open source. You're not hurting me - I don't use your product, and don't have any need for it. You're also not hurting me as the administrator of the mod_auth_mysql product, since this is not something I make any money on whatsoever (we don't even take donations).

                    What you are hurting is your users and prospective users. As I said before - this covers not only mod_auth_mysql but similar products such as pam_mysql.

                    I really don't wish to continue this discussion any further. You've made your point clear. You haven't addressed my comments. And you don't feel the need to be compatible with the rest of the world.

                    Jerry

                    Comment


                    • #11
                      Originally posted by jstuckle
                      Not a chance. Even with MD5 encryption, the unscrupulus webmaster would not be able to log in with the encrypted password - he'd have to use an unencrypted one, unless he just happened to have the same (unencrypted) password as another user, or a dictionary attack.
                      I don't understand your comment.

                      If I understand this correctly, the hashed hash is stored in the cookie. If you have a cookie on your PC, you don't need to enter the password, as you "authenticated" yourself with the cookie.
                      Now, a webmaster would have the needed hash for any of his users, and assuming that user uses the same password on another forum, he could set a cookie for himself as that user on that other forum as well.
                      Now, once salt comes in to it, this can't happen anymore. because the user, allthough he has the same password on both boards, has a different salt on each.

                      Originally posted by jstuckle
                      But again - enforcing things like minimum password length would limit such an exposure. Do you have any idea the resource it would take to do a dictionary attack on an 8 character password? Take a guess - it would be 8^62 (26 lower case, 26 upper case and 10 digits) possible values. Not something done overnight, even on a fast mainframe.
                      The way I understand it, that's not even the problem anymore. If a webmaster has the hash for the users password (without salt) he wouldn't even need to find out the password.

                      Additionally, vBulletin is used for many different types of forums, and a lot of the members using it aren't very computer literate. These are then probably the members that would be affected by a dictionary or list attack.
                      Best Regards
                      Colin Frei

                      Please don't contact me per PM.

                      Comment


                      • #12
                        Wow, I feel protected now sounds like excellent security methods!

                        Comment


                        • #13
                          This thread has run its course.

                          Comment

                          Related Topics

                          Collapse

                          Working...
                          X