For recovery and nonrepudiation purposes, storing a salted hash of the phone number would be the wiser course. If using SMS for notification, services like Twitter should have API callbacks and delegate the problems of multi-platform notifications to a trusted third-party similar to credit card processing.
You can easily brute force the narrow key space if you’re trying to verify if it’s “known”. And if you want to send an actual message you need the full value.
Sounds more like you want to outsource user verification and receive an opaque token for future validation.
Then, wait until someone texts that number in, and salt/hash the caller ID number and compare it to what you’ve got stored. If there’s a match, then you’re authenticated.
Probably lots of issues with this from ux perspective…
Not too secure, as phone numbers are easy to crack (possibly with randomized salt, that even twitter has to “brute force”?), but at least not every entry will be easily readable.
It might not be an issue for some types of usage, but sounds risky if used for account security/recovery/etc.
If the number is not actually validated in a secure (enough) manner, there's no point in using phone numbers at all.
This is something Signal should look into if they're interested in an alternative revenue stream.