Basic cyber security says that passwords should be encrypted and hashed, so that even the company storing them doesn’t know what the password is. (When you log in, the site performs the same encrypting and hashing steps and compares the results) Otherwise if they are hacked, the attackers get access to all the passwords.

I’ve noticed a few companies ask for specific characters of my password to prove who I am (eg enter the 2nd and 9th character)

Is there any secure way that this could be happening? Or are the companies storing my password in plain text?

  • blueday@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    They could hash pairs of characters on password creation and store those. Seems like more data points to guess the original password, but maybe the math is hard enough it doesn’t do much.

    • floofloof@lemmy.ca
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      If it’s uniquely salted (and especially if they use a secret pepper too) it might not help with guessing the password, because now you have to crack several hashes of long random sequences of bytes instead of just one.

      • r00ty@kbin.life
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        1 year ago

        I’m finding it hard to see how it would be more secure. If I understand what the other comment meant, they would have something like:

        password123 = ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

        We’ll assume they pick 4 random pairs

        3rd + 5th (sw) = 7865b7e6b9d241d744d330eec3b3a0fe4f9d36af75d96291638504680f805bfd
        9th + 11th (13) = 3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278
        2nd + 5th (aw) = f5fe88ee08735ae259265495a93c8de2b0eacfecf0cd90b5821479be3199fa8c
        6th + 8th (od) = 32f30ea0e83c41a331c4330213005568675f7542c25f354ebb634db78cc30d12
        
        

        Assuming all 128 7bit character options are used and ignoring dictionary or optimized attacks the complexity of the full password is 7x11 or 77 bits (or 151,115,727,451,828,646,838,272 combinations). So with just the password hash that’s how many tries you need to exhaust every possible option, again without optimizing the process.

        But for each of the pairs the complexity is 14 bits or 16,384 combinations. So it would take microseconds to crack all 4 of the pairs. With that information you’d get a password of ?as?wo?d1?3??? (because we don’t know the length) and if they have used a common word or series of words you might have enough information to guess the rest, but even when brute forcing you’ve removed a decent amount of complexity.

        Note: This is SHA256. We’re going to ignore salt for this. Salt only increases complexity because you need to crack each user’s password and not able to really use rainbow tables etc.

        Unless I misunderstood the idea. In which case, sorry about that.

        In all likelihood it is encrypted in a database and the interface to the phone operator only allows them to enter what is said and confirm (although I wouldn’t be surprised of some showing the whole password).

        • floofloof@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          You may be right. I was thinking that the strings would be padded with a random pepper and a unique salt though, before hashing. So the string “sw” might become “swrP86#UlRA64%KGjBICfyO!6” with the unique salt and then “awrP86#UlRA64%KGjBICfyO!6L6ZCf3#T##ssUPjfOMXL^YGZ" with pepper added before hashing, while the string “od” might become "odjaSmh&1$n1##1#400AjQE10kXL6ZCf3#T##ssUPjfOMXL^YGZ” (salt shown in italics). Then you’d be trying to crack these long strings rather than just two-character strings. Of course, if someone steals the DB they would have the unique salt, which would reduce the difficulty to that of guessing two characters plus the pepper (assuming the pepper is stored securely elsewhere), but that’s still quite difficult.

          • r00ty@kbin.life
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            The issue with salt is that it is stored with the password hash. So you’d pretty much get that information with the password. It’s only designed to make sure the hash won’t be the same for the same password on other users, not to make breaking the hash any harder on its own.

            You could store it (and/or pepper) wherever the password is actually checked and splitting it would help. But I cannot imagine they’re doing that. It’s far more likely they’re encrypting the password and keeping the key off the database server. Meaning they need to get both, to get passwords.

            • floofloof@lemmy.ca
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              1 year ago

              Yes, my understanding is that the pepper is usually supplied from another source (not stored in the database), specifically to make it more difficult for anyone who steals the database to crack the password hashes. It would mean that if you stole this hypothetical db with two-letter subsets of the password in it, and got the salts too, you’d still be cracking the hash of a much longer string. But if you figured out that one string (pretty hard to do), you’d have the whole lot.

      • Primarily0617@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        If you have the password hashes, you almost certainly have the salts. Salts prevent the same password used by different users having the same hash, but if you’re bruteforcing, they don’t really add to complexity.

        Bruteforcing 2 characters + a salt is computationally the same as bruteforcing 2 characters.