Open pleasework-sh opened 3 months ago
Hmm, interesting. What would you expect correct behavior to be?
Admin can accept one but not the other. For an auth=link
vote like this, they are both marked "pending" until admin approval.
Another issue to be mindful of is we don't want to leak who's already voted (by attacker entering the target's email, and seeing if it errors), nor creating a way to block a target from voting, by entering their email first.
So it's really hard to think about using email address as a verifier because there isn't really any way to truly say "This email is 100000% verfieably owned by pleasework.sh and currently under her control"
I'm wondering if email address should even be used at all as opposed to something like a government ID.
I know that for some sensitive government websites you have to physically get onto a video call with an employee and they will look at your video stream and have you show them your ID that you've already submitted (sorry I don't have this at the ready, I will do my research and find some) but with AI, is this even a good way to verify an identity anymore?
Just thinking out loud. Need to do more research.
get onto a video call with an employee and they will look at your video stream and have you show them your ID that you've already submitted (sorry I don't have this at the ready, I will do my research and find some) but with AI, is this even a good way to verify an identity anymore?
auth-by-video-chat has been publicly broken for nearly 2 years at this point, and it's only getting easier and easier: https://github.com/hacksider/Deep-Live-Cam 🥸
Awesome, thanks for that info. I'm trying to do better to keep up with new attacks, etc. Bit of a newb here.
There could be a backend check that looks to see if the email was already used. If so, just don't send the verification email.
So an attacker can try to submit someone else's email for auth for their vote and not get any error messages.
Assuming that a user verifies their email right away, then that might be a partial solution.
Of course, what if the attacker sends in a vote before the user? What if the user loses control over their email address after they submit their vote? Part of the problem is, you have to trust that user won't blindly accept a verification email sent by an attacker if the attacker used that user's email before the user got a chance to vote.
I think I'd like to try to do some threat modeling on this.
I'm not an expert by any means though in terms of AppSec or threat modeling.
Appreciate you engaging and thinking deeply about this
Thanks again for participating! This submission earned $68.03 from SIV and $72.86 from the Public Vote, for a total of $140.89.
Here's what we noted in our evaluation:
Issue to track getting paid: https://github.com/siv-org/hack.siv.org/issues/5
For the mock election, you submit your name and an email address for verification after voting.
You can then vote again, and on the auth page you can enter the same name and email address again.
Both times, you will get a verification email to that same address.