> To make it more difficult to brute force, when generating the humanID Account ID, we will concatenate the phone number with a Salt Key (another string that will be appended before the hash).
> sha512hash ( Salt_Key + Phone Number ) = Hash Result
This is a complete joke (a SHA-512 of a phone number can be brute-forced on a typical computer in a fraction of a second). I doubt the rest of the protocols and cryptography are any better.
Also, phone numbers are not unique identifiers for people. Real people, malicious or not, have multiple or no phone numbers (or phone numbers that can’t receive SMS). I haven’t found a clear answer yet as to whether SMS verification is the only proof step but it seems like that’s the case.
No, I don't want to give every service my phone number.
> humanID blocks automated accounts, cyber-bullies, trolls, and freeloaders
Yeah, stop right there. Please don't block automation. That blocks innovation in accessibility. Go after the bullies and trolls but please don't try to differentiate a human and robot user of your UI, because some humans need a robot to help them.
And the salt itself appears to be private, and I assume, unique per user.
So, I'm in no position to say whether that's "good enough", but it's at least not something you're going to brute force in a few seconds.
Assuming there are on the order of 10 billion valid phone-numbers (there could be on the order of 100 billion depending on how far down the rabbit hole of international numbers you go). A GTX 1080 can do SHA512 @ ~1 billion/sec[0]. This means it will take 10 seconds (longer if you have a >11 digit number) to recover each phone number. This is fast enough that you don't need to bother hashing the phone book, you just brute force every possible number.
I would expect the napkin math to come out to years of compute to unmask someone in the face of a DB leak, not seconds or minutes.
[0]: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
But then the example salt they give is neither 64 bits nor 64 bytes. More like 26 bytes. I don't know who is more confused. Me, or them.
"Pepper" is per user, but widely regarded as unhelpful because, again, it's not cryptographically secure if the database is hacked.
Phone numbers barely help.
What really works though, is microtransactions. I have not seen any spam in chats where you are required to pay even a tiny fraction of a cent to join (1/64000th of a cent).
Is that some sort of oxymoron.
This, user data can never be leaked, stolen, or sold.
humanID’s login is frictionless done in seconds – try yourself!
If they can't even proofread their homepage content, it doesn't surprise me there are holes in their code.
My personal feelings, that aside, is that though many of us are privacy conscious, adding more and more dependencies to your site results in us having to trust more entities. Even if they don't store anything, we have to trust they aren't lying, that redirection is implemented properly, etc.
I think the best thing you can do if you care about the privacy of your users is minimize the amount of information necessary. So if your site doesn't require email, don't take it. If a phone number isn't necessary, don't ask for it. Use usernames, only ask for an email when the user is doing something that would require it (e.g. they need a receipt).
One thing that I love is when a site actually gives you a temporary username the minute you visit the "app" portion and you can use the site as if you created an account without having to do anything. That's usually a sign that the administrators really do care about you not jumping through hoops.
I'd even say "don't ask for it". Landing on the site I get a big banner that takes up a lot of the screen asking for my email. For a service that is talking about data protection and privacy, this sets off alarms. It may be completely honest and genuine, but since it takes so much of my screen it feels like you really want that data from me.
If your target audience is privacy conscious people you gotta know how privacy conscious people think. If you can't think like them, well then I'm also concerned that you don't have our interests in mind.
That being said where I seen it used there’s usually a huge disclaimer asking you to put in your email
But either way, the diagram says they're hashing phone numbers, so presumably that means they authenticate by typing in their phone number which is a terribly password since you give you phone number out to people so they must also send a TOTP via SMS which is better, but not great. NIST has started recommending not to use SMS for out-of-band authentication. Either way, this whole chain of events just delegates authentication your mobile carrier. Same thing if you send a TOTP to an email address. It feels more seamless, but really you're just delegating auth to their email provider. No different that using OAuth.
You're right. This turns hashes into passwords, and is distinctly a step down in security.
Sharing a document where others can edit it but it's created by your customer would come to mind.
I once implemented a non standard signin where all that was needed was an email link which kept you signed in.
Users hated it.
They actually went to the trouble of complaining and no doubt it lost me potential signups.
These days I only ever do normal email and password signup.
As a user who occasionally runs into this now, I hate it.
I refuse to use sites that require 3rd-party auth. If I have a problem logging in to your site, I want to reach out to you and get it resolved. I don't want you to say, "We don't have any ability to address auth issues on our own site. Take it up with <completely unrelated site>." I don't want my account with you to be suspended because I had a falling out with Facebook or Google or anybody else that is not you.
So, to me it looks like marketing hype without substance. It would be useful for the site to be online and not giving 500 errors though to see if they had anything else.
Which has all the same issues as SMS 2FA.
... color me suspicious. I'd read the technical details, but I can't seem to find any through the wayback archive.
I am immediately suspicious. Nobody in their right mind with sufficient technical background is still claiming that in 2021, for any technical solution.
"Please use the original title, unless it is misleading or linkbait; don't editorialize."
>Our Vision: One Digital Identity per Human – both Anonymous and Accountable...billions of fake user accounts undermining our societies.
Why would I want to use something that allowed me only one identity?
And if I have to give away my mobile number it is hardly one-click.
And a lot of the stuff that other comments have mentioned!
So already I won't use it because I don't want to authenticate via SMS. It also raises the immediate question of what happens when I change my phone number?
But why should I trust this website more than your website? Unless your website is fully zero-trust it is probably better to trust you to throw away my phone number than handing my phone number to this company and other data to your company.
Prove you are human with validation as public turing test done on blockchain. There is simple one click login and it's used now on Gitcoin.
Website: https://www.idena.io/
Minimum viable user & social features.
Also, to be clear, while the site was down for an hour, the login never was, as we have set that up independently from the site.
