Anonymous login idea feedback
Hey dudes
Got an idea I want to run by you.
So I'm building this project:
https://www.indiehackers.com/product/imokay
It is in super early stages, literally spent a few hours building it on Sunday and deployed live so it is missing a lot of features.
However, I want it make it privacy focused because it is very private info you share there. Currently, there is no login or registration because I don't want any data to be associated with anyone. All data is kept in local storage where only you can access it on only one device.
This is where the problem lies, I would like the data to be synced across devices.
Here is what I came up with:
- Instead of email and password, you only provide a password
- The password then is used to generate a unique key that you MUST save somewhere, like your 1password or your notion or whatever you use
- You enter the key when you land on the site
- I then download all the data associated with that key and populate the charts/data
What do you think of this?
Trending on Indie Hackers
You might want to investigate something like SQRL, which has some of the same motivations, but has undergone some vetting already.
But the question I would personally have, if I needed to use it, is how a key/token (used to identify users and traceable to any machine that is used to access the service) is really different from a user name, which is also an ID to identify users, but is memorized and can just be hidden in interactions? That's not to poke holes, but because there might be some mental model of an account where that does make more sense. For example, peer-to-peer applications often don't have a login process, because it's assumed that you secured your account and so your generated token is all that you need to identify yourself.
It's probably less of an issue than it was years ago, but it might be also worth asking how this would work for people who share a computer.
You could also ask your users for a username and password, which is what they might be more used to. You don't have to ask for email and users don't have to use their real name as username so it's a pseudonym without a connection to a real-world identity. You can then use the username as key instead of a random ID. If you want, you can use the password for encryption, which is what password managers generally do, too.
Well, the idea is good, but I'd suggest you a simpler approach if you don't mind using SSO.
I developed two platforms with this approach:
https://subbly.app and https://memember.app
Google Sign-In assigns a unique user ID for every project, meaning that if you will sign in in both apps with the same account, you will be assigned a different ID in either case. (This part turned out not to be true) MY MISTAKE Knowing that, you can design a system where your userID is the external userID assigned by Google. Once your user signs in with Google, you will send only the Google authorization token to your backend. Then, this token might be verified and you can create your own token used for authentication on your platform (it's JWT in my case).
As a result you you don't store any personal data apart form the external user id which cannot be converted back to the google account (for instance email). What you do have on the other hand is a solid authentication mechanism with 2 factor auth that is commonly used and understandable for the user.
The downside with this approach is that there is still some connection between a real-world identity / email and the internal user ID. Even though only Google has that information, I wouldn't consider this wise from a privacy perspective, if your goal is to detach everything you store from identity.
I agree to some extent. Please note that even though there's a connection, probability of conversion userId -> email is very low. Somebody would need to get access to your database and somehow 'hack' Google's auth mechanism. I think it's the best balance between user's anonymity and convenience. Also, there's nothing stopping you to add additional layer of id scrambling.
You can create an algorithm which converts Google User Id into UUID (one way only) and use this UUID in your database. This way the database does not contain any link with real-world identity and if the hashing algorithm is designed well, even if the source code leaks, there's no simple way to reverse UUID -> userID
Yes, I agree that the practical probability of an identity being leaked this way is low, but it's not zero. So you have to consider your threat model. Also, look at it from the user's perspective; they may not understand this in full so it's also important to make them feel the privacy. Signing in with Google probably doesn't do that.
Not the OP - but you got me curious. So Google keeps an external, project specific and unique user id associated - and you just use that user id? So you only have that seemingly random number and the Google auth token? No email, nothing?
Exactly, some time ago every project received the same userID but that changed (few years ago). (This part is not true, the sub field is constant per google user despite the project) User provides his login credentials in the Google Sign-In plugin and the app receives the google auth token. This token can be verified with google (whether it really was generated using your app and if it's correctly signed with google's key).
Every time user logs into your app with Google, the ID will be the same, but when he'll log into another the ID will be completely different. This prevents a situation that a malicious actor can use a leak from app XYZ and correlate users from your app.
Interesting. Did you just find that with Google? Or is this documented behavior for OpenID connect in general?
Actually, I was wrong... I checked my databases and this ID is the same in different projects. I know that GoogleUser.getId() from Android library returns different IDs for different projects and automatically translated it to the sub field being also unique. Sorry for this mistake. But still, using it along with hashing function can generate unique UUID that can be stored in db safely.
Thanks for checking. But either way I am wondering whether this is according to the spec or according to the implementation.