Content
@
0 reply
0 recast
0 reaction
Andrei O.
@andrei0x309
It's not only on the device, I just logged in with a fresh emulator. Clearly, it's stored persistently. In the best-case scenario, it's encrypted with the user-provided seed as a password, and the seed is never stored at Merkl. But again, without the full source code of the backend + client, it's just: "trust me, bro", for all we know, even the seed could have been stored.
3 replies
2 recasts
19 reactions
artlu 🎩
@artlu
tysm for this exploration, @andrei0x309. I've just sent you my Warpcast Rewards for this week. (It's not much, but it's 100% .) Based on your best understanding, Andrei, could you speculate on what information you would need from me to be able to retrieve my phone number? My seed phrase, yes, and also would an auth token be enough?
2 replies
0 recast
4 reactions
Andrei O.
@andrei0x309
Thanks, much appreciated. I have not tested if the auth token is enough, but I can look into it. My speculation of this being guarded by the seed is the scenario, I dealt with in the past as an option when dealing with apps that integrate a client-side wallet. That scenario provides better protection for users, as any code that needs your PK needs to be executed by the client, which is more cumbersome for the provider because if users don't update the app, the provider can't take that action, or if the users use an alternative client( in Farcaster case). An example of this is the upcoming authorizing the Warplet address as an Auth address, which can only be executed with the custody PK, and will be fulfilled automatically. If is not accomplished by pushing code to the client it means Warpcast has direct access to your PK which is bad IMO. I'll take a look to see if it can be retrieved by auth token only and come back to this.
1 reply
0 recast
3 reactions
Andrei O.
@andrei0x309
It seems using the auth token is enough endpoint is v2/account-verifications . I did the verification some time ago maybe they changed it for newer verifications to not store it anymore, who knows that could be tested with a new phone verification if anybody has a new number and checks this endpoint with his token he can find that out. Anyway even if this is the case, that they have changed the policy for phone storage, older verifications should have been updated to not be possible to get the phone from API. Because it's super easy to migrate old verifications to the new standard such that the data is uniform.
0 reply
0 recast
1 reaction
