6 votes

Hashing Phone Numbers For 2-Factor Authentication

12 comments

  1. petrichor
    Link
    Do note that phone numbers are the worst form of 2-factor security, and should be avoided whenever possible. Sim swapping attacks are very easy to pull off and not just restricted to...

    Do note that phone numbers are the worst form of 2-factor security, and should be avoided whenever possible.

    Sim swapping attacks are very easy to pull off and not just restricted to "high-profile" people.

    7 votes
  2. [6]
    stu2b50
    (edited )
    Link
    It’s a good idea. May as well add a salt to them before hashing as well. My phone number was leaked ages ago from sites not doing this and getting breached. edit: the main issue that it’s fairly...

    It’s a good idea. May as well add a salt to them before hashing as well. My phone number was leaked ages ago from sites not doing this and getting breached.

    edit: the main issue that it’s fairly weak protection in the end, just because the input space is so low. There’s like ballpark 4 billion or so legit phone numbers in the US, and a 3080 could brute force all 4 billion in less than 5 minutes. A more expensive hash would help but in the end there’s just not enough phone numbers.

    Better than nothing, though.

    4 votes
    1. [3]
      Greg
      Link Parent
      You're absolutely right, but if I'm reading this correctly it's so much less that you can do it in about 0.75 seconds. Which makes no real difference to the conversation at hand, it just blows my...

      a 3080 could brute force all 4 billion in less than 5 minutes

      You're absolutely right, but if I'm reading this correctly it's so much less that you can do it in about 0.75 seconds. Which makes no real difference to the conversation at hand, it just blows my mind how fast these things actually are - a friend pointed something similar out to me recently, which is what prompted me to double check.

      2 votes
      1. [2]
        stu2b50
        Link Parent
        Yeah I gave it some leeway since you could pick hash algorithms that are slower but for most mainstream hashes you can burn through them at an insane rate on modern gpus. Fun fact: even if you...

        Yeah I gave it some leeway since you could pick hash algorithms that are slower but for most mainstream hashes you can burn through them at an insane rate on modern gpus.

        Fun fact: even if you just ignore the actual rules for phone numbers and just brute force all 10^10 possible numbers that could be phone numbers it would only take just over a minute if they’re sha256 hashed.

        4 votes
        1. pallas
          Link Parent
          I would suspect that there are simply few enough valid phone numbers that no possible hash algorithm could be both slow enough to resist brute forcing and fast enough to be useable at a reasonable...

          I would suspect that there are simply few enough valid phone numbers that no possible hash algorithm could be both slow enough to resist brute forcing and fast enough to be useable at a reasonable scale.

          2 votes
    2. [2]
      theabbie
      Link Parent
      Yup, will need a slower hash function and also salting, However, If the whole server is breached, so will the salt, I thought about user choosing salt, but then they will have to remember it and...

      Yup, will need a slower hash function and also salting, However, If the whole server is breached, so will the salt, I thought about user choosing salt, but then they will have to remember it and shouldn't forget it, thus, making it unusable, wish phone numbers were longer.

      1 vote
      1. stu2b50
        Link Parent
        The main point of the salt is to prevent rainbow table attacks (ie someone could precompute all the sha256/bcrypt/etc hashes for the database of phone numbers mine is apparently in) Although,...

        The main point of the salt is to prevent rainbow table attacks (ie someone could precompute all the sha256/bcrypt/etc hashes for the database of phone numbers mine is apparently in)

        Although, thinking more on it, probably won’t matter that much given how easy it would be to brute force.

        2 votes
  3. [5]
    Pistos
    Link
    First: The myriad incorrect uses of capitalization and punctuation riddling the article were extremely distracting for me. If this were some kind of psychological experiment, to test how many...

    First: The myriad incorrect uses of capitalization and punctuation riddling the article were extremely distracting for me. If this were some kind of psychological experiment, to test how many people found it jarring, well, I think it totally succeeded doing just that.

    Second: (unless I've misunderstood the proposal) This isn't how 2FA works. If all we're asking services to do is check a computed hash (in the present) against a stored hash (acquired in the past), then that is essentially just a password. There wouldn't be any mechanism whereby ownership of the phone is confirmed. That's what standard 2FA is: two-factor. One: something you know (password), and, two: something you have (such as a phone with a uniquely-configured app, or usb dongle). The proposal boils it down to just the "know" part; two passwords.

    Third: to hedge against the original issue (third party acquiring your precious legit phone number), you have to avoid actually giving it. As such, the hashing needs to be done client-side, such as by a local app on the computer or mobile device. And then only the hash should be transmitted to the third party. Sending the unhashed phone number to the third party to have it do the hashing defeats the original purpose.

    2 votes
    1. [3]
      Thra11
      Link Parent
      As I understood it, the idea here is that the service can use your phone number as "something you have", without having to actually store your phone number (because they store the hash instead)....

      Second: (unless I've misunderstood the proposal) This isn't how 2FA works. If all we're asking services to do is check a computed hash (in the present) against a stored hash (acquired in the past), then that is essentially just a password. There wouldn't be any mechanism whereby ownership of the phone is confirmed. That's what standard 2FA is: two-factor. One: something you know (password), and, two: something you have (such as a phone with a uniquely-configured app, or usb dongle). The proposal boils it down to just the "know" part; two passwords.

      As I understood it, the idea here is that the service can use your phone number as "something you have", without having to actually store your phone number (because they store the hash instead). For 2FA login, the service will request your phone number, hash it, check that the hash matches the one they have stored, then send a text to that number with a one time password, then discard the phone number. You then confirm that you possess the phone/SIM by entering the one time password from the text as usual.

      4 votes
      1. [2]
        Pistos
        Link Parent
        I see. I think it would help for the article to be reworded to emphasize that this is a benefit from the perspective of the service provider, not per se the end user. It gives the provider perhaps...

        I see. I think it would help for the article to be reworded to emphasize that this is a benefit from the perspective of the service provider, not per se the end user. It gives the provider perhaps some deniability, and also protects the phone numbers in the event of a provider-side breach. To be clear: It doesn't help the end user hide their phone number from an untrusted provider.

        1 vote
        1. Thra11
          Link Parent
          Assuming a trustworthy service provider, the phone numbers not being stored, and thus not leaked in a provider-side breach, is of benefit to the end user. In the case of an untrusted provider, I...

          Assuming a trustworthy service provider, the phone numbers not being stored, and thus not leaked in a provider-side breach, is of benefit to the end user.

          In the case of an untrusted provider, I think you're right: it would be better to use something like TOTP, where the provider shares the secret (which, unlike a phone number, is meaningless outside of this specific authentication) with the user, who then stores it.

    2. theabbie
      Link Parent
      It doesn't use Phone number as password, It should have been more clear, it means that it will verify the computed hash and if correct, send OTP and continue the usual 2FA procedure, so, even if...

      It doesn't use Phone number as password, It should have been more clear, it means that it will verify the computed hash and if correct, send OTP and continue the usual 2FA procedure, so, even if it doesn't add security, it won't reduce as well as we are already storing plain text phone number. A hacker who breaches will have to put some effort brute forcing each phone number, which is ofcourse possible.

      3 votes