4 ms·

Sorry maybe I haven't looked in detail enough, e.g. in Belgium telephone numbers have 10 digits, so you need a table of 10 billion hashes (far less in practice

Sorry maybe I haven't looked in detail enough, e.g. in Belgium telephone numbers have 10 digits, so you need a table of 10 billion hashes (far less in practice due to the structure of a telephone number) if you're using a telephone number, that's probably not hard to achieve. Then you look up the hash for the domain you want to hijack and try to register that domain in the service you're signing up to (with your fake / looked up telephone number).

elliottinvent 3y ago
Thanks for taking a look. I think you might have missed an important part of this (perhaps I overlooked to explain this part more thoroughly) – the "verifiable identifier" (e.g. telephone number or email address) still needs to be verified by the service provider using usual onboarding methods. An attacker can't just guess the email or telephone to be able to claim the domain on the service.
- plagiarist 3y ago
  Will an attacker be able to use rainbow tables to uncover emails or phone numbers from the publicly-available TXT record?
  - elliottinvent 3y ago
    Great question, thanks. If the Verifiable Identifier is not salted first, and the attacker is determined to match a particular domain to a hash in a rainbow table of hundreds of millions of email addresses / phone numbers, then the answer is yes. So worst case scenario, this could be a way for a bad actor (e.g. a state) to track down the journalist that runs a blog that's critical of a regime. However, people like that would not opt-in to a Domain Verification record in the same way that they don't opt in to having their details published to the website / WHOIS. So I don't think this is a real risk. The bigger rainbow table risk is mitigated by the hash being used in the DNS label. As an example, if the hashed verifiable identifier was simply stored in TXT at: _dv.example.com Then it would be trivial to harvest e.g. 100m Domain Verification records and then match those hashes against a rainbow table (e.g. 500m hashed emails). However, since the hash is used in the label so you would need to run 500m DNS queries per domain (one for each rainbow table hash).
- linuxdude314 3y ago
  Don’t you see then this accomplishes nothing for the implementer and instead makes them do more work in addition to still requiring the user to add a DNS record? Why would I want to have to validate someone’s phone or email address (not free), when I could use a standard way simply instructing my user to add a particular TXT record. This reeks of NIH.
  - elliottinvent 3y ago
    The implementer being e.g. Facebook? If I understand your argument correctly, you are saying: "I'm Facebook, why would I go to the trouble of asking my users to create a Domain Verification record and verifying their email? Especially when this record would then benefit my competitors like Google and Microsoft!?" I think there are a few angles to consider here: 1. There's no additional cost to verification for most service providers, since verification of email and phone is part of the onboarding process. 2. Licensing – if there are lots of domains with Domain Verification records, then there are benefits to Facebook in being able to automatically verify domains (if the DV record has already been setup by another service provider). By licensing the verification technology they could be required to instruct users to create these records. 3. The implementer may actually be a domain registrar like GoDaddy because it will improve the experience for their domain registrants and reduce support overhead for people trying to verify domains with service providers.
jeroenhd 3y ago
My GPU will reportedly do about 2.8 billion SHA-256 hashes per second, and it's already a few years old. With consumer hardware you can brute force this in seconds even without using heuristics (i.e. applying rules based on country prefixes).
- elliottinvent 3y ago
  I might have misunderstood you, but brute force what exactly? Sure, you could use your GPU to generate hashes for 500m email addresses / phones (if they weren't already pre-generated) but then what? You'd need to then run a DNS check against a target domain – this would introduce 15-300ms DNS check overhead, per hash and you'd get blocked in seconds by your ISP / DNS resolver. Even if you managed it, it would only reveal an association between a domain and email address, it wouldn't brute force anything. You'd still need to prove control over that email/phone. You can even remove the chance of an association being revealed through salting but that introduces a dependency, more info on the website.

elliottinvent 3y ago

Thanks for taking a look. I think you might have missed an important part of this (perhaps I overlooked to explain this part more thoroughly) – the "verifiable identifier" (e.g. telephone number or email address) still needs to be verified by the service provider using usual onboarding methods. An attacker can't just guess the email or telephone to be able to claim the domain on the service.

plagiarist 3y ago
Will an attacker be able to use rainbow tables to uncover emails or phone numbers from the publicly-available TXT record?
- elliottinvent 3y ago
  Great question, thanks. If the Verifiable Identifier is not salted first, and the attacker is determined to match a particular domain to a hash in a rainbow table of hundreds of millions of email addresses / phone numbers, then the answer is yes. So worst case scenario, this could be a way for a bad actor (e.g. a state) to track down the journalist that runs a blog that's critical of a regime. However, people like that would not opt-in to a Domain Verification record in the same way that they don't opt in to having their details published to the website / WHOIS. So I don't think this is a real risk. The bigger rainbow table risk is mitigated by the hash being used in the DNS label. As an example, if the hashed verifiable identifier was simply stored in TXT at: _dv.example.com Then it would be trivial to harvest e.g. 100m Domain Verification records and then match those hashes against a rainbow table (e.g. 500m hashed emails). However, since the hash is used in the label so you would need to run 500m DNS queries per domain (one for each rainbow table hash).
linuxdude314 3y ago
Don’t you see then this accomplishes nothing for the implementer and instead makes them do more work in addition to still requiring the user to add a DNS record? Why would I want to have to validate someone’s phone or email address (not free), when I could use a standard way simply instructing my user to add a particular TXT record. This reeks of NIH.
- elliottinvent 3y ago
  The implementer being e.g. Facebook? If I understand your argument correctly, you are saying: "I'm Facebook, why would I go to the trouble of asking my users to create a Domain Verification record and verifying their email? Especially when this record would then benefit my competitors like Google and Microsoft!?" I think there are a few angles to consider here: 1. There's no additional cost to verification for most service providers, since verification of email and phone is part of the onboarding process. 2. Licensing – if there are lots of domains with Domain Verification records, then there are benefits to Facebook in being able to automatically verify domains (if the DV record has already been setup by another service provider). By licensing the verification technology they could be required to instruct users to create these records. 3. The implementer may actually be a domain registrar like GoDaddy because it will improve the experience for their domain registrants and reduce support overhead for people trying to verify domains with service providers.

jeroenhd 3y ago

My GPU will reportedly do about 2.8 billion SHA-256 hashes per second, and it's already a few years old. With consumer hardware you can brute force this in seconds even without using heuristics (i.e. applying rules based on country prefixes).

elliottinvent 3y ago
I might have misunderstood you, but brute force what exactly? Sure, you could use your GPU to generate hashes for 500m email addresses / phones (if they weren't already pre-generated) but then what? You'd need to then run a DNS check against a target domain – this would introduce 15-300ms DNS check overhead, per hash and you'd get blocked in seconds by your ISP / DNS resolver. Even if you managed it, it would only reveal an association between a domain and email address, it wouldn't brute force anything. You'd still need to prove control over that email/phone. You can even remove the chance of an association being revealed through salting but that introduces a dependency, more info on the website.